On 07/14/2012 14:05, Joe Abley wrote:
>
> On 2012-07-14, at 16:50, Doug Barton wrote:
>
>> I would argue further that a child NS set which is a superset of
>> the parent is not lame, or broken. There are valid reasons to do
>> this, (outside the scope of this document, certainly) and I'd hate
>> to see this instantiated as "an RFC violation" as a side effect.
>
> Or a subset, or a completely different set.
The subset you can usually get away with, (assuming, as you have, that
the omitted server actually answers authoritatively for the zone) but in
practice that's a meaningless exercise because so many resolver
implementations will continue to query the server if it answers
authoritatively.
The "completely different set" case is a whole different can of worms,
and is likely to cause damage. (Both of these observations are based on
my experience.)
> The relative sizes of the
> NS sets and the size of the intersection is not really relevant; the
> important thing for resolution is whether the union of both sets
> contains lame servers.
My experience tells me differently regarding the 2 cases you mention
above. However, you'll note that the text I proposed does take what you
wrote into account when the child set is identical or greater than the
parent set.
> Any new work which needed to assert that both sets were the same
> would meet with little objection though, I think.
It's already met with at least 2 objections, so I'm pretty sure you're
wrong. :)
> It's
> commonly-shared wisdom that both sets should be the same, and "are
> consistent and remain so" (RFC 1034 section 4.2.2) is fairly clear.
Sure, that's the ideal, and I always advise people to "make it so."
However 25 years after 1034 was written we know quite a bit more about
how DNS works in the real world, and the case of the child zone having a
superset of NS records is a real, valid configuration.
Doug
--
If you're never wrong, you're not trying hard enough
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
