Subject: [dnsext] dnssec-bis-updates - EDNS buffer size in responses

From: Ray Bellis <[email-masked]>
Date: Fri, 5 Aug 2011 13:55:24 +0000

I'm bouncing this here at Peter Koch's request, following discussion on the DNSSEC Deployment List that was prompted by the observation that the responses from Google's recursive service contain an EDNS buffer size indication of 512 bytes.

Currently, RFC 4035, §3 says:

" A security-aware name server MUST support the EDNS0 ([RFC2671])
  message size extension, MUST support a message size of at least 1220
  octets, and SHOULD support a message size of 4000 octets."

However the response buffer size indicates the receive buffer size of the _server_, i.e. how big a _query_ it can receive.

There's no need for the EDNS buffer size supplied in the _response_ to adhere to this recommended minimum.

So far as I can see DNSSEC makes no difference to the size of requests, except for the overhead of the OPT RR itself, and that's moot since without that RR there's no buffer size indication anyway.

Ray

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Edward Lewis <[email-masked]>
Date: Fri, 5 Aug 2011 10:25:22 -0400

1) OPT RR is not unique to DNSSEC.  (I'm just stating the obvious.)

2) *MUST support* a message size of X doesn't 
mean it has to say that (X) in the EDNS0 buffer 
size.

The word "support" is way too fuzzy to be 
included in a requirement.  I'm not sure that 
specifying a value less than 1220 is a violation 
if the server could do 1220 "if it wanted to".

3) Does the 512 value in the Google server 
response cause a demonstrable operational 
problem?  (I.e., or is the issue just that this 
situation seems to be a violation of the written 
specification?)

At 13:55 +0000 8/5/11, Ray Bellis wrote:
>I'm bouncing this here at Peter Koch's request, 
>following discussion on the DNSSEC Deployment 
>List that was prompted by the observation that 
>the responses from Google's recursive service 
>contain an EDNS buffer size indication of 512 
>bytes.
>
>However the response buffer size indicates the 
>receive buffer size of the _server_, i.e. how 
>big a _query_ it can receive.
>
>There's no need for the EDNS buffer size 
>supplied in the _response_ to adhere to this 
>recommended minimum.
>
>So far as I can see DNSSEC makes no difference 
>to the size of requests, except for the overhead 
>of the OPT RR itself, and that's moot since 
>without that RR there's no buffer size 
>indication anyway.
>
>Ray
>

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

I'm overly entertained.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 06 Aug 2011 00:42:20 +1000

In message <[email-masked]>, Ray Bellis wr
ites:
> I'm bouncing this here at Peter Koch's request, following discussion on the
> DNSSEC Deployment List that was prompted by the observation that the respo
> nses from Google's recursive service contain an EDNS buffer size indication
>  of 512 bytes.
> 
> Currently, RFC 4035, =A73 says:
> 
> However the response buffer size indicates the receive buffer size of the _
> server_, i.e. how big a _query_ it can receive.
> 
> So far as I can see DNSSEC makes no difference to the size of requests, exc
> ept for the overhead of the OPT RR itself, and that's moot since without th
> at RR there's no buffer size indication anyway.
> 
> Ray

Just because you see a value less than 1220, it doesn't mean that you are
not 100% compliant with this code.  In the thread this came from there
was evidence that the nameservers in question *do* support EDNS at the
required size.

"support" does not mean "will always emit".  These is no MUST NOT emit
EDNS queries/responses with a EDNS UDP size less that 1220.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Ray Bellis <[email-masked]>
Date: Fri, 5 Aug 2011 16:34:15 +0000

> included in a requirement. 

[see below]

>  I'm not sure that

I don't think I want to go there.

> situation seems to be a violation of the written

The latter.  It was suggested (not by me) that _responding_ with a value of 512 was "dodgy" because it violates the 1220 value from RFC 4035.

My argument is that this value is mostly irrelevant in responses, in so much as it relates to the server's _inbound_ buffer size for UDP requests.

PK suggested that the wording might be clarified in dnssec-bis-updates.

I'd suggest that "support" is actually fine in context - it's just that it's being interpreted too widely to apply both to responses and requests.  2671-bis is relatively clear on the difference.

Ray

---

From: Peter Koch <[email-masked]>
Date: Mon, 8 Aug 2011 13:37:31 +0200

> if the server could do 1220 "if it wanted to".

this comes close to the point that lead to the suggestion to
continue the discussion in this venue.  "support"
isn't clear enough about the direction and there's
little benefit yet if an authoritative server or
a recursive server on the client facing side would be
able to handle larger packets than 512 payload.
The DNSSEC specification demands that a DO be sent back
in the response, thus an EDNS OPT RR has to be present and
therefore a payload size value must be chosen anyway.

There's little point in understatement here, either.

So, the potential clarification would emphasize that
"support" means 'generating or handling responses'
in section 3 of RFC 4035.

> situation seems to be a violation of the written 

Probably not in this case, but DNS Dynamic Update messages
might change the picture.

-Peter