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