On Oct 16 2009, Alfred Hönes wrote:
On Oct 16 2009, Chris Thompson wrote:
On Oct 16 2009, Alfred Hönes wrote:
Another point:
The draft is speaking abut "DNAME _in_ the root".
According to my surficial knowledge, DNAME RRs 'live'
at the _apex_ of the zone that shall be redirected, not
at the delegation point -- or did I miss something?
Within each zone, there may be at most one DNAME RR,
and if so, it must be at the apex of the zone.
That's just wrong. DNAMEs can occur anywhere within a zone
(including at the apex, but not restricted to it), and there
can be as many as you like within a zone, subject only to the
constraint that no RR has a name subordinate to that of a DNAME.
I don't think so.
Here's a full section from draft-ietf-dnsext-rfc2672bis-dname-17
(expected to be shipped to the IESG soon) :
2.3. DNAME Apex not Redirected itself
The term "DNAME Apex" occurs nowhere else in the document, and is
perhaps rather unfortunate. I've always assumed it was meant to be
the same as "DNAME owner name" as in the text below, and certainly
not equivalent to "zone apex".
Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
owner name; the owner name of a DNAME is not redirected itself. The
domain name that owns a DNAME record is allowed to have other
resource record types at that domain name, except DNAMEs, CNAMEs or
other types that have restrictions on what they can co-exist with.
|> DNAME RRs are not allowed at the parent side of a delegation point
|> but are allowed at a zone apex.
"Allowed at a zone apex" != "Must be at the zone apex".
(And of course lifting a DNAME into the parent zone must *replace* the
delegation, not co-exist with it.)
There still is a need to have the customary SOA and NS resource
records at the zone apex. This means that DNAME does not mirror a
zone completely, as it does not mirror the zone apex.
These rules also allow DNAME records to be queried through RFC 1034
[RFC1034] compliant, DNAME-unaware caches.
Not allowing DNAMEs except at the zone apex would be grossly incompatible
with RFC 2672 itself (see the example in section 5.2) and with deployed
code. I cannot imagine it was the intent of the draft to make such a
change without a highly explicit statement to that effect. (Nor do I
see any reason to make such a change.)
I guess this had better be continued on namedroppers rather than dnsop.
--
Chris Thompson University of Cambridge Computing Service,
Email: [email protected] New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715 United Kingdom.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
