Subject: [BEHAVE] DNS64 reverse

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Jul 2009 17:53:36 +1000

A DNS64 server SHOULD synthesize a CNAME which maps from
	the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA
	name.  The rest of the response would be the normal DNS
	processing.

	The CNAME can be signed on the fly if needed.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Jul 2009 04:14:36 -0400

On Tue, Jul 28, 2009 at 05:53:36PM +1000, Mark Andrews wrote:
> 	name.

Why?

There are three possibilities for the IP6.ARPA query.

The first is that the query is for a QNAME that corresponds to a live
IPv6 address actually in use somewhere on the Internet.  In this case,
of course, it should be left unmolested.

The second is that the query corresponds to a range of addresses that
the NAT64/DNS64 systems are using.  That range is, by definition, a
range actually under the control of the operator running the
NAT64/DNS64.  So that operator is authoritative for the range, and in
an ideal world would have the reverse tree delegation appropriate.
Therefore, the operator should answer for that range, and may do so
authoritatively.  

The third is that the query corresponds to a range of addresses
covered by a well-known prefix that is designated to be used for
NAT64/DNS64 systems.  This is analagous to the QNAMEs corresponding to
RFC1918 addresses.  We already learned that the right thing to do in
such cases is not to let those queries leak -- I don't think we want
to continue to expand the scope of AS112 responsibilities.  Therefore,
QNAMEs corresponding to such a range should be caught and answered
authoritatively.  

So what is the advantage to be gained by adding the complication of
synthesized CNAMEs (and signing on the fly), given that we have
evidence that the reverse tree is widely broken anyway? 

A

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Jul 2009 18:42:38 +1000

> of course, it should be left unmolested.

	Sure.  It's for the reverse namespace that corresponds to the
	addresspace being used by the NAT64.
 
> Therefore, the operator should answer for that range, and may do so

	To get useful responses the server need to translate the
	query.  You can either hide the translation and in the
	process hide the real authority of the data or you can make
	the translation visible (via a CNAME) and make the real
	authority of the data visible.

	In either case the server is ends up synthesizing a query.

> QNAMEs corresponding to such a range should be caught and answered

	A well know prefix should be treated like we do mapped
	addresses today in getnameinfo().  It just ends up being
	another namespace that gets translated at the application
	layer.

> _______________________________________________
> 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]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Jul 2009 05:23:40 -0400

> 	addresspace being used by the NAT64.

The case I was thinking of here is real IPv6-enabled namespace.

> 	query. 

Define "useful responses".  To use the reverse-mapping-considerations
language, do you think a "useful response" is _matching_ reverse data,
or just _existing_ reverse data?  The latter is solved by just
answering the query authoritatively.

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Jul 2009 19:28:39 +1000

> answering the query authoritatively.

Useful.  Gets the name associated with the IPv4 address if available.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Jul 2009 05:34:55 -0400

> Useful.  Gets the name associated with the IPv4 address if available.

But the client doesn't have an IPv4 address that it's looking up.  It
has a v6 address, and the site operating the NAT64 can authoritatively
answer all reverse queries for things in that range.  

What is the value that comes from being able to get the name
associated with the IPv4 address that was the basis for translation?
And is that value great enough that it's worth doing things like
signing on the fly and synthesizing CNAMEs on the fly?

A

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Jul 2009 20:22:22 +1000

> answer all reverse queries for things in that range.  

It's authoritatively answering with CNAME's then following them
usually.  The CNAMEs are being generated on the fly but it is also
authoritative for them.

What it is not authoritative for is the rdata of the PTR record.  It
doesn't own that data.  If you hide the translation you hide the real
owner.

Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Jul 2009 06:48:16 -0400

> doesn't own that data.  If you hide the translation you hide the real

This is precisely the claim I am denying.  The DNS64 _is so_
authoritative for the PTR data in its Pref64::/n, in much the way that
a local nameserver answering for RFC 3330 addresses is authoritative
for those answers.

A

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

---

From: Dave Thaler <[email-masked]>
Date: Tue, 28 Jul 2009 11:59:36 +0000

I have to agree with Mark here.

For example, consider the scenarios:
"IPv6 Internet to an IPv4 network"
"an IPv6 network to an IPv4 network" (where both are managed by the same
   organization)

In this case, the DNS64 is hosted by the same org as the authoritative
server.  If the org still wants to run a DNS64 For various reasons
previously discussed (i.e., when it's impractical to get AAAA records
into the authoritative DNS servers).

The clients expect to get the same answer when they're in the IPv4
network as when they're on the IPv6 side, especially in the
"an IPv6 network to an IPv4 network" scenario.  Giving a different
name back in the address-to-name mapping would violate the principle
of least surprise.

This is quite different from the typical use of a local network
answering PTRs for RFC 1918 addresses, since (in the typical use)
there's no global address that has the real name and hence there's
no other expectation... the local address really has the local name
as its real name.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Andrew Sullivan
> Sent: Tuesday, July 28, 2009 11:35 AM
> To: [email-masked]
> Subject: Re: [BEHAVE] DNS64 reverse
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Jul 2009 12:00:20 -0400

On Tue, Jul 28, 2009 at 11:59:36AM +0000, Dave Thaler wrote:
 
> "an IPv6 network to an IPv4 network" scenario.

Really?  I submit that this is a condition that is broken _all the
time_ in actual networks today.  There is ample evidence that
attempting to do anything beyond, "Is it there?" (and maybe using for
logging) with reverse data is already bordering on insanity: too many
people are hostile to it.  Moreover, IPv6 deployers are right now
asking for an explicit statement from DNSOP that it's perfectly fine
for there to be nothing as a result of a PTR query for an
obviously-existing address.

