add more markdown, more content on AXFR/IXFR/ANY

README.md

@@ -555,6 +555,7 @@ Note that for various reasons the AA=0 answer from the parent zone may be
 different than the AA=1 answer, and resolvers must be aware of the
 difference.
 
+
 # Further aspects
 
 The description up to this point is correct, but far from functionally
@@ -625,7 +626,7 @@ this could be done to stay under the 512 byte limit.
 It is recommended however to keep it simple and send an empty response
 packet with TC=1 whenever the byte limit is reached.
 
-### Names and nodes that do not exist
+## Names and nodes that do not exist
 DNS queries can fail to match in two ways: the whole node does not exist,
 or, the requested type is not present at that node.
 
@@ -640,7 +641,25 @@ these cases the authoritative server sends a copy of the SOA record in the
 Authority section of the response. The TTL of that record tells us how long
 the knowledge of 'no such name' or 'no such data' can be cached.
 
-# That's it!
+## Query types that are not RRSET types
+In addition to the resource record types covered above, like A, AAAA, NS and
+SOA, two additional types exist that can only be used in queries: ANY, AXFR
+and IXFR.
+
+An ANY query instructs a nameserver to return all types it immediately has
+available for a name. This 'immediately' qualification makes ANY queries
+unsuitable for talking to resolvers - it is not sure the response is in any
+way complete. 
+
+Because of the potential of creating huge answers, the use of ANY is
+problematic even when talking to authoritative servers, and it may no longer
+work well in the future.
+
+AXFR and IXFR are requests for (incremental) zone transfers, almost always
+over TCP. This query asks an authoritative server to list an entire zone.
+Resolvers do not process AXFR or IXFR queries.
+
+# That's it for basic DNS!
 This is the core of DNS. There are quite some parts that have not been
 discussed, but based on the explanations above, it is possible to write a
 compliant authoritative server. 
@@ -697,4 +716,5 @@ preventing "birthday attacks".
 of header bits (AA) and RCODEs when following CNAME chains. Also discusses
 an earlier version of DNAMEs, these parts are best ignored in lieu of
 (later) reading the newer DNAME specification.
+
 <!-- Markdeep: --><style class="fallback">body{visibility:hidden;white-space:pre;font-family:monospace}</style><script src="markdeep.min.js"></script><script src="https://casual-effects.com/markdeep/latest/markdeep.min.js"></script><script>window.alreadyProcessedMarkdeep||(document.body.style.visibility="visible")</script>

auth.md

@@ -1,4 +1,41 @@
-# Intro
+                <meta charset="utf-8" emacsmode="-*- markdown -*-">
+                            **A warm welcome to DNS**
+
+
+# Authoritative servers
+
+The basics of DNS Authoritative operation have already been described in the
+[Basic DNS](index.html) document.  In this file, we delve deeper into zone
+transfers and and notifications.
+
+This document covers RFCs 1982, 1995, 1996, 4592, 5936, 7766.
+
+# Incoming queries
+An authoritative server ignores the value of the Recursion Desired (RD) bit
+in the DNS header. On any responses it generates, the Recursion Available
+bit is set to zero.
+
+Take special care not to send answers to what is already a DNS answer. This
+leads to tight loops and denial of service attacks. In other words, QR must
+be 0 on incoming packets.
+
+# The algorithm
+As noted before, DNS is fundamentally a tree and hierarchical in nature.
+This means that when a query comes in to an authoritative nameserver, it
+first needs to find the most applicable zone to answer from. And in fact,
+the same name may be present in multiple zones on the name server, and may
+very well have different types and even record contents.
+
+The most specific zone is located for a query name (qname). If no zone can
+be found, set RCODE to 'REFUSED' and send out the response. This is unlike
+many example responses shown in RFCs and other documents listing 'root
+referrals' and other things. Just send 'REFUSED'.
+
+Within the most specific zone, see if the entire qname can be matched. If
+so, determine if that name has the type the query asked for ('qtype'). If
+yes, send out that RRSET.
+
+
 
 xxx
 RFC1982
@@ -37,3 +74,5 @@ This is not a popular feature.
 The final number, 86400, denotes that if a response says a name or RRSET
 does not exist, it will continue to not exist for the next day, and that
 this knowledge may be cached.
+
+<!-- Markdeep: --><style class="fallback">body{visibility:hidden;white-space:pre;font-family:monospace}</style><script src="markdeep.min.js"></script><script src="https://casual-effects.com/markdeep/latest/markdeep.min.js"></script><script>window.alreadyProcessedMarkdeep||(document.body.style.visibility="visible")</script>

stub.md

@@ -29,3 +29,4 @@ AAAA of a name, it should be prepared to receive responses out of order.
 It is also important to actually test the TC=1 response path, something that
 may be triggered when sending queries that lead to huge answers.
 
+<!-- Markdeep: --><style class="fallback">body{visibility:hidden;white-space:pre;font-family:monospace}</style><script src="markdeep.min.js"></script><script src="https://casual-effects.com/markdeep/latest/markdeep.min.js"></script><script>window.alreadyProcessedMarkdeep||(document.body.style.visibility="visible")</script>