Subject: Re: [BEHAVE] DNS64 reverse

From: Mark Andrews <[email-masked]>
Date: Sat, 01 Aug 2009 17:18:51 +1000

In message <[email-masked]>, Andrew Sullivan writes:
> On Sat, Aug 01, 2009 at 07:54:31AM +1000, Mark Andrews wrote:
> > 	You made this way to complicated which is why I suggested the
> > 	CNAME in the first place.
> 
> I am willing to countenance a charge that I've made it more
> complicated than you think necessary.  Perhaps just synthesizing the
> CNAME is indeed trivial (though I think you're waving away some of the
> steps I outlined without admitting that you have in fact to do them).
> But …
> 
> > > to be _that_ bad, so it's by no means impossible.  But it's more
> > > complication in an already fragile and complicated mess that we're
> > > creating just as a transition strategy.
> > 
> > 	FUD
> 
> … I am not willing to stand for that.  What I am saying is not FUD,
> it's simply asking whether a given trade-off is worth it.  It's fun to
> point and laugh at people we disagree with, but that isn't an
> argument.

Your making it out to be much harder that it is.  You are over
estimating the difficulty.  Named already does something like this
to authorise UPDATES in the 6to4 range.  It digs the IPv4 address
out of the UPDATE request and matches it against the source address
of the UPDATE as well as checking that it is coming in via TCP.

Doing this was trivial.  Doing a similar thing with queries is
trivial.
 
> I know you happen to like the reverse tree, and think everyone should
> maintain it.  I do too, and I wasted a great deal of time on a
> document that ended up practically stating an analytic truth but that
> still couldn't find consensus.  We lost that battle, story's over,
> let's move on.

This isn't the same thing.  This is like deprecating RFC2317.  This is
the method not the data.

> So, by supporting int6.arpa/in-addr.arpa strategies, we're adding yet
> more complication to a strategy that is, bluntly, a way to lie
> consistently in the DNS.

If it was just a way to lie consistently in the DNS we should not be
doing it.  It however is not just that.

> If you thnk that's not a fragile and
> complicated mess, bully for you; but I don't think it's in itself a
> good thing.  Obviously, if I didn't think it was the right trade-off,
> I wouldn't work on it.  That doesn't mean I want to do anything more
> here than the bare minimum we need to do in order to get the support
> that people need.  I am asking quite seriously whether the reverse
> tree is worth doing anything to support, given that it is in fact one
> more step.

It is a small step.  Today I run netstat on my machines and I find
it mildy annoying that I can't see what my machine is talking to
in a human friendly form (names).  I provide that information for
others.

Note this really isn't something that can be done another way if
the manufacturers don't provide the mapping tools.

Your example of a request to not pre-populate the reverse space in
dnsop is not the same thing as there are lots of alternative methods
to supply the data if one wants to.  It's comparing apples to
oranges.
 
> But if other implementers also weigh in with, "Yes, this is trivial,"
> I am not unwilling to change the draft to reflect that.
> 
> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]