Subject: [dns-dir] DNSEXT charter and treating DNS names as "the same"

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Aug 2010 00:04:00 -0400

[NOTE: Olafur & I send this to the directorate for comment before we
send it to the WG.  If we hear nothing by Friday afternoon, we'll send
this to the namedroppers list, and also send it (maybe with a
background note) to the APP and INT area discussion lists.]

Dear colleagues,

One of our primary goals for DNSEXT at IETF 78 was to get feedback
from the user community (in particular, application developers) who
have the "aliasing" and "sameness" problem(s) with the DNS.
Unfortunately, we were unable to attract many such participants. 

It is clear to us that none of the proposals now before DNSEXT
addresses all the problems that people have.  As far as we are able to
tell, there are needs with respect to domain names, with respect to
whole trees in the DNS, and perhaps with respect to individual labels
no matter where they might appear in a domain name.  None of the
proposals handles all of these, and some of these needs are not
addressed at all.

We appear to be faced with a choice among three basic strategies:

    1.  Experiment: Since we don't know what the problems are, but we
    have people proposing solutions, we could adopt the proposed
    solutions experimentally, and evaluate in (say) five years whether
    the proposals solved the problems people have.

    2.  Limp along: We could accept that no proposal will solve
    everything, and "limp along" by standardizing properly the
    proposals we have, working towards clarity and precision in the
    problem statement and then proceeding to work on the proposals
    themselves.

    3.  Kick it upstairs: A basic problem in all of this is that the
    DNS does not have a presentation layer.  Domain names end up being
    used in presentation contexts, and that's what's broken.  So, we
    could say that there is no problem here for the DNS, but that we
    are ready and willing to support building a presentation layer
    atop the DNS.  Such a specification needs to come from elsewhere.

The problem with (1) is that some of the proposals are simply
impossible to do as experiments (if we change the rules for CNAME,
they're effectively changed forever whether we like it or not).  In
addition, we think it would be a very bad idea to perform such an
experiment in the root, but we expect that there would be operational
pressures to do so.

The problem with (2) is that we make the DNS more complicated without
solving all or perhaps even most of the problems people really have.
The complication will be greater than many people seem to think: for
instance, the BNAME proposal as it is currently written is, as far as
we can tell, simply incompatible with all the deployed validators in
the world.  That seems like a problem that needs addressing, and we
can't see how to do so easily.

The problem with (3) is that it was suggested before, and got no
traction.  Moreover, it's very complicated, such that the work might
never complete; and in the meantime, people who have a problem have no
help.

We DNSEXT chairs are mostly convinced that there is no current
proposal that is any simpler than just duplicating zone apex data and
adding a DNAME to the "alias" zones.  (This suggests an option 4,
which is "document how to do this by provisioning, thereby explaining
why the WG is not doing anything else.)  Before we propose another
charter for the WG, we'd like to hear more arguments why any work is
needed, and which of the options 1-3 seem like the best bet for that
work.

Best regards,

Andrew and Olafur

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 5 Aug 2010 07:26:15 +0200

I think this is fine. I still feel the title of the draft of Suzanne makes sense, and the problem I see is the following:

Given that someone has decided that resolution of A and B (and children of A and B) should result in the "same thing", how should the domain holder implement that?

Just by provisioning? Works if the there is the same registry for A and B, but otherwise it is very difficult.

I think personally your alternative four is probably "good enough for now" until we have more data. The problem in the live is that too many people still say "DNAME is dangerous -- do not use it" but I have not really seen any real evidence for problems with DNAME, specifically if one say DNAME is to be implemented only within one zone and similar restrictions. And of course it is easier when we have the push for DNSSEC.

So I think your note is good.

   Patrik

On 5 aug 2010, at 06.04, Andrew Sullivan wrote:

> _______________________________________________
> dns-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-dir

---

From: Peter Koch <[email-masked]>
Date: Fri, 6 Aug 2010 15:25:22 +0200

> Unfortunately, we were unable to attract many such participants. 

agree with the observation, but I'm not convinced that "application developers"
are really the ones pushing the requirement of "sameness" or "equivalence".
Unfortunately this is a layer9 more than a layer7 problem.

>     problem statement and then proceeding to work on the proposals

Not sure I understand: first put the three proposals on standards track,
then publish the problem statement and then revise the proposed standards?
That's never going to happen.

> experiment in the root, but we expect that there would be operational

Smells MARID a bit, but may be a way out. On the detail level,
Experimental vs Informational can be argued.
"shadow zones" as it stands mixes data and control plane and
could interfere with upcoming work on the "name server control protocol".
Also it is unclear to me what 'adopting this draft' would actually mean
for the direction of work.
On "change the rules" it should be pointed out that these rules have
protocol or operational reasons and can't just be changed at will.
I'm not saying this wouldn't work in the CNAME+DNAME case, but it still
needs some consideration beyond "works for me".

> why the WG is not doing anything else.)  Before we propose another

I think this should be elevated to a real "option 4".

So, for a DNS audience I think this is a fine summary.  For other
audiences it might be good to give some background (see above) and
to (once more) try to gather real problem descriptions/requirements.

-Peter

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 10 Aug 2010 09:08:31 -0400

> That's never going to happen.

No.  There should be a colon after "have" instead of a comma.  Sorry.
I'll fix before posting.

Thanks for the comments, both you and Patrik.

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.