tagged DS records (was: one approach to handling DS)

[Sam Weiler <weiler+lists.dnssec@watson.org>]

DS Record Legacy Resolver Support (Tagged DS Records), or
This Time We Mean It: DS Lives at the Parent


As Ed said, these problems stem from legacy code not being able to
determine the correct authority for DS records.  One class of
solutions is to mandate that every resolver/cache/proxy along the path
be not only DNSSEC aware, but also DS aware.  Such a requirement is
likely to be a burden on backward compatibility that significantly
adds to the problem of getting DNSSEC deployed in the public internet.
Another class of solutions addresses the fundamental problem of legacy
resolvers knowing to find DS records.  This is only one possible
solution for the specific problem, details can vary, and other ideas
are welcomed.

One fix is to change the label on the DS record so that legacy code
properly determines that it is in the parent zone.  This not only
eliminates the lameness, grandparent, and DS-timeout before NS-timeout
problems already identified -- it dodges the "fundamental change" that
caused them.  We discovered the basic lameness problem in DC in late
August.  It took two more months to find the grandparent problem.
There's always the possibility that we've missed more nasty fallout of
the "fundamental change" -- this avoids digging ourselves into a deep
hole.

I propose adding a tag to the label on DS records.  For example, a
parent zone might contain:

$ORIGIN example.
child		NS	ns.child.example.
		NXT     delta.example. NS SIG NXT DS
		SIG	NXT ...
_ds_child	DS	...
		SIG	DS ...

Adding the tag allows legacy code to clearly see that the DS is in
the parent zone. 

In all respects, tagged DS records are treated as though the tag were
not present.  DS-aware authoritative servers MUST return the tagged DS
record exactly when it would be returned according to [DS].  Tagged DS
records are not sorted separately using the rules in Section 8.2 of
[2535].  Instead, tagged DS records are sorted as though the _ds_ tag
were not present, and the presence or absence of a DS record is
reflected in the delegation NXT bitmap.  This avoids needing a
separate NXT/SIG to show if the delegation is secure or not.

Similarly, if a query is received for a non-existent DS at an
existent delegation, the negative answer should be:

Query: _ds_insecure.example DS 
Answer: insecure.example NXT secure.example. ...
			 SIG NXT ...

For a non-existent name, the NXT returned must cover the label as
though the _ds_ tag was not present.  As DS records can only exist at
a delegation, and wildcards cannot be delegations, no proof of
wildcard non-existence is needed.

Query: _ds_nonexistent.example DS
Answer: insecure.example NXT secure.example. ...
			 SIG NXT ...

There may be cases where cache-poisoning prevention code rejects a DS
record attached to a referral since the name on the DS does match the
name on the NS.  In those cases, a DS-aware resolver will see the DS
bit in the NXT bitmap and can query explicitly for the tagged DS
record.  This is the only case where this change results in more
queries.

This does (minimally) limit the DNS namespace.

This solution makes it more likely that a resolver without a "clear
path" to authoritative servers will be able to get DS records. 

This solution addresses all of the cases Ed enumerated:

Case 1 (all DS aware): c zone (upper srvr) returns a referral to bc.
The lower srvr answers.

Case 2 (parent (lower srvr) is DS unaware): lower srvr returns
NXDOMAIN.  It could also be argued that if you're following a secure
chain from zone c, all servers for bc should be DS aware.

Case 3 (only the cache is DS unaware): the cache, using old logic,
correctly finds the DS.


Footnote: 

The exact tagging byte(s) can be argued later.  I prefer printable and
readily typable characters, even if it means a longer tag.  I've heard
NULL suggested, and I've heard ctrl-A suggested.  We can argue about
this later.  To be clear, the bytes(s) cannot be (in) a prepended
label (ie. _ds_.child.example), since that would be in the child zone.