Someone who can't figure out how to put AAAAs into their (presumably
split-brained) zones for their own translation purposes is surely not
going to be trying to match forward and reverse data for any purpose,
are they?

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

---

From: Dave Thaler <[email-masked]>
Date: Tue, 28 Jul 2009 16:52:20 +0000

> Sent: Tuesday, July 28, 2009 6:00 PM
> To: [email-masked]
> time_ in actual networks today.

I'd say "most of the time".  There may be networks where it isn't
broken and we shouldn't break it in such networks, in my view.
Specifically, the "broken" I'm referring to is not the same
as the "broken" you might be referring to... I'm not talking about
the existence/non-existence being different on the IPv4-only side
vs the IPv6-only side of the translator, I'm talking about
where the record exists on both sides, and it gives you different
answers even though sending traffic to an IPv4 address from the
IPv4 side gets you to the same host as when sending traffic to
the mapped IPv6 address from the IPv6 side.

> There is ample evidence that

Sure.  And personally I also agree it shouldn't be used for anything other
than logging and human readable display.  (Though there are always
folks who try.)  Even if it's just used for logging and human display
(e.g. ping etc. output), I would claim that's sufficient reason for
me to agree with Mark.

> going to be trying to match forward and reverse data for any purpose,

I've learned to not assume people in the real world are clueful :)

-Dave

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Jul 2009 06:47:05 +1000

> obviously-existing address.

	No.  It is a different question being asked.  Pre-population
	was always a bad idea but we didn't have the tools to do
	better.  We now have the tools and IPv6 it too big to
	pre-populate.  PTR records for active nodes are still needed.
	They just need to be supplied in a different manner.
 
	There is a difference between not supplying data and not
	supplying a method to get the data.  We should supply the
	method to get the data.  This requires code as the space is
	too big to  do otherwise.

> going to be trying to match forward and reverse data for any purpose,

	The tools already do it.

	Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 31 Jul 2009 16:33:45 -0400

> (e.g. ping etc. output), I would claim that's sufficient reason for

Well, this is exactly the moment when I ask whether the trade-off is
really worth it.  If we don't do anything special with PTR queries
except what a bog-standard recursive server ought to be able to do
today, that's a large chunk of code that doesn't need to be touched
(or tested).

If we do something with PTR queries, then we have to (1) capture PTRs
specially; (2) create a new class of reverse zone (the ones we have
are "the ones for which this server is authoritative" and "all the
rest", but now we'll also need "ones for which this server is not
authoritative but that need special handling"); (3) take apart the
in6.arpa QNAME and see whether it might actually map to a candidate
RNAME for the in-addr.arpa zone; (4) perform the necessary mapping if
(3) is right; (5) receive the result of the in-addr.arpa query and
take _that_ answer apart; (6) reassemble the result of (5) to go back
into the in6.arpa RNAME that matches the original QNAME; (7)
synthesize the CNAME as Mark suggests (or replace the answer, as
originally suggested); (8) return the result of this to the client.

I know that's sort of a painfully-described set of steps, and so it
probably seems rhetorically overblown.  Each of the steps doesn't seem
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. Also, there is quite a lot of
scope for operator error in configuring the feature created at (2).  I
don't think we should discount that.  Given that we're admitting that
nobody should really be relying on the reverse data anyway (because of
the already existing way it's administered, I am sad to concede), I'm
not sure the data is worth doing this work for.  (Note that a
participant in this working group showed up at DNSOP earlier this week
asking for a document that explicitly says, "It's just fine not to
populate the reverse tree."  And DNSOP already had a protracted civil
war over this topic once before, so there is by no means universal
agreement that the reverse tree ought to be maintained.)

I suggest we ask the people who have already implemented a couple
times various dns64 approaches, and see what the work is to do this
new proposal cleanly.  If Simon Perreault or Marc Blanchet wants to
give us advice, I think we should follow that.

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

---

From: Mark Andrews <[email-masked]>
Date: Sat, 01 Aug 2009 07:54:31 +1000

In message <[email-masked]>, Andrew Sullivan writes:
> RNAME for the in-addr.arpa zone; 

	Compute CNAME.  Continue normal processing.

	You made this way to complicated which is why I suggested the
	CNAME in the first place.

	For AAAA you need to convert answers.  For reverse you just
	create CNAME's.  We do that for DNAME all the time.

>(4) perform the necessary mapping if

	Nothing in that list is really new for nameservers. 

	For named it would just be yet another built in special
	zone type which would take the query and return the CNAME
	the rest of the processing would be as normal.

	Take the query. Construct the CNAME and add it to the answer.
	Continue processing as you would any other CNAME.

	zone "f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." {
		type master;
		database "dns64";
	};
	
	where "dns64" would be yet another special database in named.

	The only job of dns64 is to constuct the CNAME or return a
	negative answer.  NS and SOA are also handled.

> creating just as a transition strategy.

	FUD

> Also, there is quite a lot of
> don't think we should discount that.

	Nameservers already have special zones.  You have ones that talk
	to sql databases.  This is child's play compared to sql lookups.

> Given that we're admitting that

	This is no different to RFC 2317 which most ISP's do today.
	Add a CNAME to map from one namespace to a second namespace.
	It's just a /96 is a little bigger than a /24 so it is hard
	to just load it from a flat file.
 
> give us advice, I think we should follow that.

	Conversion from ip6.arpa to in-addr.arpa and back to ip6.arpa
	is complicated.

	Just synthesizing CNAME's is trival.
 
	Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 31 Jul 2009 18:21:43 -0400

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

> > creating just as a transition strategy.

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

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.

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

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.