cnames...
Brad Knowles
brad.knowles at skynet.be
Sun Mar 4 10:48:44 UTC 2001
At 11:21 PM -0800 3/3/01, Tal Dayan wrote:
> Without getting to into the technical details of BIND and DNS (which I am
> not familiar with), I think the server should return a response depending on
> what the client looking for. It is that simple. If the client wants to map a
> name to an IP, it should return an A record (if any) or will refer the
> client to the right hand of the CNAME. If the client is looking for
> information about the domain itself, it should return the soa, ns etc. If
> the client is looking for a mail server mapping, it should return the MX
> record.
No, it's not that simple. The RFCs explicitly say that a CNAME
cannot occur with other data at that node, and anything else is an
error. The problem is that not sufficiently enforcing this rule in
the past has gotten us into the situation we're in now, and we simply
cannot afford to do this any longer. Indeed, we would all have been
much better off if this kind of behaviour was properly enforced long
ago.
If you want to change this behaviour back, then I suggest you go
try to get the RFCs modified to suit. When that happens, and your
modifications become the next "Recommended Standard" in this area,
then you can be pretty well assured that BIND will follow suit.
However, until then, don't try to argue something without
understanding the RFCs and the technical details involved. A lawyer
that tried to argue a case in court by first openly stating their
ignorance of the law and then blatantly disregarding that law
wouldn't have any more success there than you will here by trying to
argue this matter using the methods you've attempted to use so far.
Understand the RFCs, understand the technical reasons behind the
RFCs, or don't bother trying to argue the point. Otherwise, you're
just wasting your breath and everyone's time.
--
======================================================================
Brad Knowles, <brad.knowles at skynet.be>
More information about the bind-users
mailing list