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

Doug Barton dougb at
Tue May 1 21:30:18 CEST 2007

I realize that this thread is a little stale, but I'd like to add what 
I hope is relevant material to it.

Tim wrote:
> Hello,
> I would like to run a website which hosts both IPv6 and IPv4 versions.

You haven't said this explicitly, so I should ask, the content will be 
the same on both "versions," yes? I ask because if that is not the 
case, what I say below isn't (as) relevant. Several people have posted 
examples of sites that somehow indicate that you've reached them 
through v6, my personal favorite (after the kame site of course) is The SSI to do that is very simple, I can post 
it if anyone needs it. Of course there are other ways to accomplish 
the same thing...

> Sounds easy, but in this exceedingly long transition period, it is a
> little harder than might be expected. 

You have a gift for understatement. :)

> I have noticed quite a few issues with users who run IPv6-compatible
> software but don't know it and/or don't configure it.  For instance, if
> I run Firefox on Linux (which has IPv6 enabled) and come to a website
> which advertizes both AAAA and A records, and I'm not set up properly to
> route IPv6, Firefox tends to hang quite a while before reaching the
> site.  This seems to be because it first attempts to connect via IPv6
> and waits for that attempt to fully time out before trying the IPv4 A
> record.  The pause can be unacceptable in some situations.  I'm sure
> behavior varies under different levels of IPv6 brokenness...

You are correct that this is a problem. It's getting better, but it's 
still a problem, especially for those with older OS software that are 
not going to upgrade any time soon.

> In any case, to get around this problem I thought maybe a good idea
> would be to do the following:
> - Run two separate authoritative DNS servers, one which serves only IPv4
>   records, one which serves only IPv6 records.  The v4 server would only
>   serve these records over v4, and likewise, the v6 server would only
>   serve records over v6.

Doing this (and the corollary that you posted and I snipped) won't 
work, and as others have pointed out is a bad idea. What _would_ work 
from a technical standpoint (although possibly not from a practical 
one if your registry and/or registrar don't permit it) would be to use 
something equivalent to BIND 9 views to host "separate but equal" v6 
and v4 versions of the same zone, served by their respective 
protocols. So for example (with silly fake IP addresses):

ns1	A
	AAAA	2001::1:2:3:4
ns2	A
	AAAA	2001::1:2:3:5

The v4 view of your zone would have only A records in it, and be 
served by the name server instances listening on the v4 addresses. The 
v6 view would have only AAAA records for those sites of yours that 
support them (and A records for sites that don't, obviously), and be 
served by the instances listening on the v6 addresses. (I can go 
through the exercise of setting up the config for this if you wish, 
contact me for rates). :)

In this way the only clients that will get AAAA records for a given 
host are those that actually query your servers over IPv6, thus 
guaranteeing (as much as anyone can at this stage in the game) that 
they will also be able to access the _content_ over v6.

Doing this will in fact offend some DNS purists that carp about 
"divided namespaces" and the like, but at this stage of the 
transition, I feel that the benefits far outweigh the lack of purity. 
I would caution you however that the scheme I'm suggesting only works 
if you can add A and AAAA records for each of your name servers' 
hostnames. Trying to do it any other way will lead to a lot of 
confusion and problems.

Also, doing it this way is not without risk. Clients that are behind 
name servers that do not properly limit outbound queries to v4 if 
that's all they support (e.g., with the -4 switch to BIND) will 
experience some lag time while they try to query the v6 address, but 
that's very minimal compared to the pain caused by dumb clients 
(whether application or OS) that try to query a host on an AAAA record 
when it can't ever actually get there.

> - Assuming a client fully supports IPv6 AND is configured to route it,
>   the only way they could get the AAAA record for my site is if they
>   were able to query the primary NS server over IPv6, thus proving
>   they're configured correctly on their end.  Then they should have no
>   problem getting to the site.

IMO your conclusion is correct, but your premises were faulty. 
Hopefully you see the difference between what you suggested, and what 
I suggested.



     If you're never wrong, you're not trying hard enough

More information about the ipv6-ops mailing list