[dns-operations] resolv.conf and resolving IPv6-only domains/NSes

Matt Thompson mthompson at hexwave.com
Thu Nov 4 03:27:41 UTC 2010


On 10-11-03 10:16 PM, Frank Bulk wrote:
> Holger:
>
> The Debian box is not IPv6 only.
>
> I had presumed (incorrectly) that I could list a bunch of DNS servers (IPv4
> and IPv6-only) in resolv.conf and the IP stack would handle SERVFAIL
> gracefully and move on to the next one.  Apparently that's not the case,
> which is why your recommendation that all the servers listed in resolv.conf
> be dual-stack is a good idea.
Hi Frank,

It seems that glibc getaddrinfo() does fail to the second DNS server if 
the first one is not dual stack in your resolv.conf. It's up to glibc or 
other stub resolver code to handle SERVFAIL. The IP stack itself has no 
knowledge of DNS.

My resolv.conf has:
nameserver 4.2.2.5                # Not dual stack
nameserver 192.168.12.1        # Dual stack

This test program demonstrates that it does fail over to the dual stack 
nameserver:

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <string.h>

const char *query = "onlyv6.com";

int main(int argc, char **argv)
{
     struct addrinfo hints;
     struct addrinfo *result;
     char addrbuf[INET6_ADDRSTRLEN];

     int ret;

     memset(&hints, 0, sizeof(struct addrinfo));
     hints.ai_family = AF_UNSPEC; /** IPv4 or IPv6 */
     hints.ai_socktype = SOCK_DGRAM;

     ret = getaddrinfo(query, NULL, &hints, &result);
     if(ret != 0)
     {
         fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(ret));
         return(EXIT_FAILURE);
     }

     while(result)
     {

         inet_ntop(result->ai_family, result->ai_addr->sa_data + 2, 
addrbuf, sizeof(addrbuf));
         printf("Result: %s\n", addrbuf);
         result = result->ai_next;
     }
     return(EXIT_SUCCESS);
}

Here's the output from the program:

matt at desk:~$ ./testv6
Result: ::2607:f118:8c0:800:0:0


Dig implements its own stub resolver and doesn't failover on SERVFAIL:

matt at desk:~$ dig onlyv6.com

; <<>> DiG 9.7.1-P2 <<>> onlyv6.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41092
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;onlyv6.com.            IN    A

;; Query time: 56 msec
;; SERVER: 4.2.2.5#53(4.2.2.5)
;; WHEN: Wed Nov  3 23:09:17 2010
;; MSG SIZE  rcvd: 28

nslookup does failover:

matt at desk:~$ nslookup -type=AAAA onlyv6.com
;; Got SERVFAIL reply from 4.2.2.5, trying next server
Server:        192.168.12.1
Address:    192.168.12.1#53

Non-authoritative answer:
onlyv6.com    has AAAA address 2607:f118:8c0:800::64


Cheers,
Matt Thompson
HexWave Software Systems

> Frank
>
> -----Original Message-----
> From: Zuleger, Holger, VF-DE [mailto:holger.zuleger at vodafone.com]
> Sent: Wednesday, November 03, 2010 12:26 PM
> To: frnkblk at iname.com; Stephane Bortzmeyer
> Cc: dns-operations at dns-oarc.net
> Subject: RE: [dns-operations] resolv.conf and resolving IPv6-only
> domains/NSes
>
>> Stephane:
>>
>> You are correct, whether my tool requests resolution via IPv4
>> or IPv6 for
>> onlyv6.com shouldn't matter as long as the queried resolver has IPv6
>> connectivity.
>>
>> So what I've learned is that if I want to resolve query
>> v6-only domains,
>> such as onlyv6.com, I had better make sure that the first DNS
>> server in my
>> resolv.conf has IPv6 connectivity.  Even better, make sure
>> all of them do.
> No.
> If your client is ipv6-only then it doesn't make sense to
> use an IPv4 resolver.
> Additionally each of the ipv6 resolvers in your list *must* be
> dual-stack, or need the help of an dual stack resolver (e.g. via
> BINDs dual-stack-server command).
>
> If the domain is a v6-only domain, at least the authoritative name
> servers of
> the domain have to be dual stack.
>
> Regards
>   Holger
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations




More information about the dns-operations mailing list