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

[Peter Koch <[e-mail]>]

On Thu, Aug 05, 2010 at 12:04:00AM -0400, Andrew Sullivan wrote:

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

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.

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

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.

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

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

> 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

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