cnames...

[Derek J. Balling]

Fine, users may like it differently.

However, since DNS is a TECHNICAL issue, and not a "market-driven" one, if
the users feel compelled to make it work that way, they must (a) learn the
technical issues, and then (b) address them, in order, and finally (c)
publish a standards-track RFC and hope for acceptance by others.

D

At 10:54 AM -0800 3/4/01, Tal Dayan wrote:
>Hi Brad,
>
>My main point is that the singular restriction of
>CNAME-everywhere-except-for-the-domain-itself of the standard and/or BIND is
>not the prefered behavior from a user viewpoint but a result of some
>historic and technical issues.
>
>Let's recognize this first.
>
>Tal
>
>> -----Original Message-----
>> From: Brad Knowles [mailto:brad.knowles at skynet.be]
>> Sent: Sunday, March 04, 2001 2:49 AM
>> To: Tal Dayan; Kevin Darcy; comp-protocols-dns-bind at moderators.isc.org
>> Cc: erik at primedata.org
>> Subject: RE: cnames...
>>
>>
>> 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>
>>

-- 
+---------------------+-----------------------------------------+
| dredd at megacity.org  | "Conan! What is best in life?"          |
|  Derek J. Balling   | "To crush your enemies, see them        |
|                     |    driven before you, and to hear the   |
|                     |    lamentation of their women!"         |
+---------------------+-----------------------------------------+