Subject: [BEHAVE] On the well-known host heuristic

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 Mar 2011 11:15:50 -0400

This is a note to amplify my remarks today.

Using a well-known name in the DNS to detect the existence of a DNS64
is, frankly, an idea that makes me cringe.  Among the deep problems in
the DNS is its somewhat careless commingling of the data plane and
control plane.  What this sort of proposal does is make that
commingling worse, by using the exact same form of query and answer
sometimes for control, and sometimes for data.  Reaching back to my
database theory days, I want to call this "minus first normal form" or
something like that.  

So, in the first place, there is a serious architectural issue here.
The point of having data types in the DNS is that the data that you
get from it is supposed to be one kind of data and one kind only.  But
this proposal makes a positive answer to AAAA mean not one, but two
things: (1) you can contact host $name on address $ipv6_address and
(2) there's a NAT64 here.

In the second place, there's a serious operational side effect to all
this.  What this proposal means is that the root name servers for the
DNS will have to take a pile more garbage traffic.  A AAAA query for
$well-known-name will be quite common.  Any application that cares
about this will issue these queries forever, and when the desired end
goal (native v6 [almost] everywhere) happens, applications on all
those networks will continue to make this AAAA query.  It's going to
leak from local networks (it's practically _designed_ to leak), and
we'll never get rid of it.

So, a well-known name is a terrible idea.  It is a filthy hack and it
has bad side effects for the global DNS.  It ought to be a
straightforward loser.  But, of course, that was true of most NAT
proposals, and we got all of them no matter how stupid they were,
partly by ignoring the work instead of working on the one that would
be least bad.

What I heard at the mic today is, "We who put IPv4 literals in our
higher-level protocols and who are now depending on them are going to
use a well-known name, because we have practical limitations on doing
other things.  We don't have a choice, and this is the way we are
going to do it, period, so get used to it."  Since I have no desire to
pretend to be King Canute, then, I have to concede that we need to
document something.  But while I am willing to bow to reality and make
an architecturally hideous concession, we simply cannot increase the
garbage queries that will be directed for the rest of eternity at the
root servers.  So we need to come up with something to solve the
operational consequences.

The question I have, then, for the people who are absolutely
determined to go this direction is how many restrictions you really
have.  Does this have to be a bog-standard AAAA query?  In particular,
I'm wondering whether you could do something with a PTR query (inside
ip6.arpa) instead of a AAAA.  I'm imagining a case where you get an
answer for a particular address inside the reverse tree only if there
is a DNS64 in the way.  Only if you get the required answer, you may
do the forward AAAA query for the well-known name.

The reason I am thinking that might be better is that there is
infrastructure (the AS112 project) set up to sink garbage queries of
the sort the well-known name proposal is guaranteed to generate.  

A

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

---

From: <[email-masked]>
Date: Wed, 30 Mar 2011 14:24:48 +0000

Hi,

Would it help (even if not fully solve) if AAAA query would be sent only when:
- application actually has IPv4 literal at hand and host has IPv6-only connection (i.e. not just in case)
- application is running on host having dual-stack connection and the application actually needs to determine presence of NAT64 (i.e. not just in case)

Then as IPv6 transition progresses, the IPv4 literals should become fever, and hence applications would issue AAAA queries less often. 

Also if this well-known name were application/os vendor specific, would that still cause similar problem?

I don't see how PTR could be used when network uses NSP instead of WKP?

Best regards,

	Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Andrew Sullivan
> Sent: 29. maaliskuuta 2011 17:16
> To: [email-masked]
> Subject: [BEHAVE] On the well-known host heuristic
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 30 Mar 2011 17:20:22 +0200

On Mar 29, 2011, at 5:15 PM, Andrew Sullivan wrote:

> is, frankly, an idea that makes me cringe.  

Give me a better way to detect the existence of a DNS64 that doesn't involve changes to the operating system or resolver library (or root-level application access) and I'll use it.

The issue really is that the only way to find the DNS64 itself is to ask the DNS resolver to send a packet to it. And the only kind of packets the DNS resolver will send for me are DNS queries.

> (2) there's a NAT64 here.

Actually this is true for all NAT64 queries, even ones *not* being made by applications that have IPv4 literals in hand.

> we'll never get rid of it.

Well, one of the reasons I supposed using a reserved name is that I presumed that DNS64 devices could terminate the lookup for the name locally and not let it leak out... and with careful choice of that name it could be easier to sink at the root as well.

