I've been a long-time c-ares user, but have always been a little frustrated,
and decided to write an async resolver from scratch:
http://25thandclement.com/~william/projects/dns.c.html
For my uses, it's feature complete w/ c-ares, and then some. I mention it
here because I'm curious about IPv6 usage scenarios, and perhaps the larger
c-ares community has a few people w/ opinions on the subject.
dns.c supports IPv6 records, but at the moment it doesn't talk to IPv6
nameservers. Also, it doesn't yet do simultaneous A+AAAA queries in the
getaddrinfo() interface clone (only one or the other, defaults to A for
PF_UNSPEC).
My stumbling block is devising an interface to specify ordering of A versus
AAAA lookups. For instance, if you're querying for an MX host, dns.c can
automatically, iteratively resolve the A glue, even when in stub mode
(there's no guarantee your recursive, caching nameserver will return the
glue, especially if the canonical name is out-of-bailiwick, and the answer
isn't already in the cache; that's one particular feature I put into dns.c
which is missing from all other stub resolvers I'm aware of). But when you
throw AAAA into the mix, you have to decide whether to query A first, or
AAAA first, or both (perhaps simultaneously). Simply enough. But since dns.c
can [optionally] do standard recursive queries on its own, the user should
also be able to set policy on choosing whether to recursively follow A or
AAAA nameservers first. And what about failure modes? The user says they
prefer AAAA, but their stack (or peering) is fubar'd; how should the
resolver "do what I mean", and not merely "do what I say".
To that end, I'm curious to hear comments and suggestions from anybody who
actually uses IPv6; not just querying AAAA records, but runs an IPv6
enabled-host with real applications using IPv6. I've run IPv6 tunnels; all
of my networking code can handle IPv6 addresses and sockets; but I haven't
written or maintained live IPv6 applications, and had to deal w/ the hassles
and headaches, especially regarding the bifurcated DNS namespace.
Received on 2009-03-10