"sharedds" doesn't support validating stubs

[bemasc]

A non-DELEG-aware ("legacy") validating stub can only use records that carry a non-DELEG DNSSEC signature chain. This seems to be incompatible with the "sharedds" mechanism proposed in the DNSSEC draft.

It's also unclear how to construct a DELEG-aware validating stub, as DELEG records are not presently passed to the stub at all.

At present, I think the result is that any query to a recursive resolver with DO=1 would require the resolver to skip any DELEG records with "sharedds", and would create some very complicated caching questions. This seems like bad news for "sharedds".

[pspacek]

Can you define what kind of incompatibility you have in mind?

It seems to be that the old validators will go through "traditional" chain of trust like:

• .
• com.
• example.com.
• sub.example.com.
• www.sub.example.com.
  If the chain ends prematurely the legacy validator will conclude it's insecure - which might be a different status than secure result for DELEG-aware resolver.

The result is different but I don't see it as "incompatibility" - it's simply two alternative configurations.

If secure result is desired for legacy and new setups alike then legacy DS needs to be supplied - same as today.

What am I missing?

[bemasc]

If we assume that the intention is for these to be alternative configurations, then I can rephrase the concerns:

1. DS and "sharedds" cannot coexist at a delegation point (unless they indicate the same DNSKEY, in which case "sharedds" is not helping and should be removed), so they are mutually "incompatible". This makes a transition from DS to "sharedds" very challenging: a signed zone cannot adopt the new approach without going insecure for all legacy validators (whether stub or recursive).

2. Validating stubs in DELEG are currently unspecified and maybe impossible. In DELEG, a validating stub needs all the DELEG records, but has no way to get them, or even to know that it should try to get them.