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

Tim tim-projects at
Thu Apr 19 20:02:12 CEST 2007


Thanks for your quick reply.

> > - 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.
> Does not work. 

In general you are probably right, but what do you mean in reference to
this text?

> > - Set my primary NS record to point to a name which only points to a
> >   AAAA record.  Set secondary NS records to point to names which
> > point to A records.
> First you would need to get AAAA glue records from your upstream, which 
> is likely not supported yet.

True, I just realized that after I posted.  However, my upstream
provider does support IPv6 records, so they may be able to provide this
as glue as well.

> > - 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.
> Second, IPv4 people with an IPv6-enabled DNS servers would have a big 
> problem (yes, this scenario can happen).

Ok, agreed, but the number of people in this situation is probably
small, esp given what you say about fewer people using v6 for DNS that
people running v6 in general.

> Third, the large majority of IPv6 people still do their DNS queries with 
> IPv4, since there is very little deployment of DHCPv6 yet. So this is 
> pretty much the same as cutting of IPv6 support.

True, but at least my site is available.  I can assume just about anyone
is running v4 along with v6 right now, or is using some other way to
access v6.  When people start using IPv6 resolvers, things continue to
work for everyone (except in the corner case you just mentioned).

> Forth, IPv6-capable DNS servers probably have a better maintained 
> connectivity than IPv6 nodes in general, so your assumption that
> (IPv6 connectivity && IPv6 DNS) => (working IPv6 connectivity) will most 
> likely break.

Well, my assumption is:
   (IPv6 software && IPv6 DNS) => (IPv6 connectivity)

Rather than:
  (IPv6 software) => (IPv6 connectivity)

The latter of course is your assumption if you just publish A and AAAA
for a webserver.

> > So, I guess my questions are:  Is this scheme the "right" way to do
> > it?
> No.

Ok, I won't argue with that.

> > In practice, do v6-capable resolvers currently even follow AAAA
> > records when those names are pointed to by NS records?
> That's irrelevant. Web "clients" seldom run their own recursive DNS.

Well, ok, explain to me again what happens if a non-recursive client
asks for AAAA on, and the upstream DNS supports IPv6?
Doesn't the upstream recursive resolver go SOA to NS(plus GLUE) to AAAA,
and then give back the AAAA for, or something like that?
My question is, will that upstream resolver generally accept AAAA as

> > Is there any RFC or other document which describes how to best set up
> > records for dual-stack servers?
> Yes. It tells to put A and AAAA. Trying to fix someone else connection 
> is bound to fail anyway. When you enable IPv6, you know that it will 
> likely break with some peers anyway.

Fair enough.  I agree users could have any number of messed up
configurations that would prevent connectivity and you can't account for
them all.  And I also agree just putting A and AAAA is more elegant.

However, if you rob someone of connectivity by doing this, you aren't
ever going to sell management on providing IPv6 as well as IPv4 on the
same domain name.  In addition, if you use the two-domain hack (for
"whiners"), then you're just putting up more barriers to a clean
transition, at least IMHO.


More information about the ipv6-ops mailing list