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.uk New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
