On Jan 4, 2021, at 7:44 PM, Viktor Dukhovni <[email protected]> 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: > > !…*…-…0–9…A–Z…_…a–z…~ > > 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. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
