So far I think Wayne and Stuart talk about different APIs,
Wayne is somewhere above the resolver, Stuart is inside of
it. And your problem is again different.
I went and looked at rfc1035. It doesn't address the issue of
which software layer is responsible for following CNAME, and how many links
should be followed. It says the following:
CNAME RRs cause no additional section processing, but name servers may
choose to restart the query at the canonical name in certain cases. See
the description of name server logic in [RFC-1034] for details.
Which to me says just what I said about servers following CNAME on a best
effort basis.
I also went and looked at the C code for squid. It uses resolv.h, but
does not have to deal with CNAME (unless I missed it). So, appararently
the resolv.h API handles CNAME automatically.
I looked at RFC1034. It says that name servers should restart start
queries for CNAME and include both the CNAME record and the result of
querying the canonical name. It does not say what to do if the
chain is too long to fit in a UDP packet.
It also says that resolvers should be able to handle chains and loops:
Of course, by the robustness principle, domain software should not fail when
presented with CNAME chains or loops; CNAME chains should be followed and
CNAME loops signalled as an error.
It does not say how many links to follow, or which layers should handle
CNAME.
It says that answers to recursive queries should follow CNAME:
The answer to the query, possibly preface by one or more CNAME RRs that
specify aliases encountered on the way to an answer.
It does not give a maximum number of CNAME RRs.
Taking a closer look at the squid code, it ignores CNAMES and other
extra data (e.g. NS). If no A records are found in the answer packet,
it raises an rfc1035_unpack_error. This effectively limits the length of a
CNAME chain to whatever will fit in a UDP packet along with all the A records.
IN CONCLUSION, Wayne is correct in that rfc1034 (not 1035) tells the name
server and recursive queries to follow CNAMES and include them in the answer.
However, it is silent on how to handle long chains that will not fit in
a UDP packet with the target answers - the default action is to return
a packet flagged as "partial results".
rfc1035 tells DNS software to "handle CNAME chains and loops". Possible
strategies include switching to a TCP query, continuing to reissue queries from
the last received CNAME (what pyspf does), and punting by giving up when there
are "a lot" (what squid-2.5 does).
At least one client (squid) of the resolv.h C API "handles" CNAME by ignoring
it in the answer packet, trusting that the name server and/or recursive
query has already followed all of them - raising an error if they haven't.
However, the resolv.h API does not do anything special to handle them - as I
stated.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.