[dnsext] does making names the same NEED protocol changes at all?

[Nicholas Weaver <[e-mail]>]

On Feb 24, 2011, at 5:52 AM, Nicholas Weaver wrote:

> 
> On Feb 24, 2011, at 5:44 AM, Phillip Hallam-Baker wrote:
> 
>> So you are saying that it is TOO LATE to make a change that would have major impact on the practice of domain management?
> 
> I'm stating that your "nobody validates DNSSEC" claim is demonstrably false.

More precisely, there is a large ISP, Comcast, where ALL users who've opted out of NXDOMAIN wildcarding are behind DNSSEC validating resolvers.  I would call this a significant operational deployment of DNSSEC validation.



However, back to the original topic: why does case insensitivity for non-ASCII NEED protocol changes?  Can't it be done with just authority changes for only those authorities needing case insensitive non-ASCII names (rather than a protocol change which needs universal changes to the resolvers)


The authority has a standard mapping for case insensitivity in the language in question.  

a: If its the terminal authority for a name, it just runs the mapping and returns the value (if necessary, generating a DNSSEC signature on the fly if its an uncached mapping).

b:  If the authority is not a terminal, and it knows that the authority directly beneath it for a name support case insensitivity, it just runs the mapping and returns the appropriate value (if necessary, generating a DNSSEC signature on the fly if its an uncached mapping).

c:  If the authority is not a terminal, and it does NOT know that the authority directly beneath it supports case insensitivity, it runs the mapping to generate a canonicalized DNAME or CNAME (as appropriate) with TTL=0 and, if necessary, generates the appropriate signature.


Cases A and B Just Work (tm).  

Case C will work as well because you don't have the CNAME + DNAME problem because the TTL is 0.  Case C may reduce caching and also increase latency, but that is ONLY network load on the authority not computation load (because the DNSSEC signature is cached), and creates an incentive for the authority directly beneath to support case-insensitive names.


NO DNS protocol changes are required, everything is provisioning and authority side changes.


By maintaining a cache of signed data, the reality is although it supports effectively exponential case-recasing, the ones which are actually used get in the cache.  If the cache is well structured and sticky, a computational DOS won't be able to evict valid entries (limiting its effect to only new BizArrE caSeS of TyPogRaphy)

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext