udns questions

[Michael Tokarev]

Markus Koetter wrote:
> Hi,
> 
> after i got sick using libadns, i was looking for a smart async dns 
> resolving library supporting ipv6 and offering a more powerfull 
> interface as libadns, thats how i found udns.

Wondering what's wrong with adns from the usage point of view, really.
I had specific reasons why I didn't like it for one of my applications,
which was mostly scalability and memory usage probs.

> So far i just had a look on the api description and did not code with 
> it, because there is one thing im not sure about.
> 
> udns ist just udp based dns reslving, are there any disadvantages even 
> if you support extended udp dns requests?

Sure there are disadvantages.  And sure it greatly depends on the usage
scenario.  Ans sure there are "however"s. ;)

The whols stuff is simple: if a reply packet does not fit into a single
standard (w/o extensions) DNS UDP packet, which is 512 bytes, udns will
not be able to receive the reply (note this also depends on the resolver
server used: for example, BIND will send real reply truncated to 512
bytes, which may be sufficient as the end of the packet contains
additional information which isn't normally needed by client application;
while eg djbdns (dnscache) will only send header of the answer, which
contains no answers at all. But dnscache will not fill in "unnecessary"
additional entries (djbdns does not support EDNS0), so overall size of
packets will be smaller).

Whenever it is a problem or not -- it depends.  Especially it depends
on which records you're asking for.  For example, when you ask for
A (AAAA) records, it's very unlikely you will hit too large reply,
not because A record is small or there (usually) not many records,
but because such a reply compresses very well in vast majority of
cases.  There are several quite popular applications which perfoms
UDP-only DNS lookups for A records out there, notable example of
this is squid proxy cache -- you understand that in case of this
being a problem for squid, users will notice it quite fast ;)

If you lookup PTR records, there can be more problems with stupid
cases.  Some hosters sometimes does, for whatever unknown reason,
a weird thing: for their eg webserver IP address they list *all*
domains hosted by this server, and such a list can be qulte large.
Such sites are having problems with dsbl.org removals for example
(dsbl.org requires rDNS for removals) -- somewhat dumb robot running
on dsbl.org side can't pick up the "right" PTR and gives up, so
they're forced to correct their rDNS.

So, to summarize, UDP-only approach works in a fair number of cases,
and may fail (depending on the *local* conditions) in a very few
weird cases.  Usage of EDNS0 gives much more chances to eliminate
failure (max size of the packet for udns is 64KB, most servers
supporting EDNS0 can use 2KB or 4KB packets -- it's 4x or 8x larger
than standard 512 bytes which is already "almost" sufficient).
See below for EDNS0.

> i dont know that much about the udp dns extensions, all i can say is i 
> heard it exists, so i thought it was the better idea to ask somebody who 
> made a design decision based upon his knowledge about this issue.

Speaking of EDNS0.

A good percentage of DNS servers nowadays supports it.  BIND (which is
running on about 90% of servers or more) supports it since version 8.
Microsoft DNS server supports it.  Most other opensource servers supports
it.  But that's about auth-only servers, which aren't of a good interest
here because udns is a stub resolver, supposed to work with local
recursive resolver.

Speaking of servers used as local recursive resolvers - well, here
the picture is less known.  BIND still represents a fair amount of
all servers.  M$ DNS (esp. recent ones) is also here.  DJBDNS does
not support EDNS0, but dnscache (used as local recursive resolver)
does not add "unnecessary" info to the packets so it have less chances
to overflow 512 bytes.

> and if there are disadvanatges, as dns server xy does not support it or 
> stuff like that, are there any plans to support tcp as well?

Note that "does not support" != "does not work".  EDNS0 is designed in
a way so that servers who aren't aware of it should work as before,
using standard 512-bytes replies (EDNS0 isn't only about packet size,
but it is the most interesting feature in this context).

And speaking of TCP sockets, there's a single problem with them:
supporting them isn't easy from the application point of view.
Because TCP sockets will be dynamic -- unlike UDP ones, which
gets opened at initialisation time and remains up to the end.
There will be a need to register/unregister new working socket
in the application select-loop somehow.  And regardless of how
I tried, I can't think of a good API here.

Implementing TCP mode isn't hard, but all the question is about
easy of use from the application point of view, and whenever
it's worth the effort to complicate usage case when in vast
majority of usage scenarios current very simple API is sufficient.

> i really hope there are no problems in extended udp dns usage as i 
> really would like to use udns :)
> the api looks great.

I was thinking about the API for quite a while, and yes, it is
currently the best I know of ;)  Thanks.

BTW, Do you mind me copying this message to udns mailing list for
future reference?

/mjt