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

From: Suzanne Woolf <[email-masked]>
Date: Fri, 16 Jul 2010 00:44:04 +0000

On Thu, Jun 24, 2010 at 09:24:14PM -0400, Andrew Sullivan wrote:
> The other session is a one hour session aimed just at the topic of
> aliasing, and in particular at gathering more requirements,
> objections, corner cases, worries, and so on about this topic.  It is
> primarily aimed at requirements gathering, which means that any
> telling anyone what is simply impossible in the DNS won't be allowed.
> The point is not, in this session, to say what we can or can't do, but
> to try to get straight as much as possible all the issues that people
> have with aliasing, what doesn't work, what does, what current
> behaviour people rely on, and so on.

In the interests of moving the "aliasing" discussion forward, see:

http://datatracker.ietf.org/doc/draft-yao-dnsext-identical-resolution/

The -00 draft was the work of Jiankang Yao and Xiaodong Lee, to which
I added a bunch of stuff taken from the namedroppers archives and the
discussions we've already had. The document is just a beginning but is
intended to be the place where this requirements-gathering exercise is
archived; ultimately it will either explain why we're doing whatever
work the WG takes on in this area, or explain why we decided there's
nothing that DNSEXT can usefully do.

Questions: 

1. What else does it need, besides more specific use cases?

2. Should it be a WG document? It currently isn't, and I'll be asking
that it be adopted.

3. The -01 draft plays fast and loose with a great deal of
terminology; we don't have good terminology for the analysis we need
to do here. How do we get to a more rigorous agreed-upon vocabulary
for talking about these issues?

4. Other concerns?

Suzanne

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 16 Jul 2010 09:56:27 +0100

On 16/07/10 01:44, Suzanne Woolf wrote:
	[...]
> nothing that DNSEXT can usefully do.

	Good work, Suzanne!
	It's great to see this revision out.

> 1. What else does it need, besides more specific use cases?

	I'ld suggest adding just one more: the one presented by
	Paul Vixie at the interim meeting (February 2010, was it?),
	unless Paul has an objection. This will make it clear to
	readers that motivations may arise other than those driven
	by character variants.

	It may be opportune to refer to other character-variant-based
	use cases, should any come to notice as this draft advances.
	I expect that detailed exposition of these use cases will not
	be necessary in the absence of significant specific features
	which somehow distinguish such a case from either the Han or
	Greek "prototypes".

> 2. Should it be a WG document? It currently isn't, and I'll be asking

	Absolutely.

> for talking about these issues?

	Make a snag list.
	Address each snag in section 1.3.
	Consider promoting 'Terminology' to new section 2
	and renumbering the rest.

> 4. Other concerns?

    4.a	I suggest taking advantage of this document to move
	remaining motivational material out of the BNAME and
	CLONE drafts so that these can be kept "technical".
	I've held off on suggesting changes to these until
	the current draft had appeared.

    4.b	I feel that more care is needed in choosing whether
	to refer either to a name or to a label, not just in
	the draft, but in all our thinking on what "sameness"
	means.

	Justifiably, someone will reply, "Send text."
	Yes, I must. 8-)

	0,02
	/Niall

---

From: Florian Weimer <[email-masked]>
Date: Mon, 19 Jul 2010 13:39:27 +0000

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

This comes pretty close to a requirement for complete
interchangeability.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 20 Jul 2010 16:34:52 +0800

----- Original Message ----- 
From: "Florian Weimer" <[email-masked]>
To: "Suzanne Woolf" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 19, 2010 9:39 PM
Subject: Re: draft-yao-dnsext-identical-resolution Re: [dnsext] DNSEXT sessions at IETF 78

>software actually enforces that).

two names are fully different. without some configuration, the software will not know it.

the software will not automatically know it.

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 20 Jul 2010 17:17:27 +0000

> software actually enforces that).

Examples? Send text :)

> This comes pretty close to a requirement for complete

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.

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.

best,
Suzanne

---

From: Brian Dickson <[email-masked]>
Date: Tue, 20 Jul 2010 15:25:36 -0300

> domain is still designated "the domain being shadowed" and the others
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.

> current DNS or, depending on how it's stated, at all. Let's be careful
Agreed - but let's also give thought to exploring methods that can provide
complete interchangeability, if/when we identify them.

Brian