DNS alias found where canonical name expected errors...

[jschultz]

Ian Jackson wrote:
> 
> In article <9ba8db$cr6 at pub3.rc.vix.com>, jschultz  <jschultz at jhu.edu> wrote:
> >Hey guys, I know this question was asked and answered before but I'm
> >still having problems with looking up machine names that have chains of
> >CNAMEs.
>
...
> adns never follows more than one CNAME.  This is to avoid the need for
> complicated loop detection algorithms or arbitrary limits on the
> number of CNAMEs which will be traversed.  If adns finds that the
> target of a CNAME is another CNAME, you will get the `DNS alias found
> where canonical name wanted' error, which is an adns error code.
>
Doesn't a named (a la BIND8.2.3-REL) that supports CNAME chains _HAVE_
to do some form of loop detection? Whether it be an arbitrary chain
length or explicitly remembering and testing for a cycle? If it didn't,
and it followed CNAME chains wouldn't it just churn forever (until it
crashed if stupidly implemented)? Or are there other mechanisms/limits
that would eventually kick in and stop the lookup cycle? 

If you know the named resolver you are using is already doing cycle
detection for you, then it seems to me that there is no need to
replicate this checking in the stub resolver. It sounds like this
enforcement of the RFC should be a compile
(-D_TRUST_NAMED_LOOP_DETECTION) or runtime (adns_qf_follow_cname_chains)
option. Then it is the library builder/user's responsibility to ensure
their nameds enforce some form of loop detection.
 
> adns will also not by default follow CNAMEs found as a result of MX or
> similar lookups; this can be relaxed with the `loosecname' query flag.
> However, the CNAME chain prohibition cannot be relaxed.  Simply
> removing the test for the error condition would make the resolver go
> into an infinite loop when it found a CNAME loop.
> 
The named's UDP response packets are finite. If they are truncated
because the responses are too big, then again some mechanism (in any
decent named that follows CNAME chains) must eventually kick in and stop
following the chain. I don't think there exists a reputable named that
blithely follows CNAME chains forever and therefore would be able to
generate an infinite response session -- but if you still want to
protect against this I would say make it an option of some sort. ADNS
works by just iterating over the records in the response packet/session
right? It doesn't loop back to any previous point in the response packet
-- if that is the case and the response is finite it can't go into an
infinite loop, right?

Also, why do nslookup and dig not report errors when they run across
CNAME chains? They must be tolerating the condition and assuming that
the named is doing the appropriate thing?

> So, in summary, your zone data is wrong and you must fix it.
> 
It isn't my zone data to fix and I can't spend my entire life going
around telling people to fix their messed up records.

Ian, could you answer my other question about libadns?

(1) You seem to be doing some explicit memory management inside your
structures. Will allocating over qu->cname_dgram and qu->answer->cname
without explicitly releasing them cause a memory leak? Or will your
memory
lists clean them up as well later when the query and answer are
released?

(2) Are there any other subtle side effects removing the CNAME chain
check could
have?

Thanks in advance,

John Schultz
Research Assistant
The Center for Networking and Distributed Systems
The Johns Hopkins University