Subject: [dnsext] additional section processing for DNAME

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 07 Jan 2011 15:14:49 -0800

Hello,

I have one quick question about draft-ietf-dnsext-rfc2672bis-dname-21.
In its Section 3, the draft states:

   The DNAME RR causes type NS additional section processing.  This
   refers to action at step 6 of the server algorithm outlined in
   section 3.2.

And the "step 6" of section 3.2 is as follows:

   6.  Using local data only, attempt to add other RRs which may be
       useful to the additional section of the query.  Exit.

It's not clear to me what these mean...what's "type NS additional
section processing" (for DNAME RR) in the first place?  Does this
mean, for example, if an authoritative server of "example.com" has the
following DNAME RR:

dname.example.com. DNAME dname.example.org.

and it also happens to have authoritative AAAA or A RRset of
dname.example.org, then the server includes these AAAA/A RRsets in the
additional section?  This doesn't seem to make much sense to me, so I
guess "type NS additional section processing" should mean something
else, but I don't know what it is.

Could you clarify what it is, and what it is for?

Thanks,

(p.s. I spent some time of googling to find the answer myself, and I
noticed this change was introduced in rev 15 of this document around
when there was a WG last call.  So I suspect this is a response to a
last call comment, but I couldn't find the relevant discussion.
Hence this question, at the risk of asking something twice at the same
place)

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Sat, 08 Jan 2011 10:57:00 +0100

Hi Jinmei,

> mean, for example, if an authoritative server of "example.com" has the

It is the same that is done for a query for type A.  The step 6 is from
1034, http://tools.ietf.org/rfcmarkup?doc=1034#page-25 .  This is not
special to the DNAME type.

Best regards,
   Wouter

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 08 Jan 2011 13:11:06 -0800

At Sat, 08 Jan 2011 10:57:00 +0100,

> special to the DNAME type.

