Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment

[Suzanne Woolf <[e-mail]>]

On Wed, Feb 16, 2011 at 12:40:12PM -0500, Andrew Sullivan wrote:
> This is why the SMTP and web server issues are such a big deal.  If we
> solve the problem that you only have to maintain one tree in the DNS,
> and everything else "just works", that is a completely meaningless
> victory if you nevertheless have to maintain all your SMTP and web
> servers by hand and keep them up to date about the aliases.  The work
> to keep the DNS in sync here is trivial compared to everything else.

Re-reading almost all of the history all at once, this strikes me as
the emerging key point: we started with registry issues, where
scalability of provisioning was the driver for opening the discussion.

But it's not clear that we can help registry operators with benefit
also to applciations writers, or to network operators (Alex's comment
about protocol perversions that rely on DNS lookups to fail in order
to frame a query that wlil succeed, which are always with us but which
we should hardly be encouraging).

I'm comfortable with the assertion that making life easier for
registry operators isn't worth doing if it makes life harder for
applications writers, at least for purposes of argument in the draft.

But: might helping registry operators (i.e., people who run
authority-side servers) without helping anyone else be worth the
effort? I haven't reviewed the draft lately but clones, IIRC, are
based on server-side synthesis of "the same RR you would have gotten
if the aliased zones were fully enumerated". Useful enough?

I *think* Andrew's text above says no, we can't reasonably help
registry operators if we leave applications with the same problem they
have now (knowing for themselves that string $x needs to map to string
$y). But rather than argue with something he may not have actually
said, I'm looking for further comments on this point.

thanks,
Suzanne
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext