RFC 1033: When a subdomain is also a host. In the example DNS db...

Reader comments:

Comment by M. Tyson
Submitted on 8/25/2005
Related RFC: RFC 1033
Rating: Not yet rated	Rate this comment:
When a subdomain is also a host. In the example DNS db files for the SRI.COM. zone file, CSL.SRI.COM. is shown with MX, NS, and A RRs. In the CSL.SRI.COM. zone file, SOA, NS, and A RRs are given for the top of the zone (CSL.SRI.COM.). The NS and A records in the CSL.SRI.COM. zone are authoritative, not the ones in SRI.COM. The MX record is misplaced in the example and should have been in the CSL.SRI.COM. zone file instead of the SRI.COM. zone file. I consider RFC1034's Name Server algorithm (Sect. 4.3.2) buggy in that step 3.a and 3.b should be reversed. As I understand the intent, if there is a NS RR, then any other RRs (CNAME, MX, A, etc.) in this node are not authoritative. RFC1034 states "The RRs that describe cuts around the bottom of the zone are NS RRs that name the servers for the subzones. Since the cuts are between nodes, these RRs are NOT part of the authoritative data of the zone, and should be exactly the same as the corresponding RRs in the top node of the subzone. Since name servers are always associated with zone boundaries, NS RRs are only found at nodes which are the top node of some zone. In the data that makes up a zone, NS RRs are found at the top node of the zone (and are authoritative) and at cuts around the bottom of the zone (where they are not authoritative), but never in between." Similarly, if the COM. domain had MX, A, and NS RRs for the subdomain EXAMPLE.COM, they would not be authoritative.

FAQS.ORG makes no guarantees as to the accuracy of the posts. Each post is the personal opinion of the poster. These posts are not intended to substitute for medical, tax, legal, investment, accounting, or other professional advice. FAQS.ORG does not endorse any opinion or any product or service mentioned mentioned in these posts.

<< Back to: RFC 1033