Subject: Re: I-D ACTION:draft-ietf-dnsext-rfc2672bis-dname-05.txt

From: Wouter Wijngaards <[email-masked]>
Date: Mon, 01 Oct 2007 12:01:03 +0200

Hi Ed,

Thanks for the review.

Edward Lewis wrote:
> 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".

I'm OK with this. I put "" around new query name "foo.example.net".

2, 3, 4, 5, 7)
OK.

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

> 8) Later in 3.2
> 
> I don't get the comment on "modern resolvers."  What's that based on?
> What's a "modern resolver?"

Changed to 'paranoid resolvers'.

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

The topic of extra hashing cost for NSEC3 zone DNAMEs was raised. Other
than that, we could remove the section.

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

Yes 5.3.3.2 is validated.
It has the same NSECs as 5.3.3.1, which is not validated.

I'll change the wording to:
   This reply has the same NSEC records as the example above, but with
   the query cee.example.com, the answer is validated, because 'cee'
   does not get redirected by the DNAME at 'bar'.

> 11) As it is now, you are missing a reference to NSEC3.
> 
We can remove NSEC3 talk from the document or add a reference.

Best regards,
   Wouter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Mon, 1 Oct 2007 08:47:02 -0400

A few come backs...

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

>Changed to 'paranoid resolvers'.

Are you accusing software of feeling paranoid? ;)

>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                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 1 Oct 2007 10:13:06 -0400

At 9:34 -0400 10/1/07, Scott Rose wrote:
...

>How about:
>  a wildcarded DNAME is loaded or received in a dynamic update message.

That answers what I meant.

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

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

---

From: Scott Rose <[email-masked]>
Date: Mon, 01 Oct 2007 09:34:51 -0400

> and dynamic updates as forms of editing the on-line zone, I don't think 
> that position is universally held.)
> 

How about:

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

Scott

---

From: Mark Andrews <[email-masked]>
Date: Tue, 02 Oct 2007 15:03:27 +1000

>   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: [email-masked]

---

From: Scott Rose <[email-masked]>
Date: Tue, 02 Oct 2007 13:59:50 -0400

> 	customers from idiotic mistakes ahead of rfc compliance.

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

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Oct 2007 16:21:00 -0400

> 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
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110