On Fri, Jun 12, 2015 at 01:54:50AM +0100, Tony Finch <d...@dotat.at> wrote a message of 44 lines which said:
> (end) I do not completely agree with the change but I hope I was able to address your concern. See the diff in <https://github.com/bortzmeyer/my-IETF-work/commit/ac7615473d448b315da590f0b7f552a44fbb599a> New text quoted here: The minimising resolver works perfectly when it knows the zone cut [RFC2181] (section 6). But zone cuts do not necessarily exist at every label boundary. If we take the name www.foo.bar.example, it is possible that there is a zone cut between "foo" and "bar" but not between "bar" and "example". So, assuming the resolver already knows the name servers of .example, when it receives the query "What is the AAAA record of www.foo.bar.example", it does not always know where the zone cut will be. To find it out, it will query the .example name servers for the NS records for bar.example. It will get a NODATA response, indicating there is no zone cut at that point, so it has to to query the .example name servers again with one more label, and so on. (Appendix A describes this algorithm in deeper details.) Since the information about the zone cuts will be stored in the resolver's cache, the performance cost is probably reasonable. Section 6 discusses this performance discrepancy further. > (I can't see anything that describes a way to find a zone cut in RFC > 2181 Text deleted. > Regarding the last paragraph of section 6, I think the IPv6 reverse > DNS is the best place to find names with lots of labels but few zone > cuts. It is indeed mentioned. That's the only real-world example. There are other in the XML comments of the source file: they were in the text before but I've been told that using actual domain names for examples in stable documents like RFC was dangerous (there was a zone cut between gouv and fr in gouv.fr a few years ago...) _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
