Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-08.txt

From: [email-masked]
Date: Tue, 07 Feb 2012 05:01:16 -0800

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           : Extension Mechanisms for DNS (EDNS0)
	Author(s)       : Joao Damas
                          Michael Graff
                          Paul Vixie
	Filename        : draft-ietf-dnsext-rfc2671bis-edns0-08.txt
	Pages           : 15
	Date            : 2012-02-07

   The Domain Name System's wire protocol includes a number of fixed
   fields whose range has been or soon will be exhausted and does not
   allow requestors to advertise their capabilities to responders.  This
   document describes backward compatible mechanisms for allowing the
   protocol to grow.

   This document updates the EDNS0 specification (RFC 2671) based on
   feedback from deployment experience in several implementations.  It
   also closes the IANA registry for extended labels created as part of
   RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain Name
   System") which depends on the existence of extended labels.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-08.txt

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 09 Feb 2012 17:38:08 -0500

This draft closes all issues identified so far.
The draft also addresses all Id-nits in prior version
There is one change that was not included in the WGLC version but may 
have been inferred: The document Obsoletes RFC2673 Binary labels.

If anyone objects to this version being forwarded to the IESG please 
speak up now and we will start a short WGLC on that one issue.

	thanks
	Olafur

On 07/02/2012 08:01, [email-masked] wrote:
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>
>
>

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 13 Feb 2012 14:05:18 +0100

Hi Olafur,

I have reviewed the document, and endorse it.

Could the authors put text in 6.1.1:
The OPT record is normally placed near the end of the additional section.

Because then there is guidance for the 'normal case'.

Why is: udpsize < 512 MUST be treated as 512 size?

s/udpates/updates/

Best regards,
   Wouter

On 02/09/2012 11:38 PM, Olafur Gudmundsson wrote:
> This draft closes all issues identified so far. The draft also
> addresses all Id-nits in prior version There is one change that was
> not included in the WGLC version but may have been inferred: The
> document Obsoletes RFC2673 Binary labels.
> 
> If anyone objects to this version being forwarded to the IESG
> please speak up now and we will start a short WGLC on that one
> issue.
> 
> thanks Olafur
> 
>> Title           : Extension Mechanisms for DNS (EDNS0) Author(s)
>> : Joao Damas Michael Graff Paul Vixie Filename        :
>> draft-ietf-dnsext-rfc2671bis-edns0-08.txt

---

From: Florian Weimer <[email-masked]>
Date: Mon, 13 Feb 2012 16:06:02 +0100

> This draft closes all issues identified so far.

I'm still worried that this specification does not provide much
guidance how to determine whether an authoritative server supports
EDNS.

This requirement

   Responders which choose not to implement the protocol extensions
   defined in this document MUST respond with a return code (RCODE) of
   FORMERR to messages containing an OPT RR in the additional section
   and MUST NOT include an OPT record in the response.

(section 8) updates RFC 1035.  This should be reflected in the
document header.  I think this paragraph is too strict, the actual
requirement is "MUST respond with FORMERR or process the query as if
no OPT RR was present".  The "MUST NOT include an OPT record in the
response" part is still a (minor) update to RFC 1035.  Originally, it
was possible to generate FORMERR responses by flipping the QR bit and
sending back the question packet.

Section 9 should mention that mistakenly disabling EDNS might lead to
a denial of service.  Such a failure could be caused by a query which
results in a FORMERR response, while other queries to the same server
would not.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Feb 2012 13:27:51 -0500

>Why is: udpsize < 512 MUST be treated as 512 size?

My assumption:

1) For ease of implementation
2) Because if the bufsize is too small, the header might not fit. ;)

There's a need to set a lower bound for bufsize large enough to allow 
for even a FORMERR response.  That's, what 12 bytes give or take, way 
less than 512, but the protocol is used to 512 as hard size limit.

Do you want/need to see 512 lowered?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: Joao Damas <[email-masked]>
Date: Mon, 13 Feb 2012 15:16:00 -0800

That's exactly it.
It could be less but that would mean you would be *almost* better off without EDNS (you still would get the additional flag field). You would be adding overhead to the DNS packet while limiting the packet size to a smaller amount than plain DNS creating an increased potential for fallback to TCP

Joao

On 13 Feb 2012, at 10:27, Edward Lewis wrote:

> There's a need to set a lower bound for bufsize large enough to allow for even a FORMERR response.  That's, what 12 bytes give or take, way less than 512, but the protocol is used to 512 as hard size limit.
>

---

From: Joao Damas <[email-masked]>
Date: Mon, 13 Feb 2012 19:33:21 -0800

i don't think we could introduce that feature and still call this EDNS(0)

Joao

---

From: Florian Weimer <[email-masked]>
Date: Tue, 14 Feb 2012 09:35:23 +0100

> i don't think we could introduce that feature and still call this EDNS(0)

Which feature?

With the draft, when queried with an OPT RR, you either have to answer
with an OPT RR, or produce a FORMERR.  This answer wouldn't be allowed
anymore:

; <<>> DiG 9.7.3 <<>> @ns3.schlund.de. quantenblog.net. +dnssec +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41252
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;quantenblog.net.               IN      A

;; ANSWER SECTION:
quantenblog.net.        86400   IN      A       212.227.229.215

;; Query time: 34 msec
;; SERVER: 217.160.80.131#53(217.160.80.131)
;; WHEN: Tue Feb 14 09:33:21 2012
;; MSG SIZE  rcvd: 49

This definitely looks like an error in the draft to me.

---

From: Dave Lawrence <[email-masked]>
Date: Fri, 24 Feb 2012 10:10:42 -0500

> Because then there is guidance for the 'normal case'.

Given the interest in trying to have an EDNS-capable server include
the OPT whenever possible, I'd recommend that the guidance be for the
record to be first.

I'd actually thought that was what earlier drafts said, but going back
to them I see they didn't do it explicitly and I only inferred it
because the simplest algorithm for building the reply would be "add
the OPT if it fits, then add any other records until you run out of
room."  There are, of course, other ways of doing it, but providing
guidance that it be first emphasizes the idea that the OPT is the one
Additional RR that we really want to be present if at all possible.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 24 Feb 2012 16:49:29 +0100

Hi Dave,

On 02/24/2012 04:10 PM, Dave Lawrence wrote:
>> Could the authors put text in 6.1.1: The OPT record is normally
>> placed near the end of the additional section.
>> 
> Given the interest in trying to have an EDNS-capable server
> include the OPT whenever possible, I'd recommend that the guidance
> be for the record to be first.
> 
> I'd actually thought that was what earlier drafts said, but going
> back to them I see they didn't do it explicitly and I only inferred
> it because the simplest algorithm for building the reply would be
> "add the OPT if it fits, then add any other records until you run
> out of room."  There are, of course, other ways of doing it, but
> providing guidance that it be first emphasizes the idea that the
> OPT is the one Additional RR that we really want to be present if
> at all possible.

Yes, you want EDNS OPT to be present if at all possible.
No, not at the start of the additional section, it is near the end of
the additional section.  The idea is that you reserve some space at
the end of the packet for the EDNS OPT record.  Then, you try to fit
as much additional-section data and so forth as you want into the
remaining space that is available.

I do not think 'first' is backwards compatible.

Best regards,
   Wouter

---

From: Dave Lawrence <[email-masked]>
Date: Fri, 24 Feb 2012 11:03:09 -0500

W.C.A. Wijngaards writes:
> I do not think [putting the OPT] 'first' is backwards compatible.

What is broken by it?

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 24 Feb 2012 17:10:38 +0100

Hi Dave,

>> I do not think [putting the OPT] 'first' is backwards

Today's custom in creating the packets puts the EDNS OPT at the end.

I do not know of any code that fails, I thought mine would, but a
quick scan into the code reveals it works fine.

Best regards,
   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Sat, 25 Feb 2012 10:12:59 +1100

You always need to reserve the space.  The OPT record is a extension
of the DNS header.  OPT takes precedence over answers.  Once you have
reserved the space putting it at the end is easy.

If I was doing EDNS again I would have used opcode "EDNS" and added
the extra fields immediately after the existing header before the
question.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]