cnames...

Erik Aronesty erik at primedata.org
Fri Feb 23 22:59:46 UTC 2001


-----Original Message-----
From:	Kevin Darcy [SMTP:kcd at daimlerchrysler.com]
Sent:	Monday, February 12, 2001 7:21 PM
To:	comp-protocols-dns-bind at moderators.isc.org
Subject:	Re: cnames...


Erik Aronesty wrote:

> 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?

It *is* "other data" and, yes, it *can* be queried explicitly by DNS clients, which happens quite frequently between masters and slaves (in that case, the slave doing the serial-number check is functionally a client). 

This is correct.  However in the case of AXFR/IXFR master's and slaves IGNORE CNAMEs.

Also, I would consider master/slave query part of DNS maintenance - and not the typical DNS client (ie: a browser/mail server).

An SOA record
can, unlike most record types, even appear by itself in an Authority Section, without even having been explicitly requested by the client, 

That's right!  And thus ALL CNAME's have implied SOA records associated with them.  

Example 1: the SOA for a zone applies to the CNAME record itself - for the purposes of synchronizing the master/slave (how else could a CNAME be cached?  What expiration would it use?)

Example 2: When performing an IXFR query - and the CNAME is the RR that changes what SOA do you use in the authority section?

The problem is that when performing an nslookup -type=SOA on a CNAME, you get data that is unusable (ie: you get nameserver that knows nothing about the domains) - since SOA info is chained in client utilities.

SOA and NS data should not be chained under normal operations.  I can't (yet) imagine good reason for chaining them - and there's a lot of reasons why you shouldn't

and in fact RFC 2308 mandates this under certain circumstances. SOA records received in
responses can and should be cached (subject to the credibility ranking rules, of course). They can then subsequently expire from cache and need to be fetched again from an authoritative server, just like "real" data records.
SOA records aren't "meta-data" like TSIG or OPT. They don't just get synthesized for a particular transaction and then vaporize instantly afterwards. SOA records are part and parcel of the DNS database itself. They are no less
"data" than an NS record or an A record.


By the way, where are you quoting "for the maintenance of the DNS" from? 

RFC 1035 section 3.3.13

I don't find that phrase in either RFC 1034 or 1035. If you're going to play an RFC lawyer, you should at least learn how to cite correctly.

I'm not an RFC lawyer.  I think that RFC 1034/5 (the 'originals') are a bit muddled in this point - not BIND.  BIND follows the RFC dutifully.  

SOA's/NS's should be exempt from conflicting with CNAMEs, and should possibly be exempt from chaining (yes, chaining is a real term).

> 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).

SIG/KEY/NXT are not "used for the DNS protocol itself", as evidenced by the fact that the DNS protocol got along just fine without them -- albeit less securely -- for many years. SIG/KEY/NXT come as part of the DNSSEC *extensions* to DNS which are currently optional. But, the point is moot, since SIG/KEY/NXT aren't "meta-data" either (except for the special case of SIG(0)). SIG/KEY/NXT records, when present, also become part of the DNS database (although, admittedly, they are a *dependent* part inasmuch as they only make sense in relation to other records existing in the database; in fact, it is this attribute of dependency which gives rise to their exception from the "CNAME and other data" rule).

Exactly1 SOA/NS records also only make sense in relation to other records - they describe how records are cached and where they reside - they are, like SIG/KEY/NXT records - precisely as you described them above.

> 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

I've already explained this.

Yep.

> 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.

The "original RFC" is, for all intents and purpose, the matched pair of RFC 1034 and 1035. 

Of course.

Given that, your paragraph makes little sense (i.e. the intent of RFC X was Y, which was a misinterpretation of RFC X). Or did you mean some
other "original RFC"? Be specific.

Specifically, the description of CNAME's mentions that they are not "simple data" and that there are "special conditions" involving them.  This CNAME/SOA is a non-simple "special condition" which was improperly addressed and needs to be clarified.  

In any case, if there was some other "original RFC", it was *superceded* by RFCs 1034/1035, which are quite clear that prevention of data inconsistency was one of the justifications for the "CNAME and other data" rule.

Actually, the current behaviour of resolvers chaining SOA requests, but not chaining auhority sections during IXFR requests, is clearly evidence of "data inconsistency"

> 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.

How can you reasonably claim to know how much "pain" it would require in order to code the validations? Have you tried doing it? Or are you just tossing out baseless speculations?

I patched BIND 8.2.3 to allow CNAMES with SOA/NS - but no other data.  It was a pain.

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

In my opinion, there's nothing that needs clarifying. But feel free to float your proposal on namedroppers. For that matter, feel free to publish a clarifying Internet Draft yourself. See http://www.ietf.org/ietf/1id-guidelines.txt
and http://www.ietf.org/ID-nits.html.

                                                                                                                                                - Kevin


> -----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









More information about the bind-users mailing list