[dns-operations] [Ext] Signing on the fly and UltraDNS
paul.hoffman at icann.org
Tue Jan 5 04:52:07 UTC 2021
On Jan 4, 2021, at 7:44 PM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> On Tue, Jan 05, 2021 at 02:39:27AM +0000, Paul Hoffman wrote:
>> Greetings again. Those of us who research DNSSEC adoption in the real
>> world are being a bit stymied by some of the sign-on-the-fly systems,
>> such as this one, apparently from UltraDNS. (Similar results are given
>> for any nonexistent name in house.gov, such as "www1".)
> These are certainly *interesting* choices, but the result is a valid
> denial of existence, which for some reason chooses to optimise to defend
> against zone walking (of a zone whose content is entirely predictable,
> and likely a matter of public record, ...), rather than improved
> negative caching. Not a choice I'd make for this zone, but on a purely
> technical level, the proofs work.
> If the zone is known a priori to only contain regular LDH names and the
> occasional "*" or "_", then the possible character range of "real" names
> is a subset of:
> with the two endpoints excluded. In which case, any actual successor,
> in lexical order, of some label "foo" (<62 octets long) sorts after
> "foo!", and its predecessor sorts before "~.fon~".
>> ~.anynameyouwans~.house.gov. 882 IN NSEC anynameyouwant!.house.gov. RRSIG NSEC
>> !~.house.gov. 882 IN NSEC -.house.gov. RRSIG NSEC
> Consequently, these choices are largely rational, whether they're
> "optimal" is a matter of what one chooses to prioritise.
That all seems correct. However, I brought the issue to this mailing list, instead of to the UltraDNS folks, because I am using tools that expect host names instead of domain names (in this case, dig); now I have to write shims around them. Other signing-on-the-fly mechanisms might cause similar issues for dig or other tools.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2584 bytes
Desc: not available
More information about the dns-operations