questions, improvements, suggestions from @kempniu

[ahupowerdns]

This is a copy of suggestions from @kempniu within a now merged PR

basic.md

457 Any authoritative server which does not implement 'zones' in this way will
458 eventually run into trouble. It is not enough to consult a list of known
459 names and answer records attached to those names.

The phrase "answer records" is not used earlier in the text. Later on, it is used when negative answers are discussed, in which context it makes a lot of sense. Here, though, I think the reader might wonder whether "answer records" are records which were somehow specially designated for being used in answers. Perhaps just say "records" here? Dunno, maybe it's just me.

608 ## Query types that are not RRSET types
609 In addition to the resource record types covered above, like A, AAAA, NS and
610 SOA, two additional types exist that can only be used in queries: ANY, AXFR
611 and IXFR.

You say "two additional types" and then list three of them. I understand AXFR and IXFR are related but IMHO it might be tricky to get for people reading about this stuff for the first time.

auth.md:

 61 1. No applicable zone is loaded. Send REFUSED answer.
 62 2. From best zone, there was an exact match for the qname and qtype, send RRSET, set NO ERROR
 63 3. From best zone, the name queried exists, but no matching qtype and no NS type present (send NO DATA)
 64 4. From best zone, the name may exist, but there is a node or a parent has an NS record. Send delegation

• Item 4 sounds unclear to me. Is there a word missing between the words "a" and "node"?
• Perhaps use "NOERROR" instead of "NO ERROR"? IMHO the reader is more likely to come across the former e.g. when using various diagnostic tools.
• "From best zone" sounds reasonably okay in point 2 but sounds off in points 3 and 4. (Maybe use "In the best zone" there?)
• Trailing punctuation is inconsistent between the items of this list. (Other punctuation nit: "(...), send RRSET" vs. "(...). Send delegation".

 89     2. If a match would take us out of the authoritative data,
 90        we have a referral.  This happens when we encounter a
 91        node with NS RRs marking cuts along the bottom of a
 92        zone.

I realize this bit is copied verbatim from RFC 1034 section 4.3.2 but this is the first time you use the word "referral" in the text. While obviously correct from a technical standpoint, perhaps use "delegation" here instead since you use that word elsewhere and it could prevent the reader from wondering whether there is a difference between a "referral" and a "delegation"?

optional.md:

 38 The EDNS content is attached to a pseudo-record called OPT in the additional
 39 section of a message and an answer.

AIUI, an "answer" is a type of a "message". Perhaps use "a query" instead of "a message" here?

 58  * NSID (3): Return the 'nameserver identifier' [RFC
 59    5001](https://tools.ietf.org/html/rfc5001)
 60  * EDNS Client Subnet (8): Convey part of client subnet [RFC 6891](https://tools.ietf.org/html/rfc2671).
 61  * Cookie (10): Lightweight transaction security [RFC  7873](https://tools.ietf.org/html/rfc7873)
 62 
 63 [RFC 7871](https://tools.ietf.org/html/rfc7871) is a concise specification
 64 that is completely applicable to 2018 DNS. Its implementation is highly
 65 recommended.

• RFC 7871 is the ECS RFC. Is this paragraph tongue-in-cheek? ;)
• The "RFC 6891" anchor text is linked to the wrong RFC (2671).
• I think you meant to put "RFC 7871" in the "EDNS Client Subnet" bullet point and "RFC 6891" on line 63.

Final remark: perhaps there is not a lot you can do about it quickly but the JavaScript Markdeep renderer apparently tries to outsmart itself when rendering the articles on a mobile device. It attempts to attach hyperlinks to the numbers in SOA records, treating them as phone numbers. However, since these records are inside triple backticks, the link tags appear on the screen:

---

---

Hope this helps, thank you again for doing this, it is much appreciated!