On 3.6.2015 10:44, Mark Andrews wrote: > In message <556ea478.80...@redhat.com>, Petr Spacek writes: >> I would like early feedback about following idea about interaction between DN >> S >> updates (RFC 2136) and classless IN-ADDR.ARPA delegation (RFC 2317). >> >> In short, the RFC 2317 tells me to fill reverse zone with CNAMEs pointing to >> (potentially) some other zone. >> >> At the same time, an attempt to add a PTR record to a node already containing >> CNAME will fail, possibly without reporting an error to the requester. AFAIK >> BIND 9.9 just prints an error to log but returns NOERROR to the client. >> >> As a result, RFC 2317 breaks dynamic updates for classless reverse zones. > > No, it doesn't. Add a appropriate prerequisite and you will a > error. > > nxrrset owner cname > add owner ptr hostname > > A naive client won't work but RFC 2317 has been around for decades > now so cnames should be handled.
I wish it was true. I did some experiments and even latest versions of Windows clients (8 + latest 10 beta) fail to take RFC 2317 into account and fail miserably when attempting to update PTR records. This confirms rumors from support people in the field. nsupdate from BIND 9.9 is basically a low-level tool so it cannot be blamed that it 'just fails' if the CNAME is present, but it also means that 'nsupdate' user has to implement own logic on top of it to handle RFC 2317. I seriously doubt that anybody did that. I feel that this effectively means that significant portion of PTR-updating DNS clients does not work when RFC 2317 is used and this in my eyes justifies a clarification. >> I'm going to sketch -00 draft which will attempt to address this by >> client-side canonization: >> >> The client should attempt to resolve whole chain of CNAME/DNAMEs from >> 1.2.0.192.in-addr.arpa down to terminal node and update the terminal node >> instead of the original name. > > You will get that as a side effect of working out where the zone > cut points are. > > <soa,4.3.2.1.in-addr.arpa> will get back the cname chain (if any) > and the appropriate zone soa if rfc2308 is supported either in the > answer section or in the authority section. I agree with this, but it is not enough, only a first step. Requestor also has to replace original names with the canonicalized versions in prerequisite and update sections of the Update Message otherwise the update will fail with 'out-of-zone' errors. >> Most interesting part of the text will be 'Security Considerations' >> (considering signed updates). >> >> I would welcome early feedback about the idea even before the -00 is publishe >> d. > > This shouldn't require a RFC as is it just apply exisiting RFC but > if it was to recommend that all nodes attempt to add PTR records > for themselves and described handling RFC 2317 as a senario it would > be more useful. Similarly handling DNAME. Here is the first sketch. It does not propose any protocol changes, it is just guidance for DNS UPDATE requestors. This is my very first draft and I struggle with terminology, especially with definition of canonicalization. Any feedback is more than welcome! Petr Spacek @ Red Hat -------- Forwarded Message -------- Subject: New Version Notification for draft-spacek-dnsop-update-clarif-00.txt Date: Mon, 29 Jun 2015 05:04:14 -0700 From: internet-dra...@ietf.org To: Petr Spacek <pspa...@redhat.com>, Petr Spacek <pspa...@redhat.com> A new version of I-D, draft-spacek-dnsop-update-clarif-00.txt has been successfully submitted by Petr Spacek and posted to the IETF repository. Name: draft-spacek-dnsop-update-clarif Revision: 00 Title: Clarifications to the Dynamic Updates in the Domain Name System (DNS UPDATE) specification Document date: 2015-06-29 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-spacek-dnsop-update-clarif-00.txt Status: https://datatracker.ietf.org/doc/draft-spacek-dnsop-update-clarif/ Htmlized: https://tools.ietf.org/html/draft-spacek-dnsop-update-clarif-00 Abstract: This document clarifies interaction among Dynamic Updates in the Domain Name System (DNS UPDATE), Classless IN-ADDR.ARPA delegation, and Secure Domain Name System (DNS) Dynamic Update in the presence of CNAME/DNAME redirections. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
