Date: Wed, 28 May 2008 15:35:30 -0700 From: "Kevin Oberman" <oberman@es.net> To: Doug Barton <dougb@FreeBSD.org> Cc: Steve Bertrand <iaccounts@ibctech.ca>, freebsd-net@freebsd.org Subject: Re: IPv6/IPv4 DNS resolver source Message-ID: <20080528223530.1216C4501D@ptavv.es.net> In-Reply-To: Your message of "Wed, 28 May 2008 10:21:00 PDT." <483D947C.6020906@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--==_Exmh_1212014130_70344P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Wed, 28 May 2008 10:21:00 -0700 > From: Doug Barton <dougb@FreeBSD.org> > Sender: owner-freebsd-net@freebsd.org > > Steve Bertrand wrote: > >>> Is there anyone here who can advise me where in the source tree I > >>> would find the DNS resolver code that performs AAAA/A record lookups, > >>> and more specifically, the fallback to A lookup if AAAA fails? > >> > >> Assuming you're considering getaddrinfo(), see res_queryN() in > >> lib/libc/net/getaddrinfo.c. > >> > >> BTW: "fallback" does not really accurately describe the behavior. > >> When AF_UNPSEC is specified, both AAAA and A queries are issued, > >> whether or not the AAAA query fails. > > > > Thank you for the info. I did not know that little tidbit. > > > > I've got my first IPv6 DNS, mail, web etc server up and running now, and > > before I think about migrating the actual production network, I want to > > perform some extensive testing, all the while being familiar with the > > framework of the resolver itself, and how to overcome particular > > DNS/connectivity issues (if possible). > > > > ie: I want to learn more about how DNS and IP react in the event I lose > > my IPv6 BGP peers (or IPv4 peers), and also write in some debug log > > writing into the resolver if certain events trigger. > > 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. > > 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. > > 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. 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.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1212014130_70344P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIPd4ykn3rs5h7N1ERAhOAAKCbk5MP+trzv1xqjpiySgCncy5jXACfXirn 7PgNMkKVj8YA4hp2mWA/JmY= =lDzE -----END PGP SIGNATURE----- --==_Exmh_1212014130_70344P--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080528223530.1216C4501D>