cnames...

[Erik Aronesty]

Peter,

Is an SOA record "other data"... since it is used, "for the maintenance of the DNS" and it is not, itself, a resource record queried by dns clients?  The original RFC actually does not address this point.

Most would argue that it is more like a "SIG/KEY/NXT" record (also used for the DNS protocol itself - and is not a real 'record' by this definition).

These records *can be present with CNAME's* according to RFC 2535 and the latest implementations of BIND.
	See RFC 2535 section 2.3.5
The intent of the wording in 1034/1035 was to prevent ambiguous RR's from existing in two places that would be queried by DNS clients.  This was probably a misinterpretation of the original RFC - which was not clear on this point.

It was a bit of a pain to code the validations correctly (IE: CNAMES conflict with all records except SIG/KEY/NXT/SOA/NS) - and was far easier to simply make them more restrictive.

If you want to get this to work temporarily, simply comment out the ++errs statement in the load_db.c.

There should be a draft/rfc for the clarification of RFC 1034 and RFC 1035 on this particular point.

		- Erik

-----Original Message-----
From:	peter at icke-reklam.ipsec.nu.invalid [SMTP:peter at icke-reklam.ipsec.nu.invalid]
Sent:	Monday, February 12, 2001 3:35 AM
To:	comp-protocols-dns-bind at moderators.isc.org
Subject:	Re: cnames...


Tien Nguyen <inetcam at yahoo.com> wrote:
> This zone file worked fine under 8.2.2 but not 8.2.3.

> ;=============

> $ORIGIN com.
> my-domain          IN      SOA     my-domain.org. root.my-domain.org. (
>                 62 10800 900 604800 86400 )     ;Cl=2
>                 IN      NS      ns.my-domain.com.  ;Cl=2
>                 IN      CNAME       www.other-name.com  ;Cl=2

> ;=============

> If I delete the CNAME record or use an A record to point the the same IP as
> www.other-name.com then the zone got resolved with 8.2.3

> Is there an explaination for this?

Yes.

A CNAME RR may not be present as any other data ; i quote rfc1034 sec 3.6.2 :
"If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different.  This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types."

In the above the zone has a SOA, and one NS record. Thus a CNAME is illegal.

Most versions of bind may be configured to override this ( at you own risk)
8.2.3 have stricter defaults.



> Thanks,
> Tien Nguyen


> "Cricket Liu" <Cricket at VeriSign.com> wrote in message
> news:95mis2$mn4 at pub3.rc.vix.com...
>>
>> >> The solution is to add an
>> >> address record pointing your zone's domain name to the the address of
>> >> your web server.
>> >
>> > In this case there is no simple "address" at the root, the domain name
>> has]
>> > to point to a BGP4 thing run by Akamai that changes all the time
> depending
>> > on where you are.
>> >
>> > I'm pretty sure that the fact that the CNAME record conflicts with
> SOA/NS
>> > records is simply an oversight in RFC1034/3.6.2.  Logically, no record
>> type
>> > should "conflict" with the SOA.  The SOA isn't a normal record type,
> it's
>> a
>> > definition of the zone's maintenance parameters.  Also, the fact that
> all
>> > resolvers on all platforms work with this information is evidence that
> the
>> RFC
>> > may have been severely flawed.
>>
>> Well, that's an interesting theory.
>>
>> > So far, my solution has been to patch BIND 8.2.3 - which works quite
> well.
>>
>> Okay, it's your zone.
>>
>> cricket
>>
>>
>>
>>




-- 
Peter Håkanson               Phone     +46707328101       Fax +4631223190
IPSec sverige                Email      peter at ipsec.nu  
"Safe by design"             Address    Bror Nilssons gata 16  Lundbystrand
                                        S-417 55  Gothenburg   Sweden