Re: [dnsext] DNAME with exceptions - work-around found

[Brian Dickson <[e-mail]>]

Hi, Wouter,

Good point about the cache issue.

It took a day or two to investigate a bit further, but I think I have an
even dirtier trick...

Set the DNAME TTL to 0.

:-)

The DNAME only causes a problem in the cache, if it is in the cache before
the query for the more-specific exception is made.
Not caching the DNAME prevents this. (The best way to win a race is to not
have the race at all.)

This works, both directly, and through a cache. And it can be made to also
validate for DNSSEC, by the following process:

Use the same DNSKEYs for all the variants at each level (i.e. one set of key
for all the exceptions under one zone), and combining the (mapped) DS keys,
gets you the necessary delegation DNSSEC authentication/validation. The
DNAME rewrites the QNAME, but the returned values authenticate since they
are the same RDATA. (Yes, it's a cute and evil trick.)

For the variants (parent zones of the exceptions), each variant consists of
the apex RRs plus the DNAME, signed. Their DS records get inserted into the
parent zone(s).

The server for all the variants is also the server for the exceptions. All
of those zones are loaded.
The delegation server needs only the variants, and does not need to know
about the exceptions (yay!).
The delegations inside the variants, for the exceptions, don't actually
exist - they occur via the DNAME target zone, and are served up directly (in
response to appropriate QNAME/QTYPE/QCLASS matches).

This has been verified by trying it out using bind, on a couple of instances
talking to each other (recursive resolver and authority server). I *think*
it will also work with NSD... it doesn't require anything BIND specific. It
just abuses the RFCs. :-)

The targets of the DNAMEs get cached as needed, and thus the *only* thing
not cached are the DNAMEs themselves (and the synthesized CNAMEs, and their
RRSIGs).

So, if there were no other work done, and a registrant had need for this,
the main impact would be that the DNAME look-ups would not be cached, and
every variant look-up would propagate to the authority server(s) for the
registrant.

This suggests some kind of work, either specifically concerning the overall
"sameness" problem, or perhaps specifically to handle DNAMEs with TTL=0 (to
do something "special" to handle the scaling, while preserving the ability
to implement a work-around like this.)

I think that, performance hit on the DNAME aside, it scales pretty okay, but
obviously isn't something someone would want to run on a big (high-volume)
TLD.
It appears, at first blush, to support hierarchies of this kind with
exceptions at each level.
(It does require using common DNSKEYs among variants, but not among
parent/children relations.)

Brian


On Sat, Sep 11, 2010 at 5:34 AM, W.C.A. Wijngaards <[e-mail]>wrote:

>
>