356104 - Necko resolver code should support more DNS record types

Status: RESOLVED DUPLICATE of bug 545866

(Core :: Networking, enhancement)

Description

[Neil Harris]

At the moment, the Necko code only seems to support looking up A and AAAA records: more advanced DNS functionality needs the ability to look up other DNS record types, such as TXT, NAPTR and SRV records.

However, this requires a full DNS resolver implementation, which is a non-trivial exercise to implement, since it will need probably to support things like EDNS, DNS-over-TCP, and so on.

Rather than write a DNS library from scratch, it is probably best to try to find a capable, modern, well-debugged portable DNS resolver library that is under a licence that is compatible with the Mozilla licencing policy, preferably with built-in support for asynchrony.

Comment 1

[Neil Harris]

Here's a start on listing possible candidates for a more-capable DNS resolver; of these, only ARES and skadns have very permissive (MIT/X, BSD) licenses: GPL'd libraries would need permission of the original authors for multi-licensing. 

Name
What
Language
Author
URL
Licence
Notes/possible drawbacks

adns
asynchronous resolver library
C
Ian Jackson
http://www.chiark.greenend.org.uk/~ian/adns/
GPLv2 or later
No IPv6...

Ares
asynchronous resolver library
C
Greg Hudson
ftp://athena-dist.mit.edu/pub/ATHENA/ares/
MIT/X licence
?

Poslib
resolver libarary and authoritative-server
C++
Meilof Veeningen
http://posadis.sourceforge.net/poslib/
GNU GPLv2 or later
?

RULI
Resolver User Layer Interface -- includes asynch stub resolver
C
Everton da Silva Marques
GPL
http://www.nongnu.org/ruli/
mainly designed to support SRV records..

skadns
asynchronous stub resolver
C
Laurent G. Bercot 
http://www.skarnet.org/software/skadns/
Original BSD licence
"uses separate process" for asynch stuff -- ie non-threaded?

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

is there a point in keeping this bug in addition to bug 14328? (note also bug 14328 comment 41)

Comment 3

[Neil Harris]

Yes: SRV records are just one extra record type that is needed: there are also NAPTR records, TXT records, MX records, and so on... implementing any of these will require a new general-purpose DNS resolver framework.

Comment 4

[Jo Hermans]

In my company, we're using C-Ares, a fork from Ares. We're using it for SRV and NAPTR lookups, and as a base for a DNS-cache.  I highly recommend it.

http://daniel.haxx.se/projects/c-ares/

It has the same MIT-license, and is better maintained. It also has IPv6 and 64bit support.

Comment 5

[Neil Harris]

Jo, that's good to know; I'll take a look.

Here are another two:

Librascal
Asynch I/O framework with DNS lookups, does SRV and IPv6 lookups
C++, with a C API available
The Faerion Team
http://faerion.sourceforge.net/doc/librascal/
GNU LGPL

Libsrv
"Easy netconnect library w/ DNS SRV RR"
C (but also Python[?] if so, it's no use for Moz projects)
http://libsrv.sourceforge.net/
BSD License 

Comment 6

[Neil Harris]

And, in addition:

Libbind
Resolver library from ISC BIND
C
Internet Software Consortium
http://www.isc.org/index.pl?/sw/bind/
BSD-like
Seems to work on Windows, Mac OS X, Linux and other POSIX-like systems
Is it asynchronous? Does its license contain an advertising clause?

Comment 7

[Neil Harris]

libdjbdns
Replacement for libbind
C
DJ Bernstein
http://cr.yp.to/djbdns.html
Public domain 
DJB has a good record for producing secure software, and PD status means no licensing problems

I like this: I will take a closer look at it...

Comment 8

[Neil Harris]

Judging by the proposed patch for bug 14328, the plan there is to use the built-in support for the res_query() interface in glibc for POSIX systems, and the DnsQuery_A interface in Win32. 

My impression from Googling around is that the glibc code is based on the BIND stub resolver libraries, and that the glibc 2.2 version is now thread-safe, although other previous versions were not.

Comment 9

[Neil Harris]

I've added a note to bug 14328 suggesting that if the SRV support proposed there should be implemented in a generic way at its lowest level, effectively closing this bug at the same time, whilst avoiding code duplication.