async dns

W.C.A. Wijngaards wouter at
Wed Mar 18 08:30:36 CET 2009

Hash: SHA1

Hi Marc,

Marc Lehmann wrote:
> On Tue, Mar 17, 2009 at 12:39:40PM +0100, "W.C.A. Wijngaards" <wouter at> wrote:
>> cname-to-cname is legal (RFC1034) says 'fairly long chains' are legal.
> rfc1034 says no such thing (I just searched it).

You are right, I must have seen it somewhere else.

Now I find it; I saw it in RFC2672 (end of section 3) about chains of
DNAMEs (which I treat similar to CNAMEs).

All this searching gave me RFC1035 section 7.1. which has some advice
how to implement sane (I mean: cautious) CNAME processing.

> rfc1034 explicitly says that cnames are not allowed to point to other cnames:
> It also explicitly says later that cname-to-cname should not be done.

RFC1034 does say in section 5.2.2 (Aliases):
  Multiple levels of aliases should be avoided due to their lack of
  efficiency, but should not be signalled as an error.

So, it is right by avoiding it, and wrong for signalling the error. Of
course it does not say how many levels is OK and how many an error, so
anyway...  I believe we already agree, but just RFC1034 doesn't say so.

>>> 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 ...
[ snip horror story of the 'asynchronous resolver' ]
> so, great to hear :)

I took a lot of care, because I also had to do probing for DNSSEC
capabilities and building chains of trust; while remaining event based.
And sometimes DNSSEC packets may trigger TCP because of their size.

And it works with libev :-)

Best regards,
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the libev mailing list