No subject

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