The worst case is that each app vendor needs to have well-known-name.app-vendor.com, which requires hits all over the DNS if you run >1 app with this requirement.

> has bad side effects for the global DNS.

Coming up with NAT64 without considering just how many real applications MUST use IPv4 literals is the terrible idea.

This is just fallout from that.

> going to do it, period, so get used to it."  

Yes, that's pretty much what I said.

There are IPv4 literals in the higher level protocols of Skype (where I work now), Adobe Flash Player when running RTMFP (what I worked on before I came to Skype), BitTorrent, and SIP and ICE. Plus a bunch of other things that may or may not be as popular as the above.

They're there for a reason, and that reason is that putting transient peer candidate addresses (some of which are in private address space, btw) into the DNS doesn't work nearly as well.

All of these things predate NAT64... all of them are broken by NAT64... and for all of them the easiest path to get working again in a NAT64 environment will be to add a shim which allows IPv4 traffic to find the NAT64. This shim needs to be implementable and deployable on the same systems these applications are currently running on... so that means no OS changes, no root-level privilege requirements, no resolver library changes, etc.

> Since I have no desire to

See above.

> the sort the well-known name proposal is guaranteed to generate.  

It would be nice to have it be a single query, but see above for my comments about how we might sink it better than one-name-per-app-vendor-inside-.com will be.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 30 Mar 2011 17:20:38 +0200

> - application actually has IPv4 literal at hand and host has IPv6-only connection (i.e. not just in case)

That's when one would do it.

> Then as IPv6 transition progresses, the IPv4 literals should become fever, and hence applications would issue AAAA queries less often. 

If there are really fewer and fewer IPv4 literals (or in some cases, more and more cases where the IPv4 literal is paired with a valid IPv6 literal which may be used instead) then yes.

Matthew Kaufman

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 30 Mar 2011 11:38:35 -0400

> - application actually has IPv4 literal at hand and host has IPv6-only connection (i.e. not just in case)

If I understand this suggestion correctly, the idea is that an
application shouldn't actually do this check until it finds it has an
IPv4 literal and knows it only has an IPv6 connection to use it on.
While I personally like this sort of just-in-time approach, our
experience is pretty bad in this area.  For instance, many web
browsers resolve every name in every link on a page in order to cut
page view times.  I presume any protocol that decided it had to keep
IP address literals in it would be similarly susceptible to
performance considerations.

> - application is running on host having dual-stack connection and the application actually needs to determine presence of NAT64 (i.e. not just in case)

How would the application know this?

> Also if this well-known name were application/os vendor specific, would that still cause similar problem?

It would be worse, in fact.  Instead of one well-known name (which
could be the only entry in some .arpa zone, so we could set the
negative TTL really long), we'd have lots of them with lots more
opportunity for garbage queries to get sent along.

> I don't see how PTR could be used when network uses NSP instead of WKP?

Why not?  The idea here is that you _always_ query for something
inside the WKP.  We just reserve one address (inside the WKP) for
this, and make it always return an indication that the DNS64 is in the
way.

A

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

---

From: <[email-masked]>
Date: Wed, 30 Mar 2011 16:32:21 +0000

> performance considerations.

Well, true. Some even query partial names while typing URL..
 
> > - application is running on host having dual-stack connection and the
> application actually needs to determine presence of NAT64 (i.e. not
> just in case)
> 

If IPv4/IPv6 capable application were allergic to NAT64, it might want to check for presence of NAT64 before attempting IPv6 communications? (Except if it does happy eyeballs/ICE/similar and tries both IPv4 and IPv6 at the same time). 
 
> this, and make it always return an indication that the DNS64 is in the

Ok, didn't realize that was your proposal. Well, in such case the feature would have to be mandatory feature on each DNS64 implementation, as otherwise hosts would have to do well-known name query just in case DNS64 does not happen to support PTR-based discovery..

Teemu

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 30 Mar 2011 13:47:10 -0400

On Wed, Mar 30, 2011 at 05:20:22PM +0200, Matthew Kaufman wrote:

> Actually this is true for all NAT64 queries, even ones *not* being
> made by applications that have IPv4 literals in hand.
> 

I don't see how.  DNS64 might be a hack (I've never pretended
otherwise), but it doesn't change the meaning of a AAAA answer as just
"Go here for that".
 
> Well, one of the reasons I supposed using a reserved name is that I
> presumed that DNS64 devices could terminate the lookup for the name
> locally and not let it leak out... and with careful choice of that
> name it could be easier to sink at the root as well.

