cnames...

Tal Dayan tal at zapta.com
Sun Mar 4 07:21:58 UTC 2001


>
> Erik, you haven't answered Peter's question. He asked what
> happens when you query the NS'es for the *domain*itself*, e.g.
> foo.com, and a foo.com CNAME exists. I.e. he was contemplating
> the (currently illegal) case of
>
> @         soa (etc.)
> @         ns ns1.foo.com.
> @         cname bar.com.
>
> Should the nameserver return the NS records for QNAME
> ("foo.com"), or for the canonical name ("bar.com"), in that case?
> Because of the "CNAME and other rule", this situation currently
> nevers comes up. But if -- as you propose -- we abrogate that
> rule, then the ambiguity has to be resolved somehow. How would
> you resolve it? This is **critical* to your
> proposal.



Without getting to into the technical details of BIND and DNS (which I am
not familiar with), I think the server should return a response depending on
what the client looking for. It is that simple. If the client wants to map a
name to an IP, it should return an A record (if any) or will refer the
client to the right hand of the CNAME. If the client is looking for
information about the domain itself, it should return the soa, ns etc. If
the client is looking for a mail server mapping, it should return the MX
record.

This is a  very simple and intuitive principle which is already used to some
extent (e.g. you can have an MX and an A record of the same name, one for
mail mapping and the other for IP mapping).

Now, if the current standard/implementation has some singular restrictions,
the challenge is how solve them once in the tool itself rather than leave it
to the thousand of user to resolve it independently with all kind of complex
workarounds (writing a script that periodically update the zone file, have
up to the minute coordination of remote IP changes, wait until your service
is down and then fix it manualy, just respond to www.company.com and ignore
users that type company.com, and other workarounds that were mentioned in
this list).

How would you response if your car dealer would tell you that your new car
has just one small restriction, whenever you are in a street whose name
matches your last name, the reverse gear does not work. And yes, there is a
workaround for that. This is exactly how the
CNAME-everywhere-except-for-the-domain-itself looks from a user viewpoint.
Yes, I am sure that there are good historic reasons for this  but the focus
should be directed to solve the restriction and not just telling users that
this exception actually make sense and is the preferred behavior of the
system.

Tal

A DNS User.


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



More information about the bind-users mailing list