cnames...

[Erik Aronesty]

Kevin, 

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.

IE (abbreviated):

---foo.com zone---
@ 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.

			- ERik

-----Original Message-----
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
> itself.

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.

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




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