Question about "proper" way to run v6/v4 website

[Remi Denis-Courmont]

On Tue, 01 May 2007 23:05:41 -0700, Doug Barton <dougb at dougbarton.us> wrote:
> So I'll ask the question again. What operational goal are you
> servicing by enabling v4-only clients to query a name server that does
> v6 queries?

Your question is biased.

While I do allow v4-only clients to query AAAA (in fact, I allow them to
query any RR type, even those my name servers does not know of), I know
they will NOT do that.

Only v6-enabled clients do actually query AAAA, in just about any
IPv6-capable operating system that I have seen. In fact, it has been
pointed out on this same mailing list about a month ago that it is a VERY
BAD idea for a non-v6 client to query AAAA at all because some (broken)
middleboxes screws such DNS queries up. Unsurprisingly, about every
v6-capable operating system DNS resolver only queries AAAA if it has
non-link-local IPv6 connectivity configured.

Even then, every single
operating system that I know will return a non-blocking error if you try
to connect via IPv6 while it is not implemented. Now, that might admittedly
break some very badly written software, but that will NOT break Mozilla,
IE, Opera, Netscape, Konqueror, Galeon or your-other-browser-here.

So I would rather ask what problem are you trying to solve by hiding AAAA
records from v4-only clients?


Anyway, if it was not obvious, I do allow my v4-clients to query AAAA
because I do have dual-stack clients, doing their AAAA queries through
DNS/IPv4. Besides, I do not want to duplicate server just because of IPv6,
so I obviously use the same recursive DNS caching server for both versions.

>> Responding with different answers in the face of a forwarding chain of
>> unknown length sounds like a bad idea.
> 
> Then let's talk about WHY you think it's a bad idea, and more
> importantly,

I think this has been detailled at length here already. But as a reminder,
the point is that IN REAL LIFE, you can REALLY NOT assume that queries from
v4-only clients will come through v4, neither that queries from v6-capable
clients will come through v6.
Your solution breaks many more cases that it solves.

> why you think that what I'm proposing is worse than the
> standard answer of "throw all the records into the same DNS and let
> God sort them out." With what I'm proposing, no client gets an AAAA
> record as an answer unless there is at least v6 involved SOMEWHERE in
> the chain. While it is obviously not a panacea (and I did not suggest
> that it was) I can't help believing that it's an improvement to the
> status quo.

In general terms, your "solution" puts the decision into the server's hands,
while it is generally expectable that the clients knows its own network
conditions a lot better than the server (unless it's some internal
Intranet). In fact, big OS vendors have sunk big amount of engineer-hours
to ensure that their clients make the right decision.
That's why we have RFC3484, and dual-stack resolvers, and getaddrinfo()...

> Please demonstrate in concrete terms how I am wrong.

Not again.

> BTW, there is at least one other problem with what I proposed that no
> one has mentioned yet, what about clients that are v6-capable behind a
> resolving name server that isn't?

I could be wronf but I am pretty sure I did mention this.

> But I think my main point is still
> valid. WHILE WE ARE IN THIS TRANSITION PERIOD, how can we make
> migration to v6 traffic simpler, and more transparent than it is now?

I just do not get what is wrong now, unless you care for the one in one
million systems that have broken network configuration (and hence most
likely cannot use your service anyway).

Of course, there are some experimental networks that will have troubles
with their IPv6 connectivity, but these are people who know what they
are doing. And there are also experimental networks with working IPv6
and broken IPv4 too. But these are neglectible and must be neglected.

Normal clueless users do not have IPv6 yet, unless they have Vista
(or equivalent) with proper RFC3484 support and clever dual-stack
resolver and everything.

--
Rémi Denis-Courmont
http://www.remlab.net/