cname quick question
Mark.Andrews at nominum.com
Mark.Andrews at nominum.com
Thu Mar 1 23:37:08 UTC 2001
> Mark,
>
> Following your excellent example:
>
> There is a CNAME present at the node, so the request for the SOA/NS record
> will be restarted with the QNAME changed to the target. The SOA will
> then be returned from the canonical name.
Correct. You want to have both a CNAME and SOA and a NS
RRset at the same owner name. Now depending upon the order
of queries made I get *different* responses for a SOA and
NS queries.
This is why your proposal does not interoperate with the
current resolvers despite everything you keep saying.
>
> --> The query will not fail if the algorithm is follwed.
The query did fail as it did not return the "correct" SOA /
NS record. It did follow the algorithm. It looked for
a SOA / NS record in the cache failed to find one, found
a CNAME and followed it.
Now DNSSEC went ahead with the same problem. However in
the DNSSEC case it was with a new types knowing that the
existing base would not cache the new types. Anyone look
up a DNSSEC record knows that they might have this failure
mode and can take steps to ensure that it is not a problem.
Your wanting to do the same thing with well known types
that will be cached. You are proposing a change that will
destabalise the existing base. While failing to acknowledge
that it will do that.
You keep saying that pre 8.2.3 supports CNAME and SOA / NS
records at the same node, despite us telling you as the
developers that it was not supported, and that anyone with
those versions can check that it was not supported. Use
a tool other that nslookup and make the queries of a zone
with and without a CNAME at the apex and look at the
differences in the answers returned. They don't just vary
by just the contents of the records. Try to perform a zone
transfer it will FAIL.
Now Eric of all the real life examples you have seen for
CNAME vs SOA, would they not have also been solved by the
solution space to the CNAME vs MX issue. I know I have
seen vastly more complaints about CNAME and MX vs CNAME
at top of zone.
I also know that people want to be able to mail to
user at example.com at the same time as the want to be able
to use http://example.com where the http is served by a
hosting company and the mail is in house. Adding support
for CNAMES at top of zone does not solve this problem.
It would solve the plain http://example.com but we all
know that is the less common and a short term problem
that invariable graduates into the bigger problem.
You have been told to write your proposal as a draft. Do
that listing all the ways that it breaks existing functionality,
how existing servers will behave under the new regime
including the effect on the old caches when lookup data
below the zone apex and the resulting additional traffic,
list the percieved benefits over the solution space for MX
vs CNAME. Be sure to check a number of different caching
servers from different sources. Don't assume that they
all have BIND's behaviour when it comes to dealing with
proposed change.
Go read RFC 2308. It made non-compatible changes. It also
listed all the sort of things we have been asking you to
list so that they could be evaluated and be documented as
a reference for people that were having problems in the
future.
Mark
>
> Other results:
>
> The SOA present at the zone-top will never be cached/used except
> in requests which prevent chaining, IE: requests for the CNAME itself or for
>
> other domains in the zone file. Likewise, the NS records will only be used
> for the authority section in non-chained requests.
>
> If you consider the meaning of NS/SOA records - this behavior is correct.
> (Or as close to correct as possible - since there really should have been
> *two types of NS records*, as was pointed out earlier on namedroppers)
>
> That's it. Where do you foresee failure/doom in this? Bear in mind that
> this is how BIND resolver used to behave in versions 4 through 8.2.2
> when CNAME's were not prevented from being in the zone top.
>
> - Erik
>
>
> -----Original Message-----
> From: Mark.Andrews at nominum.com [SMTP:Mark.Andrews at nominum.com]
> Sent: Thursday, March 01, 2001 10:49 AM
> To: Erik Aronesty
> Cc: 'Jim Reid'; bind-users at isc.org
> Subject: Re: cname quick question
>
>
> >
> > JIM>Please *read* the extract from RFC1034 above. Now *think* about what
> > JIM>it says and what that means. Pay particular attention to the last
> > JIM>sentence. Hint: suppose clueless.example.com was a CNAME pointing at
> > JIM>moron.example.net. That CNAME is cached by some name server. It can
> > JIM>safely use that cached CNAME without having to query the example.com
> > JIM>name servers to check that no other record types exist for
> > JIM>clueless.example.com.
> >
> > 1- Suppose clueless.example.com was at the zone top with a "@ IN CNAME mor
> on.
> > example.net."
> >
> > 2- The CNAME can still get cached by a name server. The CNAME can still b
> e
> > safely used from the cache -and no other record types ever have to be q
> uer
> > ied -
> > since the SOA and NS record types are transmitted in the authority sect
> ion
> > .
>
> The problem is once the CNAME is cached you can't retrieve
> the SOA or NS records. i.e. "dig NS clueless.example.com"
> or "dig SOA clueless.example.com" will FAIL.
>
> People have as much right to query for NS and SOA records
> as any other type. You seem to think that the only way
> they can be transmitted is as a side effect of a query for
> some other type. THIS IS FALSE.
>
> >
> > 4- You example just shows that you arent' paying attention.
> >
> > - Erik
>
> Erik you are the one that is not paying attention. Your
> changes will not interoperate cleanly with the exist resolvers.
>
> It doesn't matter how many time you say they will when you
> have proved by your own examples that they don't.
>
> Mark
> >
> >
> > --- thread below ---
> >
> > -----Original Message-----
> > From: Jim Reid [SMTP:jim at rfc1035.com]
> > Sent: Thursday, March 01, 2001 5:16 AM
> > To: Erik Aronesty
> > Cc: bind-users at isc.org
> Subject: Re: cname quick question
> >
> > >>>>> "Erik" == Erik Aronesty <erik at primedata.org> writes:
> >
> > >> If a CNAME RR is present at a node, no other data should be
> > >> present; this ensures that the data for a canonical name and
> > >> its aliases cannot be different. This rule also insures that a
> > >> cached CNAME can be used without checking with an authoritative
> > >> server for other RR types.
> >
> > Erik> Exactly. How does having a CNAME at the zone-top cause this
> > Erik> to be an error? For that mater how does having an SOA
> > Erik> record fail to allow cached CNAMES to be used without
> > Erik> checking an authoritative server for other RR types? It
> > Erik> doesn't. Because the SOA record is used for zone transfers
> > Erik> and cache/timing information itself. The RFC neglected to
> > Erik> mention that. That's all.
> >
> > JIM>Like Tal Dayan, you are being obtuse or deliberately provocative.
> > JIM>Please *read* the extract from RFC1034 above. Now *think* about what
> > JIM>it says and what that means. Pay particular attention to the last
> > JIM>sentence. Hint: suppose clueless.example.com was a CNAME pointing at
> > JIM>moron.example.net. That CNAME is cached by some name server. It can
> > JIM>safely use that cached CNAME without having to query the example.com
> > JIM>name servers to check that no other record types exist for
> > JIM>clueless.example.com.
> >
> > 1- Suppose clueless.example.com was at the zone top.
> >
> > 2- The CNAME can still get cached by a name server. The CNAME can still b
> e
> > safely used from the cache -and no other record types ever have to be q
> uer
> > ied -
> > since the SOA and NS record types are transmitted in the authority sect
> ion
> > .
> >
> > 4- You example just shows that you arent' paying attention.
> >
> > - Erik
> >
> >
> >
> --
> Mark Andrews, Nominum Inc.
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews at nominum.com
>
>
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews at nominum.com
More information about the bind-users
mailing list