[DNSOP] Sanity check
Hi, I wonder if I could please have someone say whether they agree with me on this one: I've come across a configuration in the wild where a given zone 'z' contains both a.z. NS some.name.server. *and* sub.a.z. NS some.other.name.server. and where the owner of 'a.z' could not understand why they have trouble controlling the data registered at the 'sub.a.z' name. My claim is that it is a Registry Error for the operator of the registry for the 'z' domain to permit this to happen, as it violates the basic idea of what a delegation means. Implementations appear to be slightly inconsistent in whether they expose or hide the sub.a.z. delegation, a sample shows: NSD 3.2.8 exposes BIND 9.7.0-P2 hides BIND 9.7.3-P1 hides BIND 9.8.0-P4 exposes ironDNS 1.0.1 exposes I'm a little surprised that BIND apparently has regressed on this... The actual names have been withheld to protect the guilty. Regards, - Håvard ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Sanity check
On 27 Oct 2011, at 12:06, Havard Eidnes wrote: Hi, I wonder if I could please have someone say whether they agree with me on this one: I've come across a configuration in the wild where a given zone 'z' contains both a.z. NS some.name.server. *and* sub.a.z. NS some.other.name.server. are some.name.server and some.other.name.server really different servers? Different instances of name server software(not only different IP addresses)? and where the owner of 'a.z' could not understand why they have trouble controlling the data registered at the 'sub.a.z' name. My claim is that it is a Registry Error for the operator of the registry for the 'z' domain to permit this to happen, as it violates the basic idea of what a delegation means. Implementations appear to be slightly inconsistent in whether they expose or hide the sub.a.z. delegation, a sample shows: NSD 3.2.8 exposes BIND 9.7.0-P2 hides BIND 9.7.3-P1 hides BIND 9.8.0-P4 exposes ironDNS 1.0.1 exposes I'm a little surprised that BIND apparently has regressed on this... The actual names have been withheld to protect the guilty. Regards, - Håvard ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Sanity check
I've come across a configuration in the wild where a given zone 'z' contains both a.z. NS some.name.server. *and* sub.a.z. NS some.other.name.server. are some.name.server and some.other.name.server really different servers? Different instances of name server software(not only different IP addresses)? That should not matter, IMO -- I consider it to be a Registry Error irrespective. However, let's say that they are completely separate, i.e. under different administrative control -- that appears to be the actual case in the example I'm looking at. Regards, - Håvard ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Sanity check
On 27 Oct 2011, at 11:12, Joao Damas wrote: I've come across a configuration in the wild where a given zone 'z' contains both a.z. NS some.name.server. *and* sub.a.z. NS some.other.name.server. are some.name.server and some.other.name.server really different servers? Different instances of name server software(not only different IP addresses)? Why would the NS records' RDATA matter to the z zone Joao? The NS records have owner names living under two discrete but nested zone cuts. I don't understand how the z zone would (need to) care about hostnames in the server or name.server zone. Or if they even resolve. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Sanity check
On 27 Oct 2011, at 12:24, Jim Reid wrote: On 27 Oct 2011, at 11:12, Joao Damas wrote: I've come across a configuration in the wild where a given zone 'z' contains both a.z. NS some.name.server. *and* sub.a.z. NS some.other.name.server. are some.name.server and some.other.name.server really different servers? Different instances of name server software(not only different IP addresses)? Why would the NS records' RDATA matter to the z zone Joao? The NS records have owner names living under two discrete but nested zone cuts. I don't understand how the z zone would (need to) care about hostnames in the server or name.server zone. Or if they even resolve. because some implementation merge info if it is available, if they host the databases for both zones, which leads to different observed behaviours in responses. Having said that, the registry for z. should not be delegating both a.z. and sub.a.z. (but it may happen in private DNS where z. is a small local TLD not part of the Internet's DNS). Joao ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Sanity check
On 27 Oct 2011, at 11:27, Joao Damas wrote: Why would the NS records' RDATA matter to the z zone Joao? The NS records have owner names living under two discrete but nested zone cuts. I don't understand how the z zone would (need to) care about hostnames in the server or name.server zone. Or if they even resolve. because some implementation merge info if it is available, if they host the databases for both zones, which leads to different observed behaviours in responses. Ah yes. I thought those sorts of quirks were limited to registry implementations and their database schemas. Perhaps DNS implementations show similar sort of behaviour whenever they use a database as their back-end. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Sanity check
On Oct 27 2011, Havard Eidnes wrote: Hi, I wonder if I could please have someone say whether they agree with me on this one: I've come across a configuration in the wild where a given zone 'z' contains both a.z. NS some.name.server. *and* sub.a.z. NS some.other.name.server. and where the owner of 'a.z' could not understand why they have trouble controlling the data registered at the 'sub.a.z' name. My claim is that it is a Registry Error for the operator of the registry for the 'z' domain to permit this to happen, as it violates the basic idea of what a delegation means. Implementations appear to be slightly inconsistent in whether they expose or hide the sub.a.z. delegation, a sample shows: NSD 3.2.8 exposes BIND 9.7.0-P2 hides BIND 9.7.3-P1 hides BIND 9.8.0-P4 exposes ironDNS 1.0.1 exposes I'm a little surprised that BIND apparently has regressed on this... I tried this setup with BIND 9.8.1 and it seems to me that it hides the inner delegation perfectly well, i.e. looking up anything in sub.a.z gives a referral for a.z only. Did 9.8.0-P4 really do something different? Or have I not understood what you mean by hides vs. exposes? -- Chris Thompson University of Cambridge Computing Service, Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Sanity check
At 12:06 +0200 10/27/11, Havard Eidnes wrote: Hi, a.z. NS some.name.server. sub.a.z. NS some.other.name.server. My claim is that it is a Registry Error for the operator of the registry for the 'z' domain to permit this to happen, as it violates the basic idea of what a delegation means. Depending on what you mean by exposed... It's possible to see this in a zone transfer, possibly occurring as a result of a dynamic update that added a.z's NS set after sub.a.z existed. What I recall from discussions (meaning I don't know if this is in a document) is that the dynamic update occludes (hides, as in the sense that the moon occludes the sun in a solar eclipse) the sub.a.z name. The rationale for this is as follows. When getting the dynamic update adding a.z/IN/NS, you have a design choice. You can refuse the update because there are names in the zone below a.z. You can eliminate the now out-of-zone data because the zone is not authoritative for it. Or you can occlude the data, meaning hold it in the zone (AXFR) but not consult it when answering a query. The last approach is better than the first because a bounce is avoided. The last approach is better than the second because the user can undo the dynamic update add with a delete at a minimum of effort to the name server. Mark Andrews noted that in his support experience, users often make a mistake and want to undo it. So this may not be a registry error but a way to maintain the ability to undo an addition. Of course, it may be a registry error but some name server implementations wouldn't let you load this zone from a user file. (Slaves would load from their backup files on restart; they would accept this in AXFR/IXFR.) Back to expose - if some.name.server. and some.other.name.server are the same process (even if the IP addresses are different for the names, etc.) it might appear that both delegations are in effect. There was once ip6.int which had all of it's delegations broken, but all fragments were on the same set of servers anyway. The only way to tell that the cut points were wrong was to get the AXFR and inspect it because name servers always give you the best answer they can as according to step 2 of the algorithm in RFC 1034, section 4.3.2. (All DNS geeks should have that section pinned to their wall at home.) But, yes, this is broken for some definition of broken. What happens in the query processing would never reach the deeper delegation IF you started in that zone. I'd test this by standing up a series of name server processes each with just one zone. You can have them on one OS but use multiple addresses (such as 127.0.0.2 127.0.0.3 and so on on the loopback interface with host routes), so long as they are separate processes. With this you'll see what name server implementations really do. It's the only way to isolate step 2 referred to above. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Vote for the word of the day: Paparazzi - father that constantly takes photos of the baby Corpureaucracy - The institution of corporate red tape ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Sanity check
I've come across a configuration in the wild where a given zone 'z' contains both a.z.NS some.name.server. *and* sub.a.z. NSsome.other.name.server. You're right, it's a mistake, but it is not my impression that registries make many semantic checks on the DNS records that their clients ask them to publish, since the range of errors is endless. So the response to a.z is don't do that. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Sanity check
On Thursday, October 27, 2011 10:06:25 Havard Eidnes wrote: I wonder if I could please have someone say whether they agree with me on this one: ... My claim is that it is a Registry Error for the operator of the registry for the 'z' domain to permit this to happen, as it violates the basic idea of what a delegation means. ... i'm +1 with this interpretation. not just because implementations do not all do the same thing in the presence of this data pattern, but because in recent decades we've adopted a mount point semantics view of dns delegations. this should be written down somewhere, because the rfc 1034 rules about scan down the tree looking for a delegation logic does not mesh well with the closest enclosure logic that most implementations actually follow. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Sanity check
In message 201110272103.38158.p...@redbarn.org, Paul Vixie writes: On Thursday, October 27, 2011 10:06:25 Havard Eidnes wrote: I wonder if I could please have someone say whether they agree with me on this one: ... My claim is that it is a Registry Error for the operator of the registry for the 'z' domain to permit this to happen, as it violates the basic idea of what a delegation means. ... i'm +1 with this interpretation. not just because implementations do not all do the same thing in the presence of this data pattern, but because in recent decades we've adopted a mount point semantics view of dns delegations. this should be written down somewhere, because the rfc 1034 rules about scan down the tree looking for a delegation logic does not mesh well with the closest enclosure logic that most implementations actually follow. RFC 1034 does mount point to find the zone (step 2) and scan down within the zone to find the delegation within the zone (step 3). It's when you try to merge multiple zones into one database and just scan down that you get problems (BIND 4 and BIND 8 did this and mangled the zone content in the process). RFC 1034, Section 4.3.2. Algorithm 2. Search the available zones for the zone which is the nearest ancestor to QNAME. If such a zone is found, go to step 3, otherwise step 4. 3. Start matching down, label by label, in the zone. The matching process can terminate several ways: The DNS has always had the concept of occulted data. Glue is occulted data and is only returned in referrals. You can't look for glue directly and it is visible in axfr. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
