cnames...

[Kevin Darcy]

No, changing the spec with respect to CNAMES is not the way to do this.
Implementing SRV records is the way to do it. If all clients understood SRV
records, then it would be a simple matter to say "machine bar.com handles all
of the HTTP requests for the name foo.com". You could specify these
redirections on a *protocol*by*protocol* basis, instead of using aliases, which
have no granularity at all. SRV also allows you to do load-balancing and
weighting. It is a far superior solution. Changing the CNAME rules would break
a lot of nameserver software and even when it worked it would be inefficient
(under certain circumstances, a recursive caching server would have to fetch
information from both the foo.com and bar.com zones in order to satisfy a query
where a CNAME was present, whereas with the current rule, it only needs to look
in one place).


- Kevin

Tal Dayan wrote:

> Hi Kevin,
>
> I really admire your knowledge of how DNS works, I hope to get to this level
> one day but for now I am a simple DNS user.
>
> >From a viewpoint of a user (me) it is a major restriction having to specify
> the IP for the domain. Many times these IP's are of remote servers and
> whenever they change, we suffer downtime until we detect the problem, make
> the change, and let it propagate.
>
> Since CNAME were invented to solve exactly this problem, it would be great
> (again, from a user viewpoint) if CNAME would work also for the domain
> itself.
>
> With you knowledge, can you think of a creative idea how to safely change
> BIND and/or the spec to eliminate this restriction ?
>
> Thanks,
>
> Tal
> tal at zapta.com
>
> > -----Original Message-----
> > From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org]On
> > Behalf Of Kevin Darcy
> > Sent: Friday, February 23, 2001 6:38 PM
> > To: comp-protocols-dns-bind at moderators.isc.org
> > Subject: Re: cnames...
> >
> >
> >
> > Erik,
> >       I'm going to brutally summarize this discussion thread,
> > since in my opinion it's off-topic to bind-users. (It belongs on
> > namedroppers, as I have repeatedly pointed out).
> >
> > Your basic proposal appears to be (correct me if I'm wrong):
> >
> >
> >      NS and SOA are "special" types because they are typically
> > used only between nameservers, not something that a normal client
> > would query. Given this, they should be exempted from CNAME
> > chaining, and therefore can be exempted from the "CNAME and other
> > data" rule as well, i.e. it should be legal for a CNAME to
> > co-exist with SOA and/or NS records. This would put an end
> > finally to the persistent confusion over the "CNAME and other
> > data" rule as applied to names of registered domains.
> >
> >
> > I can foresee at least 3 general objections to this:
> >
> > 1) It complicates name resolution in the case where a query comes
> > into a recursive nameserver, and all it has cached is a CNAME
> > which matches QNAME, but nothing for the target of the alias.
> > Currently, the decision of what to do next is simple: recurse to
> > the authoritative nameservers for the *target*'s zone. Under your
> > proposal, however, the nameserver needs to look at the query type
> > first. If it's an NS or SOA query, then it should recurse to the
> > nameservers for QNAME's zone, otherwise it recurses to the
> > nameservers for the CNAME target's zone. Is the benefit to be
> > gained here worth the cost of adding *yet*another*conditional* to
> > the critical path of the DNS resolution algorithm?
> >
> > 2) It violates "the principle of least surprise". Take the
> > following example: foo.com, a name which owns NS records, is an
> > alias for bar.com, where bar.com owns *different* NS records and
> > an A record. Doing a "dig foo.com a" yields the A record which is
> > ultimately contained in the bar.com zone. Doing a "dig foo.com
> > ns", however, yields the foo.com zone's NS records, since, under
> > your proposal, the CNAME isn't chained for an NS query. An
> > application or human which/who doesn't notice the indirection in
> > the first query might be incorrectly led to believe that the A
> > RRset and the NS RRset originated from the same zone -- a
> > reasonable conclusion, since the QNAME was the same for both
> > queries. Yet they are
> > from *different* zones, and thus the human or application could
> > be easily led astray, possibly with disastrous results.
> >
> > 3) It arbitrarily reduces the overall usefulness of the aliasing
> > mechanism. Why *shouldn't* I be able to point aliases at names
> > which own SOA and/or NS records and have them chain properly when
> > I do SOA and/or NS queries? Maybe I have domains many levels deep
> > and I want "friendly" aliases to those domains at some higher
> > level (which are more likely to be in my search path), so that I
> > can say just "dig foo ns" instead of "dig
> > foo.bar.blech.us.northamerica.earth.daimlerchrysler.com ns".
> > CNAMEs are supposed to provide a *general* aliasing mechanism,
> > but here you are carving out exceptions for record types you
> > consider "special". Where does that line get drawn? Every record
> > type is "special" in its own
> > way. Do we head down that slippery slope and eventually get rid
> > of CNAMEs altogether (as DJB proposes)? I think that would be a
> > great loss.
> >
> >                                                                  - Kevin
> >
> >
> >