From owner-freebsd-net@FreeBSD.ORG Thu May 29 12:57:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A796F1065677 for ; Thu, 29 May 2008 12:57:42 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: from ibctech.ca (unknown [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id 451978FC1E for ; Thu, 29 May 2008 12:57:42 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: (qmail 37629 invoked by uid 89); 29 May 2008 08:58:01 -0000 Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve@ibctech.ca@2607:f118::5) by v6.ibctech.ca with ESMTPA; 29 May 2008 08:58:01 -0000 Message-ID: <483EA7D0.6050301@ibctech.ca> Date: Thu, 29 May 2008 08:55:44 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Kevin Oberman References: <20080528223530.1216C4501D@ptavv.es.net> In-Reply-To: <20080528223530.1216C4501D@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: IPv6/IPv4 DNS resolver source X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2008 12:57:42 -0000 >> If you lose your IPv6 connectivity (or worse, if it's up but not >> performing well) you will run into problems with your end users that >> have IPv6 enabled because when it's on it is generally tried first. >> Since more and more operating systems come with IPv6 enabled by >> default, and more and more networks worldwide are enabling it for >> their users, this can be a problem. Essentially, this is exactly why the only box that I have in production with IPv6 is my own personal server. The production network has internal IPv6 connectivity, but no DNS AAAA records until I find out how badly my own gear will react in certain events. >> In an ideal world you'll want to be able to monitor your IPv6 >> connectivity from key points outside your network, and alert $SOMEONE >> if it isn't working properly. If it's a prolonged outage you will >> probably want to update DNS to withdraw your AAAA records, and at >> least to start with you'll want them to have a fairly short TTL when >> they are in the zone. Generally, the zone that I have AAAA and A records for a single name have five minute TTLs for this purpose. >> Although it is not popular with the "IPv6 do or die!" crowd, one >> procedure I recommend in the early stages of IPv6 deployment is to set >> up nameservers that only listen on IPv6 addresses, and only add the >> AAAA records to the zone files on those nameservers. (The AAAA records >> for the nameservers will have to be in all zone files of course.) At >> least that way you will be sure that the people you serve AAAA records >> to have _some_ kind of IPv6 connectivity, and that your end is at >> least up before sending your end users there. This is not a foolproof >> system because there is not necessarily a 1-to-1 relationship between >> the network that the resolver is on and the network the user is on, >> but for the vast majority it will be, and it's a lot better when >> rolling out to take baby steps till you have found all/most of the >> land mines. > > While this idea makes a bit of sense, the single most popular OS for the > desktop is Windows XP and will not issue IPv6 DNS queries. While XP runs > IPv6 just fine, all name resolution is over V4, so if people do what you > suggest, they will always use IPv4. You will see traffic from MacOS, > Unix and Vista, but that is a fairly small part of the end-user world. I agree that the idea makes sense, but also completely understand where Kevin is coming from. All things considered now, I may end up whipping up a monitor script to reload BIND with an alternate (IPv4 only) zone file for the affected domains if I can't ping my IPv6 BGP peer. That $SOMEONE you mentioned above could be nobody ;) > And I am probably in the "IPv6 do or die!" crowd as I see some really > big problems arising in the next coming few years with IPv4 address > exhaustion and several other things that can only be addressed when a > large portion of the 'eyeballs' are running over IPv6 exclusively. (Dual > stack does not really do much good.) Unfortunately, there are reasons why I have to be dual stacked, some of which are beyond my control, and others because I am not overly confident with the lack of consensus in the IETF regarding transition yet. I would highly prefer to be dual-stacked at this point, then to have to perform *any* sort of translation, again, due to lack of consensus within the IETF. When an agreed upon standard is created for rock-solid global IPv6 connectivity, I'll be one of the first to hand ARIN back my v4 addresses. Doug mentioned a great mailing list (that I'm currently on). For those interested, here are some more: - v6ops@ops.ietf.org - ipv6canada@ipv6forum.com Thanks for the great feedback. Steve