[dd] Re: Security Considerations: NS Weaker Than DELEG

[Havard Eidnes <[e-mail]>]

>> I'm otherwise with you that the protocol itself should not
>> mandate NS record presence in all zones, be that human-maintained
>> or synthesized, any more than the cautionary notes now in section
>> 6 in draft -07.
> 
> I'm curious since you expressed a related opinion above what
> you think about what I've said previously regarding the danger
> (as I see it) of name errors propagating through resolvers,
> forwarder and application caches.
>
> Do you have a solution in mind that avoids my concern in order
> to achieve what you say above, or do you think my concern is
> unwarranted?

I can't claim that all my utterances have been 100% self-consistent,
sorry...

That said:

The concern about NXDOMAIN propagating from a non-DELEG recursive
resolver to a "downstream" DELEG-aware recursive resolver is, I
beleive, diminished or eliminated by declaring such a setup to fall in
the "do not do that" category: if you need to configure a DELEG-aware
recursive resolver with a forwarder, it is up to you as a DNS resolver
administrator to ensure that the pointed-to upstream recursive
resolvers are all DELEG-aware.  Said with other words: configuring a
DELEG-aware recursive resolver to use a non-DELEG-aware recursive
resolver as forwarder is a "deployment error" and is "not supported".
"You're threading on ground outside the standard, and do not be
surprised that bad things might happen, e.g. some parts of the name
space which are DELEG-only delegated may spuriously(?) become
unreachable."

The mental model I have which justifies NXDOMAIN in the non-DELEG case
for a name in a DELEG-only zone is that the publishing name servers
need to present a view to the non-DELEG-supporting recursive resolvers
of the DNS name space which is consistent with the DNS as if the DELEG
record "has no special properties", in particular, "has no name space
delegating" properties, in other words, behaves as any other "unknown"
RR type.  A non-DELEG-aware recursive resolver can never look up names
residing in a DELEG-only zone, and the NXDOMAIN is a cacheable signal
that there is no point in trying.

> Related, in draft-ietf-deleg-requirements we see:
>
> S5. DELEG should allow for backward compatibility to the
> conventional NS-based delegation mechanism. That is, a zone operator
> who wants to maintain a single source of truth of delegation
> information using DELEG should be able to easily have Do53
> delegations derived from it.

Are we fully agreed that this needs to be a protocol mandate?

From a protocol perspective, the zone administrator may register both
NS and in parallel DELEG records which express the same method of
delegation, but that does not *need* to be something the protocol
provides, but can instead be solved at the implementation or
administrator interface level.

Some might claim that allowing parallel publication of DELEG and NS is
the asked-for "backward compatibility".

It's also worth noting that if DELEG should express exactly the same
as what NS does, what is then the point of having the DELEG records
there in the first place?  (I'll claim "very little".)

On the other hand, if the zone owner wants to start pushing for secure
transport to DNS publishing name servers, that is something which
cannot be expressed with NS records, so in that case you cannot have a
"single source of truth" for those two delegation mechanisms.


I don't know, it's all sort of a hot mess...


Regards,

- Håvard