Date: Wed, 28 May 2008 10:21:00 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Steve Bertrand <iaccounts@ibctech.ca> Cc: freebsd-net@freebsd.org Subject: Re: IPv6/IPv4 DNS resolver source Message-ID: <483D947C.6020906@FreeBSD.org> In-Reply-To: <483D50D1.8000707@ibctech.ca> References: <483B3E7F.8000907@ibctech.ca> <m2wslfwpcp.wl%Jinmei_Tatuya@isc.org> <483D50D1.8000707@ibctech.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Caveats aside, google has taken a big step into the IPv6 arena giving access to their search engine through http://ipv6.google.com/, and they have said that once they get the bugs shaken out there they plan to go a lot bigger with IPv6 access to their network. This is widely recognized as a tipping point in the "must have v6 content to justify wider v6 rollout on the consumer side" debate, so anyone not making plans for IPv6 on their own network now is already one step behind the curve. There is an excellent list that covers IPv6 operational issues, http://lists.cluenet.de/mailman/listinfo/ipv6-ops You will probably want to search the archives there as well. hth, Doug -- This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?483D947C.6020906>