async dns

Marc Lehmann schmorp at schmorp.de
Tue Mar 17 23:38:07 CET 2009


On Tue, Mar 17, 2009 at 12:39:40PM +0100, "W.C.A. Wijngaards" <wouter at NLnetLabs.nl> wrote:
> cname-to-cname is legal (RFC1034) says 'fairly long chains' are legal.

rfc1034 says no such thing (I just searched it).

rfc1034 explicitly says that cnames are not allowed to point to other cnames:

   A CNAME RR identifies its owner name as an alias, and specifies the
   corresponding canonical name in the RDATA section of the RR.

It also explicitly says later that cname-to-cname should not be done.

Of course you know and I know that rfc1034 is a piece of crap and not
worthy of being called a specification, but cname-to-cname is definitely
ruled out in it (even though it mentions robustness principle yada yada).

So a dns resolver ruling it out is certainly within the letter of the rfc
(nowhere does it say that this must be supported, or to which length), it
just fails the reality test.

> > c) like many other "asynchronous resolvers" it is of course fully synchronous
> >    and even blockign when it has to fall back to e.g. virtual circuit mode
> >    (for large replies). this is not uncommon.
> 
> At least I did this right ...

Frankly, I was totally pissed off when our product literally hung for
hours due to this (and subsequently wrote our own stub resolver), and
found out that the state of the art is either:

a) huh? tcp? it exists??
b) of course we do tcp, but unfortunately our api doesn't support doing this
   event-based.

(libadns is special in that its api deos support it, but it doesn't
implement it event-based :()

so, great to hear :)

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list