Re: draft-yao-dnsext-identical-resolution Re: [dnsext] DNSEXT sessions at IETF 78

[Brian Dickson <[e-mail]>]

On Tue, Jul 20, 2010 at 2:17 PM, Suzanne Woolf <[e-mail]> wrote:

> On Mon, Jul 19, 2010 at 01:39:27PM +0000, Florian Weimer wrote:
> > * Suzanne Woolf:
> >
> > > 4. Other concerns?
> >
> > I don't think pseudo-equivalence based on non-canonical names will be
> > good enough because canonical names cannot be used in some places (and
> > software actually enforces that).
>
> Examples? Send text :)
>
> > This comes pretty close to a requirement for complete
> > interchangeability.
>
> Then we have to figure out where it applies and where we can get away
> with a more relaxed requirement. As the draft already notes, all of
> the proposals we currently have treat one name as "canonical" or
> "preferred" and others as "aliases" or "variants"-- a one-way,
> asymmetrical transformation. "Shadow zones" comes closest, but one
> domain is still designated "the domain being shadowed" and the others
> are "shadows" of it.
>
>
There was a suggestion I raised earlier, for a method similar to, but
significantly different from, shadow zones...

(Given the volume of discussions, it's easy to miss new ideas or solutions.)

The idea doesn't specifically require any changes to the protocol, only to
the implementation methods.

It involves the idea of the equivalent to a "hard link" in the filesystem
analogy (an analogy which quickly breaks down, unfortunately).

The basic issues with [bcd]name et al, are that they are "client-side"
aliasing. The resolver sees the [bcd]name (or in some cases a synthesized
*name), and chases that down.

The idea of hard-linking zones, involves having the "server-side" being
aware of the aliasing, and in fact literally hard-linking zone data.

Given two names to resolve, foo.ex1.example.com and foo.bar.ex2.example.com,
we want to have zone "foo" underneath ex1.example.com be linked (and thus
identical) to "foo" underneath bar.ex2.example.com.

On the "upstream" side, the delegations for both ex1.example.com and
bar.ex2.example.com, point to the same NS set. They are ordinary, regular
delegations (optionally with suitable DNSSEC stuff like DS et al.)

The "magic" happens on the nameservers in that NS set. The nameservers serve
up data which is not only identical, but literally linked (e.g. using
pointers to the same data structure, from the different zone names). The
linking avoids the need to maintain duplicate data, and the corresponding
size bloat (exponentiation is not your friend.)

Obviously, some implementations would need slightly non-trivial changes,
e.g. NSD having the entire answer ready-to-go; it would need to concatenate
two pieces of data (the non-unique zone "name", joined with the relative
name within the zone and the RDATA).

On the plus side (and I think this a HUGE plus, especially for the likes of
MX), the clients don't need to be changed, and in fact are compatible back
to the earliest implementations, as far as I can tell. If they understand
zone delegation, it works for them.

The down side is that some new logic is likely needed to allow DNSSEC
signing to not require signatures from all possible SEP (secure entry point)
signer names for a given zone. Perhaps allowing for "null" values of signer?
I'm not sure what implications this has on the relative strength of signing,
or other aspects of keys/signing/etc. Unchanged DNSSEC behaviour is unclear
to me - I suspect "insecure" rather than "bogus", which I think is pretty
reasonable.

The DNSSEC issue is a potential can of worms, but the length of the tail
(i.e. number and age of DNSSEC validators, vs number and age of DNS
resolvers) is significantly shorter, and arguably leads to easier
justification to incorporating this method as ONE of the methods to
consider.

IMHO, we don't need to go either/or on these ([BCD]name, shadows,
hard-links), as long as some combination of the methods available are able
to meet all the requirements we have identified.


> Some of the folks who have contributed to this discussion as it's
> evolved to this point have some convincing arguments that a
> "requirement for complete interchangeability" can't be met in the
> current DNS or, depending on how it's stated, at all. Let's be careful
> with this one.
>
>
Agreed - but let's also give thought to exploring methods that can provide
complete interchangeability, if/when we identify them.

Brian