I-D ACTION:draft-ietf-dnsext-rfc2672bis-dname-05.txt
Interne...@ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.
Title : Update to DNAME Redirection in the DNS
Author(s) : S. Rose, W. Wijngaards
Filename : draft-ietf-dnsext-rfc2672bis-dname-05.txt
Pages : 16
Date : 2007-9-26
The DNAME record provides redirection for a sub-tree of the domain
name tree in the DNS system. That is, all names that end with a
particular suffix are redirected to another part of the DNS. This is
an update to the original specification in RFC 2672.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-05.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announ...@ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-ietf-dnsext-rfc2672bis-dname-05.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mail...@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-05.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail...@ietf.org"
Content-Type: text/plain
Content-ID: <2007-9-26...@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsext-rfc2672bis-dname-05.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2007-9-26...@ietf.org>
--OtherAccess--
--NextPart--
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Edward Lewis
At 16:15 -0400 9/26/07, Interne...@ietf.org wrote:
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-05.txt
1) Second paragraph of section 1...because I find the phrase "a DNAME
from example.com to example.net" to be colloquial and a bit confusing
I am proposing this as a strawman replacement:
# Take for example, looking through a zone (see RFC 1034, section 4.3.2,
# step 3) for the domain name "foo.example.com" and a DNAME resource record
# is found at "example.com" indicating that all queries under "example.com"
# be directed to "example.net". The lookup process will return to step 1
# with the new query name of foo.example.net. Had the query name been
# "www.foo.example.com" the new query name would be "www.foo.example.net".
2) Later on:
s/Other usage of DNAME lies in/Another usage of DNAME lies in/
or "Other usages" ...
3) In section 2.2
"suffix owner name" is descriptive but not defined. Perhaps say that
the portion of the QNAME ending with the root label that matches the
owner name of the DNAME RR is replaced with the contents of the DNAME
RR's RDATA.
4) Rewording/punctuation:
s/It is possible for DNAMEs to form loops. Just like CNAMEs can form/
It is possible for DNAMEs to form loops, just as CNAMEs can form
5) Section 2.4
Add "See section 5.2 for further restrictions related to dynamic update."
6) Section 3.1
Also add that the server ought to at least burp when trying to add a
DNAME to a wild card domain name. (Meta note - when I see "load a
zone" I always look to see what's said about dynamic update.)
7) Section 3.2
First sentence add "when one is encountered."
8) Later in 3.2
I don't get the comment on "modern resolvers." What's that based on?
What's a "modern resolver?"
9) Section 5.3
Getting into NSEC3 is sticky. First, you don't reference any NSEC 3
document. Second, if you do, it'll get this hung up in the RFC
Editor queue for a few days. (At least.) Third, if you talk about
NSEC3, you need a reference. Fourth, you don't need to talk about
it, leave that to the NSEC3 document if and when it comes out.
I don't want to bet against NSEC3, but this document will stand
better if it doesn't get into a discussion on NSEC3. Even if we know
about NSEC3 while writing this.
10) Section 5.3.3.2
I don't get the comment:
If the query had been cee.example.com as shown above, then this
answer would have been validated, because 'cee' does not get
redirected by the DNAME at 'bar'.
Wasn't this a valid Name Error example? So "this answer would be validated"?
11) As it is now, you are missing a reference to NSEC3.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Think glocally. Act confused.
Edward Lewis
At 12:01 +0200 10/1/07, Wouter Wijngaards wrote:
>> 6) Section 3.1
>>
>> Also add that the server ought to at least burp when trying to add a
>> DNAME to a wild card domain name. (Meta note - when I see "load a zone"
>> I always look to see what's said about dynamic update.)
>>
>It already says:
> A server MAY give a warning that the behavior is unspecified if such
> a wildcarded DNAME is loaded.
>How about this addition:
> The server MAY refuse it, refuse to load or refuse dynamic update.
What I am tripping on is the use of "loaded" without mention of
dynamic(ally) update(d). At times I have seen comments that dynamic
update is not the same as a zone load. (I think of both zone loading
and dynamic updates as forms of editing the on-line zone, I don't
think that position is universally held.)
>> 8) Later in 3.2
>> What's a "modern resolver?"
>
>Changed to 'paranoid resolvers'.
Are you accusing software of feeling paranoid? ;)
>> 11) As it is now, you are missing a reference to NSEC3.
>>
>We can remove NSEC3 talk from the document or add a reference.
If you can get away with not mentioning it at all, you'd be better
off when dealing with the document handling.
Edward Lewis
...
>>> It already says:
>>> A server MAY give a warning that the behavior is unspecified if such
>>> a wildcarded DNAME is loaded.
>How about:
> A server MAY give a warning that the behavior is unspecified if such
> a wildcarded DNAME is loaded or received in a dynamic update message.
That answers what I meant.
>>>> 8) Later in 3.2
>>
>>>> What's a "modern resolver?"
>>>
>>> Changed to 'paranoid resolvers'.
>> Are you accusing software of feeling paranoid? ;)
>>
>
>how about "cautious"? Or simply "some resolvers" since it is really the
>implementor that is paranoid.
;)
I guess to take this off-(DNAME)-topic, let's say this is the response:
QUESTION:
www.example.net. IN AAAA
ANSWER:
example.net. IN DNAME parked-page1.example.com.
www.example.net. IN CNAME www.parked-page1.example.com.
www.parked-page1.example.com. IN AAAA 2001:15FF:2345::DEAD:CAFE
It is possible for all of the answers to be coming from authoritative
sources as the same name server can be authoritative for all of the
involved zones. But what you are describing is that to the querier,
only the first (two) record(s) would be really in zone, so there are
queriers that will ignore the AAAA record?
Well, I never was a fan of CNAME following in RFC 1034/4.3.2/3. But
in the name of reducing round trips it was a good thing at the time.
>>>> 11) As it is now, you are missing a reference to NSEC3.
>After looking back at the NSEC3 doc, I realize I was wrong - it does
>mention NSEC3's existing "under" a DNAME. In light of this, I'm tempted to
>cut out the discussion as well. The doc's whole purpose is to clarify
>DNAME discussion in other RFC's :)
>
>I'm tempted to keep the NSEC3 text in for now and hope that we can get
>something out by the Dec. meeting. We have until Nov. 19.
I tried to get DNAME out of the Wildcard RFC but lost that. 2672 was
so badly written that I had to struggle to come up with clarifying
text without trying to rewrite 2672 passages. Still, somehow it
stayed in and the RFC was published.
I guess one of the dilemmas is that to the publishing process, NSEC3
does not exist but to the mental state of the WG it does. So, what's
the appropriate wa to treat the NSEC3-lb gorrilla?
Scott Rose
> A few come backs...
>
> At 12:01 +0200 10/1/07, Wouter Wijngaards wrote:
>
>>>
>> It already says:
>> A server MAY give a warning that the behavior is unspecified if such
>> a wildcarded DNAME is loaded.
>> How about this addition:
>> The server MAY refuse it, refuse to load or refuse dynamic update.
>
> What I am tripping on is the use of "loaded" without mention of
> dynamic(ally) update(d). At times I have seen comments that dynamic
> update is not the same as a zone load. (I think of both zone loading
> and dynamic updates as forms of editing the on-line zone, I don't think
> that position is universally held.)
>
How about:
A server MAY give a warning that the behavior is unspecified if such
a wildcarded DNAME is loaded or received in a dynamic update message.
>>> 8) Later in 3.2
>
>>> What's a "modern resolver?"
>>
>> Changed to 'paranoid resolvers'.
>
> Are you accusing software of feeling paranoid? ;)
>
how about "cautious"? Or simply "some resolvers" since it is really the
implementor that is paranoid.
>>> 11) As it is now, you are missing a reference to NSEC3.
>>>
>> We can remove NSEC3 talk from the document or add a reference.
>
> If you can get away with not mentioning it at all, you'd be better off
> when dealing with the document handling.
After looking back at the NSEC3 doc, I realize I was wrong - it does
mention NSEC3's existing "under" a DNAME. In light of this, I'm tempted
to cut out the discussion as well. The doc's whole purpose is to
clarify DNAME discussion in other RFC's :)
I'm tempted to keep the NSEC3 text in for now and hope that we can get
something out by the Dec. meeting. We have until Nov. 19.
Scott
Mark Andrews
> >> It already says:
> >> A server MAY give a warning that the behavior is unspecified if such
> >> a wildcarded DNAME is loaded.
> >> How about this addition:
> >> The server MAY refuse it, refuse to load or refuse dynamic update.
> >
> > What I am tripping on is the use of "loaded" without mention of
> > dynamic(ally) update(d). At times I have seen comments that dynamic
> > update is not the same as a zone load. (I think of both zone loading
> > and dynamic updates as forms of editing the on-line zone, I don't think
> > that position is universally held.)
> >
>
> How about:
> A server MAY give a warning that the behavior is unspecified if such
> a wildcarded DNAME is loaded or received in a dynamic update message.
Having any text that disallows outright rejection of the
zone is a show stopper as far as I am concerned. Additionally
it's likely to be ignored as vendors put protecting their
customers from idiotic mistakes ahead of rfc compliance.
Mark
P.S. warnings get ignored. The only effective way to get
things corrected is to refuse to load until the
"i-know-this-stupid-but-im-going-to-do-it-anyway" switch
is set.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Mark Andrews
What "old resolvers" are we protecting by forcing the TTL
to 0 rather than having the TTL match the DNAME's TTL?
Additionally this is inconsistant with the rest of the
draft.
A CNAME RR record, with TTL matching that of the DNAME, is
synthesized for old resolvers, specifically for the QNAME
in the query.
Mark
On the server side, the DNAME RR record is always included in the
answer section of a query. A CNAME RR record with TTL 0 is
synthesized for old resolvers, specifically for the QNAME in the
query. DNSSEC [RFC4033], [RFC4034], [RFC4035] says that the
synthesized CNAME does not have to be signed. The DNAME has an RRSIG
and a validating resolver can check the CNAME against the DNAME
record and validate the DNAME record.
Scott Rose
>>>> It already says:
>>>> A server MAY give a warning that the behavior is unspecified if such
>>>> a wildcarded DNAME is loaded.
>>>> How about this addition:
>>>> The server MAY refuse it, refuse to load or refuse dynamic update.
>>> What I am tripping on is the use of "loaded" without mention of
>>> dynamic(ally) update(d). At times I have seen comments that dynamic
>>> update is not the same as a zone load. (I think of both zone loading
>>> and dynamic updates as forms of editing the on-line zone, I don't think
>>> that position is universally held.)
>>>
>> How about:
>> A server MAY give a warning that the behavior is unspecified if such
>> a wildcarded DNAME is loaded or received in a dynamic update message.
>
> Having any text that disallows outright rejection of the
> zone is a show stopper as far as I am concerned. Additionally
> it's likely to be ignored as vendors put protecting their
> customers from idiotic mistakes ahead of rfc compliance.
>
> Mark
>
I wasn't trying to disallow a master from rejecting to load a zone. How
about we change the text to match some of the wording in the wildcard
clarify RFC?
A server MAY give a warning that the
behavior is unspecified if such a wildcarded DNAME is loaded or
received in a dynamic update message. An implementation may refuse
to load or transfer a zone that contains a wildcarded DNAME, but there
is no direct protocol specification.
I'd be very welcome to better text. :)
Scott
> P.S. warnings get ignored. The only effective way to get
> things corrected is to refuse to load until the
> "i-know-this-stupid-but-im-going-to-do-it-anyway" switch
> is set.
--
----------------------------------------
Scott Rose Computer Scientist
NIST
ph: +1 301-975-8439
scott...@nist.gov
http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------
Scott Rose
> What "old resolvers" are we protecting by forcing the TTL
> to 0 rather than having the TTL match the DNAME's TTL?
>
No reason, I admit. We thought we had to choose something consistant. I've
noticed servers doing either TTL=0 or TTL=CNAME TTL
> Additionally this is inconsistant with the rest of the
> draft.
>
> A CNAME RR record, with TTL matching that of the DNAME, is
> synthesized for old resolvers, specifically for the QNAME
> in the query.
>
We really just kept that because it was in the old draft and there wasn't
enough strong desire to change it.
Scott
> Mark
>
> On the server side, the DNAME RR record is always included in the
> answer section of a query. A CNAME RR record with TTL 0 is
> synthesized for old resolvers, specifically for the QNAME in the
> query. DNSSEC [RFC4033], [RFC4034], [RFC4035] says that the
> synthesized CNAME does not have to be signed. The DNAME has an RRSIG
> and a validating resolver can check the CNAME against the DNAME
> record and validate the DNAME record.
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
>
Mark Andrews
> > What "old resolvers" are we protecting by forcing the TTL
> > to 0 rather than having the TTL match the DNAME's TTL?
> >
>
> No reason, I admit. We thought we had to choose something consistant. I've
> noticed servers doing either TTL=0 or TTL=CNAME TTL
>
> > Additionally this is inconsistant with the rest of the
> > draft.
> >
> > A CNAME RR record, with TTL matching that of the DNAME, is
> > synthesized for old resolvers, specifically for the QNAME
> > in the query.
> >
>
> We really just kept that because it was in the old draft and there wasn't
> enough strong desire to change it.
For serious use of DNAME, i.e. in the root zone, you need
a longer ttl than zero. Zero is a good way to inflict a
DoS on yourself.
Mark
> Scott
Edward Lewis
>> > What "old resolvers" are we protecting by forcing the TTL
>> > to 0 rather than having the TTL match the DNAME's TTL?
>> >
>>
>> No reason, I admit. We thought we had to choose something consistant. I've
>> noticed servers doing either TTL=0 or TTL=CNAME TTL
I noticed this issue too when I read the draft but didn't give it much thought.
Use the latter (=CNAME's TTL). TTL's of 0 have proven to be
problems, and with DNSSEC, short TTLS (less than a 1-5 minutes) have
been demonstrated to be problem causers.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Think glocally. Act confused.
--
Andrew Sullivan
> A server MAY give a warning that the
> behavior is unspecified if such a wildcarded DNAME is loaded or
> received in a dynamic update message. An implementation may refuse
> to load or transfer a zone that contains a wildcarded DNAME, but there
> is no direct protocol specification.
>
> I'd be very welcome to better text. :)
You could strengthen it by changing the MAY to a SHOULD. (I am not
commenting on whether that's a good idea -- I can see arguments in
each direction.)
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada Toronto, Ontario Canada
<and...@ca.afilias.info> M2P 2A8
jabber: aj...@jabber.org +1 416 646 3304 x4110