[dns-operations] A problem with using DNAMEs in reverse lookups

Chris Thompson cet1 at cam.ac.uk
Sat Apr 2 22:15:46 UTC 2011


For some time we have been experimenting with a scheme for reverse zones
inspired by RFC 2317 but using DNAMEs rather than CNAMEs. There is a
sketch of it at

  http://people.pwf.cam.ac.uk/cet1/prune-reverse-zones

During our latest application of this, we came across an unexpected problem,
and I wonder if anyone else using DNAMEs as part of reverse lookup resolution
has encountered anything similar.

For the first time, we applied it to hosts that were emitting e-mail
directly to the Internet in general, rather than via our central mail
systems. (We have port 25 blocks at our border routers for most of our
network addresses, which is why this hasn't arisen before.) Occasional
hosts pointed to by MX records started rejecting attempts to send e-mail
from these hosts, saying either that they had no reverse lookup, or
that reverse lookup had "failed". The latter is the case for the targets
of the MX records for "comcast.net" - a particular embarrassment.
(You get a 421 error on connecting, rather than the 554 you get if you
really had no reverse lookup.)

The results of a reverse lookup for these hosts, after the change,
look like

 nnn.232.128.in-addr.arpa.     DNAME nnn.232.128.in-addr.arpa.cam.ac.uk.
 mmm.nnn.232.128.in-addr.arpa. CNAME mmm.nnn.232.128.in-addr.arpa.cam.ac.uk.
 mmm.nnn.232.128.in-addr.arpa.cam.ac.uk. PTR xxx.yyy.cam.ac.uk.

(Try any address in the top half of 128.232/16.) The CNAME is "synthesised"
from the DNAME, of course. When I started investigating the e-mail
problem, I expected to find that the offending hosts couldn't cope
with RFC 2317 style reverse lookup results at all, but in all cases
investigated so far, this turned out not to be the case. They work
correctly if the result consists of just a CNAME followed by a PTR,
in basic RFC 2317 style. It's the DNAME that causes them to misbehave.

Has anyone else come across resolvers that behave like that?

[We have reported the problem to postmaster at comcast.net, incidentally.
No human response yet.]

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: cet1 at ucs.cam.ac.uk    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.



More information about the dns-operations mailing list