Re: [Ldapdns-users] CNAME alias

[Mrs. B. <mrs...@ni...>]

"Have you stopped beating your wife yet?"
(Note, J.deB has some really good pages about how to ask questions :)

The behavior that J.deB describes is not a bug or does it violate RFC 1034- that section
is describing an ALGORITHM-- a particular one that only makes sense to BIND/derivatives.

It wouldn't even make sense to BIND if it's cache were disabled.

The algorithm _suggested_ in the particular section J.deB is interested in is ridiculous
for content-only nameservers. It is only possible if you have a cache. Using J.deB's
patches will cause you to be unable to answer certain kinds of queries.

That said, LDAPDNS 3 (or LDAPDNS 2 with some scary patches, IIRC) _will_ follow cNAMES
efficiently in an effort to save wan traffic IF it's not a hard question to answer-
and besides the user will probably be asking it soon anyway.

Caches may inspect the additional section to see the answer to the "next question"
and perhaps save a trip.

It may look an awful lot like the algorithm suggested- but it differs if it doesn't know
about that new host- AND it always uses the original question name. But then, LDAPDNS 3
doesn't allow you to make retarded CNAMEs anyway (cname host1.example to host2.example--
it simply answers questions about host1 with host2's data)- so it could be said that
by using LDAPDNS you can't answer certain kinds of questions.

Fortunately, if you really want to give retarded answers and you are one of the four
people on planet earth that actually know what CNAMEs are/do, you have the ability with
LDAPDNS to get behavior much more similar to tinydns.

On Sat, 2003-11-29 at 09:42, Petr Okurek wrote:
> Hello Mrs. Brisby,
> I have a question. Does the ldapdns 2.05 have a truncation of alias chains
> or
> it's behaviour is according to the alogorithm in RFC 1034?
> More details on
> http://homepages.tesco.net/~J.deBoynePollard/FGA/djbdns-problems.html#tinydn
> s-alias-chain-truncation