cnames...

[Kevin Darcy]

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

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

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

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

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.

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

> 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