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

[Phillip Hallam-Baker <[e-mail]>]

The problem here comes in that the downstream server needs to be prepared to
support the scheme. And there can be multiple levels of ambiguity so the
cache requirement grows exponentially with each level.

I am starting to get a really bad feeling about the resolve the same
requirement. Is the objective here really to make things work better or did
the authorities that raised this in ICANN have a rather different agenda?




On Thu, Feb 24, 2011 at 12:00 PM, Nicholas Weaver <[e-mail]
> wrote:

>
> 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)
>
>


-- 
Website: http://hallambaker.com/

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