erik at primedata.org
Fri Mar 2 16:35:09 UTC 2001
When someone requests the namervers of an alias - the canonical name's nameservers are returned - even though the zone's nameservers are available. This is not a "new" thing in DNS.
@ IN NS ns1.foo.com
dom IN CNAME bar.com
nslookup -type=ns dom.foo.com
returns the ns records from bar.com
That's how CNAME's work.
From: peter at icke-reklam.ipsec.nu.invalid [SMTP:peter at icke-reklam.ipsec.nu.invalid]
Sent: Wednesday, February 28, 2001 6:56 AM
To: comp-protocols-dns-bind at moderators.isc.org
Subject: Re: cnames...
Tal Dayan <tal at zapta.com> 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
CNAME creates an ambiguity THATS the problem.
When delegating a domain the NS record is required to have
a FQDN on righthand side. What heppens when someone searches
for NS records of a zone and finds a CNAME ? Which nameservers
should be asked for that zone ? Which MX records is to be used ?
Come on, if you host a domain and cannot keep track of
which IP they use, i'll call it lack of organization.
> With you knowledge, can you think of a creative idea how to safely change
> BIND and/or the spec to eliminate this restriction ?
> 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...
>> 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
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