[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "DNS-4to6 automatic mapping" - No more DNS-ALGs & 6then4 DNS queries

On 26 nov 2007, at 6:40, Erik Kline wrote:
For this, let's specify that a next release of the DNS sotware (BIND and 
others) will have to include a DNS-4to6 AUTOMATIC MAPPING.
With it, an IPv6 RR is automatically created, within the DNS, for each 
existing IPv4 RR, using for this the *mapped address format* of RFC
2373.


The question is: do we really have a problem?
Yes, people recommend turning off IPv6 on forums here and there, but this used to be because there were some DNS servers out there that would reply with an error when queried for AAAA records. That problem has been solved 99.9%, unless I'm mistaken. Also, apparently turning off IPv6 helps agains all kinds of problems that are provably IPv6- unrelated.
I think any effort would be better spent by making sure OSes don't send AAAA queries when there is no IPv6 connectivity.
You can achieve pretty much the same result by placing the A records in the additional section of responses to AAAA queries, without creating a need for mapped addresses. This could be done very simply, but changing DNS implementations for IPv6 capable servers will only solve part of the operational problems encountered today. 

Right.
These operational problems are direct consequences of the current IETF recommendation to always ask first for the AAAA record if the client is IPv6 capable. This is a very aggressive stance, designed to maximize the occurrence of IPv6 connections. If we wanted to smooth transition, we could take a softer stance, e.g. let dual- stack hosts only send AAAA queries if it can reasonably presume that the target server is IPv6 capable. 


Out of curiosity: how would a machine determine what it can
"reasonably presume" to be IPv6 capable?  Some locally administrated
policy directives for the host's resolver?


Indeed. There is no way to know that without asking for AAAA records.
The problem with implementing new features that aren't actually used (which is what happens if you prefer A records - something Windows users can do manually using the policy table, by the way) is that over time broken behavior grows and then when usage finally occurs it doesn't work. Examples: 

- HTTP pipelining
- ECN bits
- path MTU discovery

And so on.
If people don't want to use IPv6 they should either disable the protocol or set up an appropriate RFC 3484 policy table. If IPv6 connectivity is available, the only reasonable thing to do is prefer that by default. 

Separately: I wonder if there was any discussion of creating a DNS rr
query type with the essential meaning "A*", i.e. give me A records,
AAAA, A6 (while they were being tried), hence A*.
There already is a * query type but I gather that trouble with that is that it won't go out and make sure that copies of all possible records are available, if there is something in the cache you get that. 

The problem with a new query type is that you could end up asking for:

A*
AAAA
A

Which takes longer than:

AAAA
A
But again: do we really have a problem? The first query can take some time because the delegation tree must be traversed at least partially, but after that the following query(ies) can go directly to the authorative server so the delay is minimal.