4 ms·

This is pretty good, but some minor nits - >A name and all the names below it that are not delegated to someone else is collectively called a zone I don't und

by axaxs 12y ago

This is pretty good, but some minor nits - >A name and all the names below it that are not delegated to someone else is collectively called a zone I don't understand this statement. For example, the vast majority of the 'com' zone are NS records for subdomains, and that is considered part of the com. zone. The DNSSEC section is decent. NS rrsets don't get signed, and a distinction in DNSKEY types should probably be pointed out. Also, the talk of 'shadow nodes' is confusing and I still don't know what they are referring to.

js2 12y ago
I don't understand this statement. For example, the vast majority of the 'com' zone are NS records for subdomains, and that is considered part of the com. zone. The NS records themselves are within 'com' so they are part of the 'com' zone. It is the NS record itself that forms the delegation. The article elsewhere makes a mention of "someone else" but of course you can delegate to yourself. What makes a delegation is an NS record. What makes a zone is really an SOA record (and the corresponding sibling authoritative NS records in that zone). FWIW, RFC 1034 and 1035 are very readable. http://tools.ietf.org/html/rfc1034 http://tools.ietf.org/html/rfc1034 http://tools.ietf.org/html/rfc1035 http://tools.ietf.org/html/rfc1035 Aside, I always found it somewhat interesting that the DNS RFCs go into the implementation details of BIND. It's not really relevant to the operation of a other DNS implementations what the syntax of a zone file should be. Or how replication (AXFR) should be handled. The SOA record itself contains information that only BIND even cares about.
- axaxs 11y ago
  Heh, I'm very familiar with DNS and the RFCs. I was questioning the wording of the statement. "A name and all the names below it that are not delegated to someone else is collectively called a zone". The names in the com zone are delegated to someone else, hence the NS records. Just murky wording to me, but maybe I'm reading it wrong.
yxhuvud 11y ago
There is a updated version at http://calle.dybedahl.se/dns.html http://calle.dybedahl.se/dns.html . I don't know if any of your issues are clarified though. Apparently I shared the wrong version :(

by axaxs 12y ago

js2 12y ago

I don't understand this statement. For example, the vast majority of the 'com' zone are NS records for subdomains, and that is considered part of the com. zone. The NS records themselves are within 'com' so they are part of the 'com' zone. It is the NS record itself that forms the delegation. The article elsewhere makes a mention of "someone else" but of course you can delegate to yourself. What makes a delegation is an NS record. What makes a zone is really an SOA record (and the corresponding sibling authoritative NS records in that zone). FWIW, RFC 1034 and 1035 are very readable. http://tools.ietf.org/html/rfc1034 http://tools.ietf.org/html/rfc1034 http://tools.ietf.org/html/rfc1035 http://tools.ietf.org/html/rfc1035 Aside, I always found it somewhat interesting that the DNS RFCs go into the implementation details of BIND. It's not really relevant to the operation of a other DNS implementations what the syntax of a zone file should be. Or how replication (AXFR) should be handled. The SOA record itself contains information that only BIND even cares about.

axaxs 11y ago
Heh, I'm very familiar with DNS and the RFCs. I was questioning the wording of the statement. "A name and all the names below it that are not delegated to someone else is collectively called a zone". The names in the com zone are delegated to someone else, hence the NS records. Just murky wording to me, but maybe I'm reading it wrong.

yxhuvud 11y ago

There is a updated version at http://calle.dybedahl.se/dns.html http://calle.dybedahl.se/dns.html . I don't know if any of your issues are clarified though. Apparently I shared the wrong version :(