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

Gert Doering gert at space.net
Tue May 1 23:00:02 CEST 2007


Hi,

On Tue, May 01, 2007 at 12:30:18PM -0700, Doug Barton wrote:
> protocols. So for example (with silly fake IP addresses):
> 
> ns1	A	1.2.3.4
> 	AAAA	2001::1:2:3:4
> ns2	A	1.2.3.5
> 	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.

Given that end users normally query "some recursive resolver on the
way", and rarely directly query the authoritative server hosting the 
domains, I wonder why there would be any relationship between 
"the protocols that the end user machine can use" and "the protocols 
that the recursive DNS server can use".

Specific example: if our customers use our recursive DNS service, our 
DNS *will* use v6 queries (if the target DNS server has v6 connectivity), 
but about 95% of our customers do not have v6 connectivity yet, so they
would not be able to reach the destination.


(The whole idea has been beaten to death in this thread already, anyway)

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  113403

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279


More information about the ipv6-ops mailing list