RFC1918 addresses are never supposed to leave a site, and they have no
meaning except in a local context.  Yet people had to set up the AS112
project in order to divert all the reverse-map queries for addresses
in 1918 space.  That project didn't get set up because people had a
lot of spare time; it got set up because root servers were being
hammered by these queries.  So while I agree that we could tell DNS64
never to pass these along, I'm not sanguine about what will actually
happen.  But anyway, that's not the problem.

The problem is that we're giving nodes a way to learn whether they're
behind a DNS64.  One thing we want that for is DNSSEC validation on
the end node.  That's an absolute requirement for a number of things
that people seem to be doing or planning to do with DNSSEC.  So, every
host that has only an IPv6 connection and wants to do DNSSEC will have
to make this query, forever.  Since we would like to suppose that in
the longish run most of those won't be behind a DNS64, there's nowhere
to sink those queries.  So they'll have to be answered by the global
DNS.  Worse, the more successful real IPv6 deployment is, the more
acute the problem gets.

> The worst case is that each app vendor needs to have
> well-known-name.app-vendor.com, which requires hits all over the DNS
> if you run >1 app with this requirement.

Yes, I completely agree, which is why I'm not screaming "Lord no make
it stop!"  If people are going to do this anyway, I'd way prefer that
everyone do it the same way.

> Coming up with NAT64 without considering just how many real applications MUST use IPv4 literals is the terrible idea.

Two things about that:

    1.  I was always sceptical that NAT64/DNS64 would really work,
    because of exactly this problem.  I suggested we put in some sort
    of detection from the beginning, but the point was supposed to be
    that applications and hosts needed _no_ changes to use this.  The
    goal of NAT64/DNS64 was supposed to be practically no intervention
    on the end points.  

    2.  We always seemed to believe that there were going to be
    "corner cases" where NAT64/DNS64 was going to break stuff.  Maybe
    we now think that was a bad decision, but that was in fact what we
    said originally.

A

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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 31 Mar 2011 04:11:49 -0400

On Wed, Mar 30, 2011 at 04:32:21PM +0000, [email-masked] wrote:
> Ok, didn't realize that was your proposal. Well, in such case the
> feature would have to be mandatory feature on each DNS64
> implementation, as otherwise hosts would have to do well-known name
> query just in case DNS64 does not happen to support PTR-based
> discovery..

I don't think so, although as I think it through I don't think we're
any better off if we use the reverse.

Here's what I was thinking.  DNS64 says this:

   If a DNS64 server receives a PTR query for a record in the IP6.ARPA
   domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the
   address portion of the QNAME according to the encoding scheme
   outlined in section 2.5 of [RFC3596], and examine the resulting
   address to see whether its prefix matches any of the locally-
   configured Pref64::/n or the default Well-known prefix.

[…]

   1.  The first option is for the DNS64 server to respond
       authoritatively for its prefixes.  If the address prefix matches
       any Pref64::/n used in the site, either a NSP or the Well-Known
       Prefix (i.e. 64:FF9B::/96), then the DNS64 server MAY answer the
       query using locally-appropriate RDATA.
[…]

   2.  The second option is for the DNS64 nameserver to synthesize a
       CNAME mapping the IP6.ARPA namespace to the corresponding IN-
       ADDR.ARPA name.  In this case, the DNS64 nameserver SHOULD ensure
       that there is RDATA at the PTR of the corresponding IN-ADDR.ARPA
       name, and that there is not an existing CNAME at that name. 

(We're making a small change, I guess, but I don't think it alters
these rules.)  So, a DNS64 will always either answer authoritatively
for the well-known prefix, or else it will produce a CNAME with a
target IN-ADDR.ARPA name.  But an ordinary resolver on IPv6 will
_never_ have data for the WKP, because there isn't data there.
Therefore, we can necessarily tell whether there's a DNS64 in the way
because of the rules about how reverse data has to be handled.

Now, none of this is any better than a forward-zone well-known name
(WKN) that gives you the signal, except, I thought, that it would be
in the AS112 system.  That has the nice property that we'd be sending
those garbage queries I was worried about into a system that is
actually designed to sink garbage queries instead of against the
roots.  But I thought some more, and the in6.arpa space that is the
WKP for NAT64 isn't actually in the AS112 system (and it's tricky,
because of how AS112 grew, to add new things to it).  So I'm no longer
so sure about this.

A

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