Question about "proper" way to run v6/v4 website
rdenis at simphalempin.com
Thu Apr 19 19:39:16 CEST 2007
Le jeudi 19 avril 2007 20:20, Tim a écrit :
> - 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.
> - 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.
> - 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).
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.
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
> So, I guess my questions are: Is this scheme the "right" way to do
> 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.
> 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.
Some people also provide an extra www.ipv4.example.com and
www.ipv6.example.com for whiners.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20070419/a68b0610/attachment.bin
More information about the ipv6-ops