Thanks for the response, but it doesn't really clear my confused
head.  Could you show an example (like the one I used in my original
question) of how "type NS additional section processing" could happen
with DNAME (even if it's no different from type A query)?

Meanwhile, I've got an off-list response to my original question,
which says "providing NS/A glue like you would for a delegation."
If this means the following scenario, I can see it as a consequence of
the server algorithm described in Section 3.2 of rfc2672bis...:

- there's an authoritative server for example.com and example.org
- in example.com it has a DNAME:
  dname.example.com. DNAME dname.example.org.
- in example.org it has a delegation by NS (and glue):
  dname.example.org. NS ns.dname.example.org.
  ns.dname.example.org. A 192.0.2.1

With this setup if we ask this server for www.dname.example.com, the
server will include:
- the DNAME (and synthesized CNAME) in the answer section
- the NS in the authority section
- the (glue) A in the additional section

(this is, in fact, how BIND 9 and NSD behave in this situation, btw)

...however, if this is what "type NS additional section processing" of
Section 3 means, I suspect it's very difficult for ordinary readers to
reach the correct understanding (and I think we need more detailed and
concrete explanation).  Also, if this is what the draft means,
referring to "step 6 of the server algorithm" doesn't seem to be
correct, as this is actually a result of step 3-B.

[besides, as far as I know the vast majority (if not all) of today's
deployed recursive/caching servers will ignore such NS/A to prevent
cache poisoning anyway, so it's mostly a waste in practice.  But
that's a different discussion]

It's still quite likely that I misunderstand something very
fundamental.  If so, pointing it out with a concrete example of "type
NS additional section processing" with DNAME would be very much
appreciated.

Thanks,

---
JINMEI, Tatuya

---

From: Edward Lewis <[email-masked]>
Date: Mon, 10 Jan 2011 14:20:10 -0500

At 15:14 -0800 1/7/11, JINMEI Tatuya / 

>Hence this question, at the risk of asking something twice at the same

I'm still puzzled by the question, especially the reference to a 
change "in rev 15".  RFC 2672 has "The DNAME RR causes type NS 
additional section processing."  Only the location of that comment 
has changed in the 22 versions of 2672bis.

Is the original question "what's the significance/usefulness of the 
glue records in a DNAME-involved response?"  Does the question apply 
against the original RFC too, or to something that has been changed 
in the draft?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Jan 10, 2011 - In regions with mm/dd/yy, it's "Binary Day" - 01/10/11
Happy Binary Day

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 10 Jan 2011 23:16:32 -0800

At Mon, 10 Jan 2011 14:20:10 -0500,

> against the original RFC too, or to something that has been changed 

Ah, sorry for the confusing question.  It applies to the original
RFC2672, too.  Actually I first had the question when I (re)read
Section 3 of RFC2672:

   The DNAME RR causes type NS additional section processing.

So I next checked the latest revision of the bis draft
(rfc2672bis-dname-21) and found:

Since it was changed from the original RFC, I thought it was a result
of an attempt of clarifying the original text, but it was still
unclear to me (as I said in my original question message).  So I next
searched draft archives to identify when exactly the change was
introduced.  It was revision 15:
https://tools.ietf.org/rfcdiff?url1=draft-ietf-dnsext-rfc2672bis-dname-14&difftype=--html&submit=Go!&url2=draft-ietf-dnsext-rfc2672bis-dname-15

But I still failed to understand the sense of the change, and what
"type NS additional section processing" means wasn't still clear to
me.

---
JINMEI, Tatuya

---

From: Edward Lewis <[email-masked]>
Date: Tue, 11 Jan 2011 21:55:38 -0500

At 23:16 -0800 1/10/11, JINMEI Tatuya / 

>"type NS additional section processing" means wasn't still clear to

Ahh, yes.  Ok, I understand the question.  And I agree it's not 
entirely clear. ;)  (As in, "yes, I certainly understand the 
problem...")

One of the issues in writing these updates (or alleged 
clarifications) I can mention from my experience in doing them is 
that the original text is so weak and thus interpreted so 
differently, someone will be unhappy.  The safest thing to do is 
retain as much of the original text and slap on some supports where 
we can "get away with it."  Perhaps this is a case of that.

Jan 11, 2011 - Either it's 1/11/11 or 11/1/11,  "Junior Saint Broadcast day"
(Nov 11 is senior...)

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 12 Jan 2011 00:11:57 -0800

At Tue, 11 Jan 2011 21:55:38 -0500,

> entirely clear. ;)  (As in, "yes, I certainly understand the 

Okay, I'm glad to know it was not only me:-)

> we can "get away with it."  Perhaps this is a case of that.

Perhaps.  Right now I just wonder about the meaning rather than
agreeing or disagreeing with anything.  Since the original text in
question was (seemingly) intentionally updated, I'd at least like to
know the intent of the update.

Thanks,

---
JINMEI, Tatuya

---

From: Andreas Gustafsson <[email-masked]>
Date: Wed, 12 Jan 2011 10:31:39 +0200

> Okay, I'm glad to know it was not only me:-)

You may add me to the list of people who find the text confusing.
Actually, I would go further than that and say that the text is not
just confusing - it's simply wrong.

> know the intent of the update.

To me the update seems like an attempt to rationalize some text in the
original RFC that never made sense in the first place.

So, to summarize, I think the following text in the draft makes
no sense, serves no useful purpose, and should be deleted:

-- 
Andreas Gustafsson, [email-masked]

---

From: "Rose, Scott W." <[email-masked]>
Date: Wed, 12 Jan 2011 10:06:20 -0500

Based on the discussion, is there any reason to keep the text below?  

If the consensus is "no", should it just be dropped completely, or should it be replaced with something stating (rough text):

"The DNAME RR does not cause any additional section processing.  This is a change from RFC 2762."

Because this is another change from the original DNAME spec. 

Scott.  

On Jan 12, 2011, at 3:31 AM, Andreas Gustafsson wrote:
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 12 Jan 2011 11:20:05 -0800

At Wed, 12 Jan 2011 10:06:20 -0500,

> Because this is another change from the original DNAME spec. 

I don't have a strong opinion, but if there'll be a "changes from
RFC2762" section in the final bis RFC, I'd simply remove the text from
the body and note the fact in that section.

BTW, not a strong opinion again, but I agree with dropping the
statement about additional section processing in some way because the
text didn't make sense to me and I cannot think of any existing
deployment that relies on it (although, as with any compatibility
related topic, I understand such a view could often be too
optimistic).

---
JINMEI, Tatuya