Subject: [dnsext] New rules for DO bit

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 14 Jun 2009 14:33:58 -0400

To follow up on the discussion from the last two weeks here is a
draft to explicitly outlaw setting of DO bit of with buff size < 1220.

http://tools.ietf.org/html/draft-gudmundsson-dnsext-setting-ends0-do-bit-00

The draft also has another protocol change related to responders

Intended Status: Standard Track                           O. Gudmundsson
Network Working Group                                     Shinkuro, Inc.
Internet-Draft                                             June 13, 2009
Updates: 4035 (if approved)
Intended status: Standards Track
Expires: December 15, 2009

       DNSSEC OK buffer minimum size requirment and error handling
             draft-gudmundsson-dnsext-setting-ends0-do-bit-00

  Abstract
    RFC3226 mandated support for EDNS0 in DNS entities claiming to
    support either DNS Security Extensions or IPv6 address records.  This
    requirement was motivated because these new features increase the
    size of DNS messages.  If EDNS0 is not supported fall back to TCP
    will happen, having a detrimental impact on query latency and DNS
    server load.

--
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: "Jeffrey A. Williams" <[email-masked]>
Date: Sun, 14 Jun 2009 12:20:24 -0700

Olafur and all,

  I didn't know the IETF was a legislative body of any sort.  ???

  Where is the consensus that 1220 is bad?

>     will happen, having a detrimental impact on query latency and DNS

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: Florian Weimer <[email-masked]>
Date: Sun, 14 Jun 2009 22:43:44 +0200

> draft to explicitly outlaw setting of DO bit of with buff size < 1220.

I think the assumption in section 3 is wrong.  At least two resolver
implementations haven't got a DO/non-DO cache separation and can't
provide DNSSEC data to a client if it was not originally put into the
cache.  From what I've heard, this is difficult to change.

The proposed change is risky for popular zones because BIND will
requery immediately (at a rate of 1/RTT) when the response lacks
DNSSEC records expected as the result of local configuration or a
secure delegation.

By the way, I'm pretty sure that the reason for the DO flag wasn't
packet size, as you suggest, but the desire not to confuse resolvers
with additional data at odd places in the response packet.

Section 2.2 seems to imply that the root does not support EDNS0, but
it actually does:

; <<>> DiG 9.6.0-P1 <<>> @a.root-servers.net . NS +bufsize=4096 +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33462
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 21

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       518400  IN      NS      E.ROOT-SERVERS.NET.
[...]
M.ROOT-SERVERS.NET.     3600000 IN      AAAA    2001:dc3::35

;; Query time: 171 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Sun Jun 14 22:36:01 2009
;; MSG SIZE  rcvd: 643

So even the priming reply is larger than 512 bytes nowadays.

If the traffic increase for a signed root is a concern, it could be
served from separate IP addresses (requiring new hints), so that the
ramp-up would be a bit more gradual.

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 14 Jun 2009 17:56:48 -0700

On Jun 14, 2009, at 4:20 PM, George Barwood wrote:

> From the draft:
>
> "What seems to be  happening is that resolver implementations have  
> discovered that ENDS0
>   with buffer size of 4096 is sometimes silently dropped and fall  
> back  to < 1220 in an attempt to get messages through."
>
> Is the reason known for the silent dropping?
>
> At a guess, it would be due to packets exceeding the internet MTU  
> size of 1500 bytes.

Well, the Ethernet MTU, with is something of a De-facto Internet MTU.

What happens is some device won't fragment when they should, some  
devices won't reassemble properly when they should (*cough* firewalls/ 
nats *cough*), etc.

So although a host may advertise EDNS0 support, it can't actually  
properly receive a large request.

(This is one of the things we test for in netalyzr, BTW).  Its  
unfortunatly very common.

>
> I wonder if some protocol extension could be defined so that large  
> responses can be sent over UDP
> in several packets, to avoid problems with fragmentation. I'm no  
> expert in IP fragmentation, but is it
> the case that normally fragmentation does not occur, so faulty  
> implementations are likely to have arisen
> unnoticed, and therefore relying on it for transporting DNSKEY  
> rrsets may be unrealistic.
>
> That said, the limited aim of the draft seems sensible, as a  
> practical measure.
>
> ----- Original Message -----
> From: "Olafur Gudmundsson" <[email-masked]>
> To: <[email-masked]>
> Sent: Sunday, June 14, 2009 7:33 PM
> Subject: [dnsext] New rules for DO bit
>
>
>> ÿûhº{.nÇ+≈·¬zwZ˙ë,j– 
>> ¢vœyÚèœ˜«“úﬁªç¬·ú)“øıµÿè®"¶a{
> +wû§”æìr¸˝{ø§jÈ§≠W¥…w˚”Ø^˙ë,j–{[¡Üÿj·! 
> …÷ÿﬂm§ÿÿ¢˝ÿ≈ë_ﬂ…àﬂX¬¶Ïçjgˇ®…iz»?
>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 14 Jun 2009 21:18:55 -0400

>cache.  From what I've heard, this is difficult to change.

This is exactly the reason why the draft specifies that the DO bit
be cleared in response when the server does not fit the DNSSEC answer
into the <1220 buffer advertised.

>DNSSEC records expected as the result of local configuration or a

Bind is the biggest offender of setting DO =1 && buff_size < 1220.

>with additional data at odd places in the response packet.

It was both.

>Section 2.2 seems to imply that the root does not support EDNS0, but

Looks like I need to fix the wording in the next version :-)

This is the query that has me most worried
<stora:~ 21:17 8 0>dig doesnotexistatall.gov. ptr +dnssec
     ...
;; MSG SIZE  rcvd: 1513

it is > 1500 bytes long because they use NSEC3 and Zone Signing keys that is
2048 bits long. (Org's negative answer is only 1007 bytes.

         Olafur

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 14 Jun 2009 18:44:45 -0700

On Jun 14, 2009, at 6:18 PM, Michael Graff wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nicholas Weaver wrote:
>
> Do you have any data showing that a 1220-byte packet might make it,
> where a 4096 one will not?

Not yet, but I can add it in.  Currently the Netalyzr test is as  
~1800B response...

I can easily add in a 1200B response to see if that does make it  
through OK.

nweaver% dig +dnssec edns_large.netalyzr.icsi.berkeley.edu  
@roland.icir.org

; <<>> DiG 9.4.3-P1 <<>> +dnssec edns_large.netalyzr.icsi.berkeley.edu  
@roland.icir.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 21
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;edns_large.netalyzr.icsi.berkeley.edu. IN A

;; ANSWER SECTION:
edns_large.netalyzr.icsi.berkeley.edu. 1 IN A   192.150.187.31

;; AUTHORITY SECTION:
netalyzr.icsi.berkeley.edu. 10  IN      NS      roland.icir.org.
netalyzr.icsi.berkeley.edu. 100 IN      NS       
return_false.netalyzr.icsi.berkeley.edu.

;; ADDITIONAL SECTION:
roland.icir.org.        10      IN      A       192.150.187.31
filler0.netalyzr.icsi.berkeley.edu. 100 IN CNAME  
return_false 
.this 
.is 
.random 
.filler.ballast.to.make.the.response.big0.netalyzr.icsi.berkeley.edu.
filler1.netalyzr.icsi.berkeley.edu. 100 IN CNAME  
return_false 
.this 
.is 
.random 
.filler.ballast.to.make.the.response.big1.netalyzr.icsi.berkeley.edu.
....
;; Query time: 29 msec
;; SERVER: 192.150.187.31#53(192.150.187.31)
;; WHEN: Sun Jun 14 18:42:54 2009
;; MSG SIZE  rcvd: 1824

>
> - --Michael
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAko1oXYACgkQ+NNi0s9NRJ3iXACfYsfnUzMlIGAnA/ZpC+wL7kp2
> a0kAn3Wz5L5pmtaHzeWZQyU5aqHFuDfL
> =/l5T
> -----END PGP SIGNATURE-----

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 15 Jun 2009 11:52:58 +0200

Hi Olafur,

>> > draft to explicitly outlaw setting of DO bit of with buff size < 1220.

The draft is overcomplicated as it stands now.  I propose this:

   All DNSSEC compliant severs MAY treat ENDS0 queries with DO bit set
   and the buffer size set to less 1220, as error in the query and
   return FORMERR.

This is so close to the current spec, the draft is not really necessary
and it can go into dnssec-bis-updates as a clarification.  (If this
draft becomes standard it'll get implemented for unbound of course).

It is also much simpler.  The if-statement 'truncation would be caused'
complicates way too much, for no real benefit.  Also a FORMERR causes
the server to be cached as EDNS0-noncompliant in those resolvers.  And
the resolver can try again later without EDNS0, or have some internal
logic to handle non-EDNS0 servers.

(for example, if only one server in the NS set has the problem, it gets
blacklisted as not DNSSEC aware, and failover to other servers happens,
I think both BIND and unbound have such logic.  For example the path to
one .org server caps at 512, but other paths do not, then this can cause
bind to get smart and avoid the 'edns0-noncompliant' .org server).

Also I have a question about the security considerations, which states
that some implementation is vulnerable to a downgrade, and will go to
insecure if signatures are removed.  So, this is a broken
implementation, I do not think it merits a security consideration.  Or
state more strongly that this thing is badly broken.  This security
consideration must not give the impression that such broken behaviour is
to be condoned, or should be catered for in the protocol specs.

What I would have expected to see in the security considerations is that
for both the method in the draft and the FORMERR return, the zone can go
completely bogus for resolvers that tried to do EDNS@512 and DNSSEC
validation. (say .org anchor loaded into BIND using EDNS0@512).  The
idea is that such software has to be updated to work.

(or possibly such a resolver may have a secondary path to another
nameserver that does not have the 512-limit imposed, and falls back to
that, then DNSSEC validation works (and better than before) ).

Best regards,
   Wouter

---

From: Florian Weimer <[email-masked]>
Date: Mon, 15 Jun 2009 12:34:13 +0200

> into the <1220 buffer advertised.

The DO bit is not signed (even if you don't strip signatures), so such
a reply has to more or less disregarded if you expect a secure answer.

> Bind is the biggest offender of setting DO =1 && buff_size < 1220.

Sure.  I'll try to change our distribution if necessary, but I fear
that this dispute will turn into something close to a shouting match
between BIND resolvers and authoritative servers which implement the
old (and new) behavior.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 15 Jun 2009 11:17:03 +0000

> Date: Mon, 15 Jun 2009 11:52:58 +0200
> From: "W.C.A. Wijngaards" <[email-masked]>
> ...

i think ignoring the DO bit is better.  it's not a format error and we
would not want the initiator to treat this as an EDNS downgrade.  there
are other benefits to EDNS beyond just helping to carry DNSSEC metadata.

> logic to handle non-EDNS0 servers.

it's taken ten years to get EDNS this far.  i think we should not burden
its very slow deployment curve with a DO-related setback.

DO does not mean "DNSSEC is desired" so much as "DNSSEC is understood".
it would not stretch the meaning of "understood" at all for a target to
say, i see your DO bit but i also see your small buffer size, so i am
rejecting your claim that you understand DNSSEC, and thus ignoring DO.

---

From: Michael Graff <[email-masked]>
Date: Sun, 14 Jun 2009 20:18:47 -0500

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

- --Michael

---

From: [email-masked]
Date: Mon, 15 Jun 2009 16:33:00 +0100

> where a 4096 one will not?

I have plenty, albeit in the context of SOHO CPE.

Lots of DNS proxies in routers will handle ~1464 bytes of payload (i.e. 
one PPPoE frame) but no larger.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Joe Abley <[email-masked]>
Date: Mon, 15 Jun 2009 16:07:55 -0400

> rejecting your claim that you understand DNSSEC, and thus ignoring DO.

I think it would be great if this observation could find a home in  
Olafur's draft, somewhere. I find the text above concise and easy to  
understand, and I think it would make the choice of "ignore DO" vs.  
FORMERR (or something else) much easier to understand.

Joe

---

From: Peter Koch <[email-masked]>
Date: Mon, 15 Jun 2009 23:11:57 +0200

> The draft is overcomplicated as it stands now.  I propose this:

that was my reaction, too.  I believe the draft doesn't state anything
dramatically new, just reinforces a statement made in RFC 3226 and later
in RFC 4035, Section 3.

>    and the buffer size set to less 1220, as error in the query and

As a protocol purist, I'd support this, but as an operator I'd rather avoid
such a draconian reaction.  Ignoring the DO bit should be less problematic.
Also, it is in the spirit of "be conservative in what you send" (and
note that "liberal in what you accept" therefore doesn't include obeying
DO at <1220 octets).

> draft becomes standard it'll get implemented for unbound of course).

Seconded, either way the dnssec-bis-updates document is the right place
to make this statement.  It's hard to unilaterally standardize the
reaction to a non-compliant query, anyway.

> complicates way too much, for no real benefit.  Also a FORMERR causes

Agreed. It would also lead to unnecessary protocal lawyering since
the client, albeit in violation of the spec, could argue that the
server would be obliged to engage in that extra calculation if it was
to ignore DO=1 only after it found that the response would have TC=1.
Thenew text should encourage the authoritative server to defend itself
against non compliant clients, rather than to restrict this ability.

-Peter

---

From: [email-masked]
Date: Mon, 15 Jun 2009 23:44:56 +0000

> draft becomes standard it'll get implemented for unbound of course).

	as long as we are plus-oneing  -  i like this 
	wording and the results.

--bill (DNSSEC - expect collateral damage)

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Jun 2009 10:25:17 +1000

In message <[email-masked]
> one PPPoE frame) but no larger.

	Which would be a issue between the stub server and the
	ultimate recursive server.  It normally doesn't affect
	traffic to and from iterative servers behind the SOHO CPE
	because they don't go through the proxy code.

	For end user zones 512 is often quite reasonable.  It really
	is only the root that has a problem because it returns lots
	of NXDOMAIN responses which are large with DNSSEC.  Iterative
	resolvers talk to the root.  Stub resolvers don't normally.

	The response below has lots more that could be thrown away
	if needed.

; <<>> DiG 9.3.6-P1 <<>> +dnssec +bufsize=512 www.isc.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27551
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
;www.isc.org.			IN	A

;; ANSWER SECTION:
www.isc.org.		589	IN	A	149.20.64.42
www.isc.org.		589	IN	RRSIG	A 5 3 600 20090715025015 20090615025015 27624 isc.org. l7d+erEfXgcixSMvMNj6+/TmP7VqojAcgojPpb4pNtnBMgr7++I559rK k/fwBSMXHjkE8kUfgW8vCOLxdaFRsysd/6znbItLiBFVtBqiy0vpMtA7 JIg62JZP2oDHLP5+qRK5gVqMdOcd+9KmMC9UQh9Gk4lck5Tnuwtktpsm e2M=

;; AUTHORITY SECTION:
isc.org.		4275	IN	NS	sfba.sns-pb.isc.org.
isc.org.		4275	IN	NS	ams.sns-pb.isc.org.
isc.org.		4275	IN	NS	ns-ext.nrt1.isc.org.
isc.org.		4275	IN	NS	ord.sns-pb.isc.org.
isc.org.		4275	IN	RRSIG	NS 5 2 43200 20090715025015 20090615025015 27624 isc.org. RIvdvpRZXH6qVSII4KAOCPsWzQobJAehL+HqXDb75IEc5NyQ62d1yoTv IwQ0XS6apM9DSQimu2W7aoQV2rWco/q/Sb9RJ265sHBxmG5XAwDiXyDy c6R1R1jYp7EEgiju6nSBIem6cHqleG4qYAbgDD6V5vx2DLwlxXoY+f1P +ac=

;; ADDITIONAL SECTION:
ams.sns-pb.isc.org.	4275	IN	A	199.6.1.30
ord.sns-pb.isc.org.	4275	IN	A	199.6.0.30

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 16 10:13:00 2009
;; MSG SIZE  rcvd: 510

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

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 15 Jun 2009 17:59:58 -0700

> 	because they don't go through the proxy code.

Similar issues however crop up between the recursive server and the  
rest of the net, due to firewall issues, where the firewall code for  
handling DNS does not do proper reassembly.

dig edns_large.netalyzr.icsi.berkeley.edu

on a nameserver which supports EDNS (or even if it doesn't).  It  
returns enough random CNAME junk that it will require fragmentation on  
an ethernet network.   Its suprising how many recursive resolvers will  
fail to resolve that name.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Jun 2009 12:31:58 +1000

I worry about this because you get validators sitting behind
	all sorts of crappy boxes which are *not* under the control
	of the validator owner and we are telling the validator
	owner that's tough @#$$!@# you can't validate despite there
	being a path which can allow the answers through.

	Also is there any demonstratable damage being caused by
	having the TCP queries?  As far as I can see only sites
	behind the mis-configured firewalls will be impacted if
	TCP connections fail which is self correcting.  

	Mark

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Jun 2009 21:08:29 -0700

> 	being a path which can allow the answers through.

s/validator owner/upset customer/

This is a *good* thing.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 16 Jun 2009 09:26:35 +0200

Hi Peter,

> note that "liberal in what you accept" therefore doesn't include obeying

That sounds like one reason to do the draft approach.

> reaction to a non-compliant query, anyway.

Yes I'd also prefer the draft statement put in dnssec-bis-updates.

> against non compliant clients, rather than to restrict this ability.

Also if the draft statement is used, I would like the 'truncation would
be caused' clause to be removed.

Best regards,
   Wouter

---

From: Joe Abley <[email-masked]>
Date: Tue, 16 Jun 2009 08:11:50 -0400

> reaction to a non-compliant query, anyway.

It sounds like you are wondering about how a recommendation such as  
the one Olafur proposed could be deployed.

Are we mainly looking for a general solution to a potential general  
threat (i.e. give implementers and hence authority-only server  
operators an option if TCP query rates start to cause pain)?

Or is this a more tactical measure designed principally for use by  
operators of infrastructure zones (the root, TLDs, etc)?

If the latter, it seems reasonable to imagine that the number of code- 
bases and the number of operators needed to get blanket deployment are  
both rather low.

If the former, then it doesn't seem important to worry about  
deployment; either the TCP query load will be a problem, in which case  
this measure might help, or it won't be a problem, in which case who  
cares about deployment.

Either way it seems like if it's to be of any use consensus needs to  
be achieved and code written in conjunction with the DNSSEC deployment  
timeline, and based on the NTIA's desires with respect to the time to  
a signed root we need this to happen fairly quickly. Perhaps a  
different document is a good way of achieving targeted consensus and  
hence speed to implementation.

Joe

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 16 Jun 2009 10:40:33 -0400

<chair-hat=on>
Andrew is the sole chair of the working group when it comes to this document.

<chair-hat=off>

I put the document out to stimulate discussion, the document describes
what is needed to allow "Ignore DO bit" and when. (+/- guidance on when to
ignore, when needed or always).
The current draft does not explicitly say that resolvers need to cache based
on the DO bit setting in answer not query.

I agree that publishing this in dnssec-bis-updates would be the right place,
BUT something is IMHO needed NOW and dnssec-bis-updates is moving slowly.

If we need an RFC too beat up vendors then this document is the way to go,
if we just need a consensus, next rev can reflect that and then get 
incorporated
into dnssec-bis-updates.

Personally I do not care if we specify "Ignore DO" or FORMERR but I 
prefer the one
that will put more pressure on bad boxes.

         Olafur

At 08:11 16/06/2009, Joe Abley wrote:

>If the latter, it seems reasonable to imagine that the number of 
>code- bases and the number of operators needed to get blanket deployment are
>both rather low.
>

---

From: Peter Koch <[email-masked]>
Date: Tue, 16 Jun 2009 19:14:49 +0200

> the one Olafur proposed could be deployed.

there are two aspects to this:

1) When a document is proposed (no pun) for Standards Track, I think one
   should be able to elevate it there per the rules (even if that never
   happens), which means the interoperability requirements must be clear.
   In this case, the server is reacting to a question in violation of
   the spec and I have difficulties to see how "two independent
   implementations" could successfully interoperate.

2) By specifying the correct behaviour and limiting the possible reactions
   one creates a grey area where both sides might be raight and wrong.

> operators an option if TCP query rates start to cause pain)?

Ideally, before that happens.

-Peter

---

From: Florian Weimer <[email-masked]>
Date: Tue, 16 Jun 2009 19:47:41 +0200

* Olafur Gudmundsson:

> prefer the one that will put more pressure on bad boxes.

Do not answer such broken queries.  This will make the issue obvious
right now.  It mainly punishes the violator, and not both ends (to the
degree that is possible if you deliberately prevent a transaction
which is mutually beneficial).

Ignoring DO or sending FORMERR will not make a difference to the
violator if DNSSEC is not involved.  Either no fallback is needed at
all, or it will happen after one round-trip (which is still not such a
huge delay that it is likely to catch operator attention).  If DNSSEC
is involved and the violator lacks a BAD cache, a self-DoS due to a
query storm might be the result, punishing both ends.

By the way, it's still not clear to me if this thread is about
improving the DNS protocol in an objective sense, or punishing ISC for
more or less deliberately misinterpreting an RFC.  That is, I don't
see the protocol-level harm caused by the BIND behavior.  (In the
abstract, I can imagine that a dominant vendor is able to cause quite
arbitrary damage by ignoring established standards, both to the
protocol itself and the standardization process.)

---

From: Paul Vixie <[email-masked]>
Date: Tue, 16 Jun 2009 19:33:36 +0000

> From: Florian Weimer <[email-masked]>
> Date: Tue, 16 Jun 2009 19:47:41 +0200
> 
> * Olafur Gudmundsson:
> Do not answer such broken queries.  ...

the query isn't broken.

> By the way, it's still not clear to me if this thread is about improving
> the DNS protocol in an objective sense, or punishing ISC for more or less
> deliberately misinterpreting an RFC.

the authors of the rfc in question have told me that DO means dnssec would
not cause the initiator to dump core, not that dnssec records are desired.
by that interpretation, bind9's current behaviour is not unreasonable, and
it really does fall to the target to decide that the initiator might not be
going to dump core, but that with the buffer size being less than 1220, it
is not reasonable to assume that dnssec metadata will all fit, and so the
fact that it would not make the initiator dump core becomes irrelevant.

---

From: [email-masked]
Date: Wed, 17 Jun 2009 10:31:42 +0000

> operators of infrastructure zones (the root, TLDs, etc)?

	I'm ok with the idea that a rise in TCP transactions
	will occur ... what I am not comfortable with is the idea
	that it might be the case that the percentage of TCP
	traffic shifts dramatically... and that this shift can
	be directly correlated to the existance of non-compliant
	edge software.

	i am sorely tempted to pull out my majik DPI filtering 
	box and drop all DNS requests w/ DO=1 and buffsize lt. 1220

	this option seems like the only sane response by authority 
	servers who wish to deploy standards compliant software and
	zones.   Is there a valid reason to not encourage this 
	behaviour by all authoritative servers? 

	granted, we don't have very many datapoints yet, but the ones
	we do have are captivating.  perhaps Matt is right - there is
	nothing to worry about here - move along.  

--bill

---

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Jun 2009 23:00:05 +1000

> 	be directly correlated to the existance of non-compliant

	Well if you have figures Bill, publish them.  All I've heard
	so far is conjecture.  I've asked for figures from those
	that should be able supply them but there has been a deafening
	silence.

	All I've heard is "There may be a problem".  No one as far
	as I can tell has looked at the existing traffic to workout
	what percentage of EDNS capable clients actually fall back
	to or have been configured to send EDNS queries at 512 vs
	those that ask with a bigger size.

	Is it 0.01%, 0.1%, 1%, 10%, 50% or 90%?

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 17 Jun 2009 06:36:27 -0700

> 	Is it 0.01%, 0.1%, 1%, 10%, 50% or 90%?

Here's the problem:

There are two possible reasons why an EDNS buffer of >1500B might be a  
problem.

The first is a middlebox which can't handle UDP fragmentation  
(including one parsing DNS).

The second is a middlebox which pareses DNS and can't handle EDNS or  
DNS packets >512B.

Correct me if I'm wrong, but Bind's fallback assumes the latter,  
correct?  If 4096b fails, it drops to 512B.  What market share is Bind  
of those resolvers supporting DNSSEC and EDNS?

Are there any resolvers which assume that it could be case one, and  
first drop the buffer size to ~1400B and only if that fails, to 512B?

Absent the resolver actively probing to determine cause, a resolver  
which doesn't assume case 2 is going to be problematic, so I would  
actually hope that if there is a single-step downgrade of EDNS buffer  
size, it drops to 512B.

I apologize for not thinking of the difference myself, the next  
version of netalyzr will have two separate tests, one for 1400B and  
one for 1800B, to distinguish the two cases.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 17 Jun 2009 16:35:39 +0000

> From: Nicholas Weaver <[email-masked]>
> Date: Wed, 17 Jun 2009 06:36:27 -0700
> ...
> The first is a middlebox which can't handle UDP fragmentation  (including
> one parsing DNS).
> 
> The second is a middlebox which pareses DNS and can't handle EDNS or  DNS
> packets >512B.

for completeness, many middleboxes object to QR=0 && ARCOUNT!=0 regardless
of packet size.

---

From: David Conrad <[email-masked]>
Date: Wed, 17 Jun 2009 14:40:55 -0700

> the query isn't broken.

In the strictest sense of RFC 4035, I guess I'd reluctantly have to  
agree.  Section 4.1 states:

"4.1. EDNS Support
A security-aware resolver MUST include an EDNS ([RFC2671]) OPT pseudo- 
RR with the DO ([RFC3225]) bit set when sending queries.
A security-aware resolver MUST support a message size of at least 1220  
octets, SHOULD support a message size of 4000 octets, and MUST use the  
"sender's UDP payload size" field in the EDNS OPT pseudo-RR to  
advertise the message size that it is willing to accept. ..."

One can read this as saying that while the security-aware resolver  
MUST support 1220 bytes, it doesn't have to advertise that fact.   
Since it MUST advertise a message size, it can, in fact, advertise  
anything it wants, including 512 bytes.

Of course, the whole point of the 1220 byte minimum was to try to  
reduce the number of queries that result in responses with TC set, so  
advertising a buffer size that will increase the number of responses  
with TC set seems counter-intuitive to me.

> not cause the initiator to dump core, not that dnssec records are  

To clarify, when I wrote 3225, I was aware of two name server  
implementations (one of which was relatively common) that had issues  
with the DNSSEC-related RRs so it was a factor. However, if you read  
3225, you'll note the rationale section leads with concerns about  
fallback to TCP, not core dumping.  That was intentional.  As numerous  
people pointed out, if your resolver core dumps based on input it gets  
from the network, it deserves to die.

In any event, preliminary results obtained while studying the impact  
of scaling up the root zone size (due to DNSSEC, IPv6, and new TLDs)  
on the "L" root server indicates the combination of DO=1 and a buffer  
size of 512 results in a small percentage increase in the number of  
TCP session initiations.  While the increase is well within the  
capacity of "L" to withstand, I will admit some nervousness.

Regards,
-drc

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 17 Jun 2009 15:35:16 -0700

Bill and all,

  Non compliant edge software meaning what exactly?  Definition?

Regards,

---

From: [email-masked]
Date: Wed, 17 Jun 2009 22:41:33 +0000

> anything it wants, including 512 bytes.

	and, turning the stick around... a server that sees a DO=1
	and an advertized message size of less than the MUST of 1220
	octets is perfectly capable of interpreting the situation
	(MUST/MUST) and seeing (MUST-ok/MUST-fail) as a failure
	or hostile event... and refuse service.  

	one might argue that if buffsize is throttled to lt 1220
	octets, that a security aware resolver should reluctently
	crawl back to a non-secure state and not set DO=1 - since
	the infrastructure can't support the increased demand.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 18 Jun 2009 09:21:54 +1000

In message <[email-masked]>, Nicholas W
> first drop the buffer size to ~1400B and only if that fails, to 512B?

	There is no real benefit in doing that.  There are very few
	answers that actually result in fragmentation.  Turn on a
	packet dump an watch.  If the EDNS@4096 fails then EDNS@1200
	will almost certainly also fail or result in TC being set
	especially if you don't add the NS RRset to the DNSKEY
	response.  Recent versions of BIND set minimal-response for
	DNSKEY responses (DNSSKEY and RRSIG only only record).

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 17 Jun 2009 17:58:33 -0700

George and all,

  Nicely summed up.  Yep, these are about it...

George Barwood wrote:

> So trying to summarize, seems to me there are 2 sensible strategies for resolvers:
>
> (1) Try EDNS@1400 , fall back to TCP on truncation.
>
> Advantage: stops IP fragment spoofing.
>
> (2) Try EDNS@4000, fall back to TCP on truncation.
>
> Advantage: fall back to TCP very unlikely. May still drop some glue ( se needs 4444 ).
>
> (1) Should just about work without TCP fallback, provided servers do not send NS rrset on
> DNSKEY queries, and manage keys carefully. Fingers crossed.
>
> George
>
> [snip]¶‹§²æìr¸›zÇ§u©ž²Æ zÚ'jg®Šiz»+z«ž²Ú)²'~ŠàÂ+a¶°¢·nžË›±Êâmè§jÈ§‚W¥Šwš²Ø^™ë,j{[¡ÜšÈb½èm¶Ÿÿ¢›"z×è®åŠËlþv¦yÚè¦—«s/==

Regards,

---

From: Florian Weimer <[email-masked]>
Date: Thu, 18 Jun 2009 09:22:26 +0200

> Advantage: stops IP fragment spoofing.

No, it doesn't.  There's no minimum MTU for IPv4.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: [email-masked]
Date: Thu, 18 Jun 2009 08:25:32 +0100

> anything it wants, including 512 bytes.

It seems very clear to me:

1.  MUST include EDNS0, with DO=1
2.  MUST support >= 1220 (SHOULD support 4000)
3.  MUST say so

I'm struggling to parse the §4.1 text in any way that would support an 
alternate conclusion.

The only way to misinterpret this is if the phrases "MUST support a 
message size of ..." and "the message size that it is willing to accept" 
are taken to mean different things.  That's quite a twisting of the 
language, and clearly not what the authors intended.

Ray

---

From: [email-masked]
Date: Thu, 18 Jun 2009 08:33:34 +0100

>    DNSKEY responses (DNSSKEY and RRSIG only only record).

I can't agree.

There's very clearly a number of large zones already sending signed 
packets in the 512 - ~1400 range.

It's simply not true to say that failure with EDNS@4096 makes failure with 
EDNS@1200 (or 1400) certain.  I've seen plenty of middleboxes that'll fail 
with the former, but work quite happily with the latter.

However I concede that my experience with this is with SOHO CPE (and 
therefore most likely affecting stub -> recursor).

Ray

---

From: Mark Andrews <[email-masked]>
Date: Thu, 18 Jun 2009 22:06:12 +1000

In message <[email-masked]

> packets in the 512 - ~1400 range.

	Yes and they all get through without fragmentation with a
	EDNS UDP size of 4096.

> with the former, but work quite happily with the latter.

	They work because they got a answer back not because of the
	size of the answer.

	For DNSKEY SE it make not a bit of difference if I set the
	bufsize to 512 or 1400.  I still need to fallback to TCP
	to get the answer if I can't get fragmented packets through.

; <<>> DiG 9.6.1 <<>> dnskey se +dnssec +bufsize=1400 +ignore
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30556
;; flags: qr tc rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
;se.				IN	DNSKEY

;; ANSWER SECTION:
se.			2354	IN	DNSKEY	256 3 5 AwEAAc9B2MqxtXW/bQUYBV5zHf1z8e8MRSVWleDlQ3XZaOMlki4g4qdX hJ2rHN69ZzmvMj2DjTvLd8lMTN54NiHntofBIg0ZJ9pi0pcDemeeVQ7B h7T1OYzaM2rnId7xfSaoXBdX+6tMhkB/3CXM/cgqgar33emkhzdPUDdS 8FYNBGuL
se.			2354	IN	DNSKEY	257 3 5 AwEAAdKc1sGsbv5jjeJ141IxNSTdR+nbtFn+JKQpvFZETaY5iMutoyWH a+jCp0TBBAzB2trGHzdi7E55FFzbeG0r+G6SJbJ4DXYSpiiELPiu0i+j Pp3C3kNwiqpPpQHWaYDS9MTQMu/QZHR/sFPbUnsK30fuQbKKkKgnADms 0aXalYUuCgDyVMjdxRLz5yzLoaSO9m5ii5cI0dQNCjexvj9M4ec6woi6 +N8v1pOmQAQ9at5Fd8A6tAxZI8tdlEUnXYgNwb8eVZEWsgXtBhoyAru7 Tzw+F6ToYq6hmKhfsT+fIhFXsYso7L4nYUqTnM4VOZgNhcTv+qVQkHfO OeJKUkNB8Qc=
se.			2354	IN	DNSKEY	257 3 5 AwEAAeeGE5unuosN3c8tBcj1/q4TQEwzfNY0GK6kxMVZ1wcTkypSExLC BPMS0wWkrA1n7t5hcM86VD94L8oEd9jnHdjxreguOZYEBWkckajU0tBW wEPMoEwepknpB14la1wy3xR95PMt9zWceiqaYOLEujFAqe6F3tQ14lP6 FdFL9wyCflV06K1ww+gQxYRDo6h+Wejguvpeg33KRzFtlwvbF3AapH2G XCi4Ok2+PO2ckzfKoikIe9ZOXfrCbG9ml2iQrRNSM4q3zGhuly4NrF/t 9s9jakbWzd4PM1Q551XIEphRGyqcbA2JTU3/mcUVKfgrH7nxaPz5DoUB 7TKYyQgsTlc=
se.			2354	IN	DNSKEY	256 3 5 AwEAAa03g6eUym7QeFGEt0wx88nUcQmqnRRoUos95ICScmAgXimeiIhA pAOTWUrrybMyCOVgeFH8oovLoR8UR3YmScloECOU/EZQ4gLXGtL74HlO X8hw0HhlkOXNfSlxWZBTOOQn2Rf9yS3xWZ+ciLTqgj9SFxKr4n0AT6sy rWYFt4jJ
se.			2354	IN	DNSKEY	256 3 5 AwEAAcZN0OVaokJAtEiVGan/g3J3gOeYx7BCLTX1RuaWPHmPKROR7nfU a2Hc7Glpdtofk/uk5Aeiq9BKAAavke7Abr35cPXxOIdxdX65K4se1Iqe YpX+oW66xsn87WV89t1yPS67/nqFP5tcHnRnqA3lXGDlcfkjEsMQwY/M flQSVIkl

;; Query time: 9 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jun 18 21:41:04 2009
;; MSG SIZE  rcvd: 1027

	Yes there will be examples where truncating the additional section
	will allow the answer to just squeeze in.  I'm just saying there
	isn't much benefit in doing it.

	Mark

---

From: [email-masked]
Date: Thu, 18 Jun 2009 15:03:11 +0100

>    They work because they got a answer back not because of the

That's not the point

If an initial >1472 byte response is completely lost because of 
fragmentation, then as I understand it the recursor will drop down to 
EDNS0/512 for subsequent queries (forever?) even if those queries might 
have succeeded at something between 512 and 1472 bytes.

Currently those subsequent EDNS0/512 queries will result in TC=1, and 
retry over TCP.  If the recursor had retried at EDNS0/1440 that wouldn't 
happen.

Ray

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 18 Jun 2009 11:10:35 -0400

[no hat]

On Wed, Jun 17, 2009 at 02:40:55PM -0700, David Conrad wrote:

> One can read this as saying that while the security-aware resolver MUST 
> support 1220 bytes, it doesn't have to advertise that fact.  Since it 
> MUST advertise a message size, it can, in fact, advertise anything it 
> wants, including 512 bytes.

If that is true, then what it really means is that the advertisement
of the message size is unrelated to the actual message size the
resolver actually can support.  This strikes me as at the very least a
strained reading of the RFCs.  Perhaps the IETF needs a truth in
advertising BCP, but I'd hate to think we had that many protocol
lawyers around.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Jun 2009 11:46:48 -0400

>advertising BCP, but I'd hate to think we had that many protocol

Given my experience with implementers who don't pay attention to the 
IETF's daily soap opera, I support David's statement above.  When you 
read the RFCs "cold" and try to write code you find the RFCs are 
pretty poorly done and neglectfully maintained.

(As one case in point, the RFC 1996 for NOTIFY, section 3.7 describes 
a feature that was silently deprecated 10 years ago - no one bothered 
to update the Proposed Standard document.)

I've adopted an personal informal rule - if the RFC is more than 5 
years old and BIND doesn't do it in the current version, consider the 
feature deprecated.  So in this case, I'd expect to see DO=1 and 
bufsize under 1220.  As far as RFC 3226, I recall a few years ago 
arguing that it didn't apply to IPv6 because it referenced A6 and not 
AAAA.

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

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 18 Jun 2009 12:11:33 -0400

On Thu, Jun 18, 2009 at 11:46:48AM -0400, Edward Lewis wrote:

> read the RFCs "cold" and try to write code you find the RFCs are pretty 
> poorly done and neglectfully maintained.

[no hat]
While I think you can find lots of examples to illustrat that
position, this one strikes me as a particularly poor one.  Only
someone who had already made up his or her mind to do what they wanted
would imagine that "advertising your message size" means anything
other than "advertise the message size you can accept".  What possible
purpose would an advertisement for some other size serve?  

Now, you might argue that in this case it serves your best guess of
what the _deployed_ settings of your system actually can handle (since
those deployed settings include the network gear in front of the
resolver).  But in that case, what you're saying is that you do not,
as deployed, support a message size larger than 512.  In which case,
you're telling the truth in some sense, and it happens that as
deployed, you're not in a position to do what DNSSEC needs over UDP.
Of course, if it's true that almost all existing networks fall into
this category, then it means that DNSSEC is just not deployable over
UDP, and we're out of luck.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 18 Jun 2009 12:21:15 -0400

[Co-chair hat on]

On Thu, Jun 18, 2009 at 11:46:48AM -0400, Edward Lewis wrote:

> (As one case in point, the RFC 1996 for NOTIFY, section 3.7 describes a 
> feature that was silently deprecated 10 years ago - no one bothered to 
> update the Proposed Standard document.)
>
> I've adopted an personal informal rule - if the RFC is more than 5 years 
> old and BIND doesn't do it in the current version, consider the feature 
> deprecated.  So in this case, I'd expect to see DO=1 and bufsize under 
> 1220.  As far as RFC 3226, I recall a few years ago arguing that it 
> didn't apply to IPv6 because it referenced A6 and not AAAA.

Speaking only for myself, but in my role as chair, I am both depressed
and alarmed by the above two paragraphs.

If we have "silently deprecated" a feature, it'd be awful nice to see
someone write up the maintenance draft.  I don't note that such a
draft is floating around, but maybe I'm missing it.

But I'm more concerned about the second paragraph.  If the answer,
even for DNS experts with long experience, to "How should this work?"
is "What does BIND do?", then it seems to me we're wasting everyone's
time and energy here.  We can just let ISC do what it wants, and
everyone else can follow that.

This is particularly troubling in the current case, since the present
dispute is in fact partly about behaviour in BIND. 

If a significant portion of the DNS community has a silent rule that
one implementation is actually _the_ reference implementation, we're
doing a huge disservice to the Internet community generally by
pretending otherwise.  I sort of find this hard to believe, and I
rather hope it's false, but actually knowing would be better than
hope.

I am therefore curious to know whether others have the same informal
rule as Ed.  Feel free to send me mail off-list if you don't feel
comfortable saying so on-list.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: [email-masked]
Date: Thu, 18 Jun 2009 17:02:00 +0000

> UDP, and we're out of luck.

	you've just lept to a conclusion.

	DNSSEC is deployable over UDP.  DNSSEC is not feasable
	if some helpful box/app between the validator and authority
	server decides to arbitrarily throttle the infrastructure capaibility.
	
	i'm kind of interested in the second stage event, when the pushback
	to TCP occurs and then the very helpful box/app inthe middle decides that
	NO, port 53 over TCP is not supported either.

	the problem is the cruft in between the validator and authoritive server.
	not UDP.

	the 512 limiter is in some respects like a bandwidth limiter.  what kinds
	of hoops would we have had to jump through if there was general kowtowing
	to the fact that it was too expensive to upgrade core links from 64Kbit.
	or that 64K Ram was a hard limit.  we have put buffer size negotiation 
	in endsystems and are finding that others have placed rate/service limiters
	inbetween these endsystems.  

	the proper pressure here is to affect changes in those rate/service limiters
	to allow the DNSSEC capability to be expressed/used.

-- bill

---

From: [email-masked]
Date: Thu, 18 Jun 2009 17:06:47 +0000

BIND has been touted as -the- DNS reference implementation.

 which might have been true at one time, but is patently no longer
 the case; e.g.  no A6 support anymore, non-spec DLV, non compliance 
 with RFC 3226... the list is long and growing.

--bill

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Jun 2009 13:53:36 -0400

ISC has staunchly denied being a reference implementation.  ISC has 
never claimed BIND to be a role model.  (Heck, it combines authority 
and recursion in one code base.)  Innuendo that they are "no longer" 
a reference implementation is an unfair slight.

BTW, A6 has been deprecated (perhaps not documented ;) ) - it and 
bitstring labels were very, very bad ideas upon further review.  Cool 
ideas maybe, but not sustainable in core infrastructural elements.

---

From: Michael Graff <[email-masked]>
Date: Thu, 18 Jun 2009 13:17:13 -0500

> ideas maybe, but not sustainable in core infrastructural elements.

And just to add humor into the mix:  DLV is an informational RFC, and
uses vendor-reserved numbering space.  The title of RFC 3226 is "DNSSEC
and IPv6 A6 aware server/resolver message size requirements" and since
BIND 9 is no longer A6 aware, well we can ignore it, right?  I mean, in
order to be strict in how ISC reads RFCs and IETF maintains them?

It sounds like perhaps the RFCs need some cleanup, nothing more.  A
reality check, if you will.

- --Michael

---

From: bert hubert <[email-masked]>
Date: Thu, 18 Jun 2009 20:46:38 +0200

On Thu, Jun 18, 2009 at 6:21 PM, Andrew Sullivan<[email-masked]> wrote:
>> 1220.
[...]

> comfortable saying so on-list.

I'd go even further than Ed. If any DNS feature is not in constant
use, or if neither Windows or BIND relies on it, it does not work and
it will not work.

In fact, sending packets that deviate even slightly from the norm has
been known to crash many CPE/SOHO routers (case in point, not doing
label compression on the first answer).

Quite a lot of what happens on the 'soap opera known as DNSEXT' has
very little relation to reality.

In general, try to be as close to BIND (perhaps even version 8) as
possible, and your stuff will work.

    Bert

---

From: David Conrad <[email-masked]>
Date: Thu, 18 Jun 2009 12:00:10 -0700

Ray,

On Jun 18, 2009, at 12:25 AM, [email-masked] wrote:
> > agree.

That would be my reading as well (assuming DNSSEC-related RRs are  
desired).

> I'm struggling to parse the §4.1 text in any way that would support  
> an alternate conclusion.

As I mentioned, I can see the argument that there is ambiguity.

Note that I'm not saying I agree with the argument, rather I agree the  
argument can be made if you take the words of 4035 and ignore their  
intent.

> message size of ..." and "the message size that it is willing to  
> accept" are taken to mean different things.  That's quite a twisting  
> of the language, and clearly not what the authors intended.

As I discovered with 3225, what the author intended and how it is  
interpreted are not necessarily directly related... :-/

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Thu, 18 Jun 2009 12:19:52 -0700

Andrew,

On Jun 18, 2009, at 9:11 AM, Andrew Sullivan wrote:
> Only

Well, BIND advertises a number other than what it can accept.  Mark  
can explain why it does so.

Regards,
-drc

---

From: [email-masked]
Date: Thu, 18 Jun 2009 19:35:33 +0000

> a reference implementation is an unfair slight.

	my memories here diverge from yours.

> ideas maybe, but not sustainable in core infrastructural elements.

	bitstrings were formally depricated.  A6 is still experimental.
	ISC decided unilaterally to remove the code - although they retain
	code for other experimental or depricated labels/codepoints.

> >> years

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Jun 2009 15:49:59 -0400

>	code for other experimental or depricated labels/codepoints.

Experimental or not, A6 is and was a bad idea.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Jun 2009 09:12:40 +1000

In message <[email-masked]>, David Conrad
> can explain why it does so.

	BIND advertises EDNS@4096.  It then advertises EDNS@512 if
	it doesn't get a answer from several queries for this lookup
	to multiple servers.  It then advertises plain DNS.

	The size of the first lookup can be adjusted in named.conf
	but the defaul value is 4096.
 
	It is clear looking at the data that the vast majority of
	queries made with EDNS@4096 the responses get through.  It
	is only the exceptions that don't.

	There are two levels of exception:
	1.  Fragmented responses get dropped (firewalls, SOHO
	proxies).  To continue with this one could retry at 1024
	(to allow for the smaller link sizes) but that will almost
	always result in a response with TC set.

	2. There is a firewall which won't let through UDP/DNS >
	512.  Retrying at 512 is needed for this case.  Again this
	will almost always result in TC being set.

	Falling back to 512 allows both of these to work.  Falling
	back to 512 doesn't significantly change the number of TCP
	connections that will be made by the level 1 exceptions.

	Changing named to fallback to 1024 won't significantly
	change the number of TCP connection made.  For type 1
	exceptions.

	Working from behind a type 2 exception is very hard as all
	the lookups into secure zones are slooowwww.  People complain
	about how slow they are and fix the problem.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Jun 2009 10:04:12 +1000

In message <[email-masked]
> have succeeded at something between 512 and 1472 bytes.

	Just for that particular query.

	If the answer fragemented then the chance that it will work
	without TC at 1024 (which is the only realistic alternate
	fallback step) is miniscule.

> retry over TCP.  If the recursor had retried at EDNS0/1440 that wouldn't 

	No.  It almost certainly would have happened. 

	Run named with edns-udp-size set to 1024 behind a firewall
	which drops fragments then run it with edns-udp-size at the
	default.  The number of TCP connections being made will be
	less with the defaults.

	If you tune named to use the maximimal edns-udp-size without
	local fragmentation (1460 for IPv4) then you will have less
	TCP connections that the default.

	But percentage wise the number of TCP connections in all
	three senarios is still low and of similar magnitudes.

	Mark

---

From: [email-masked]
Date: Fri, 19 Jun 2009 03:23:37 +0000

> 	but the defaul value is 4096.

	wonderful!  can we then tweek the code to then advertise
	EDNS1400, then  plain DNS, no EDNS and buffsize 512?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Jun 2009 14:10:13 +1000

> 	EDNS1400, then  plain DNS, no EDNS and buffsize 512?
 
	Other than to deliberately break DNSSEC working through a
	512 firewall is there any benefit?  I don't see any evidence
	that changing the number will significantly affect the low
	amount of TCP traffic.

---

From: [email-masked]
Date: Fri, 19 Jun 2009 07:35:47 +0100

> Just for that particular query.

Mark,

Can you please clarify this - the EDNS failback algorithm is retried for 
every query, and the results not cached on a per-dest-IP basis?

Ray

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Jun 2009 16:55:05 +1000

In message <[email-masked]
> every query, and the results not cached on a per-dest-IP basis?

	It's retried for every query.  We want to give the EDNS@4096
	query a chance to succeed before we fallback.

	Mark

---

From: [email-masked]
Date: Fri, 19 Jun 2009 10:37:34 +0000

> Experimental or not, A6 is and was a bad idea.

	lots o bad ideas out there... take ARP for example.
	and some really good ones... like A6!

--bill

---

From: [email-masked]
Date: Fri, 19 Jun 2009 10:50:00 +0000

> 	that changing the number will significantly affect the low

	I can take that as a yes then?

--bill

---

From: Paul Vixie <[email-masked]>
Date: Fri, 19 Jun 2009 14:08:49 +0000

> To: IETF DNSEXT WG <[email-masked]>
> From: Mark Andrews <[email-masked]>
> 

please send new fallback text for RFC2671bis.

---

From: [email-masked]
Date: Fri, 19 Jun 2009 16:47:36 +0100

>    query a chance to succeed before we fallback.

RFC 2671 (§5.3) certainly envisioned that resolvers might cache the EDNS0 
capabilities of other servers.

In such a case then probing @1280 or @1460 should certainly be of some 
benefit, per the scenario I suggested in my previous e-mail.

I'm slightly surprised that BIND apparently does not do any such caching. 
I can see why in BIND's case you currently argue that EDNS0 fallback to 
something higher than 512 is unnecessary, notwithstanding that in the DO=1 
case falling back to 512 bytes is clearly contrary to RFC 3226.

Ray

---

From: "George Barwood" <[email-masked]>
Date: Fri, 19 Jun 2009 17:22:17 +0100

Isn't the other situation in which dropping, or starting, at 1400 may be of benefit is where 
the server tailors's response to fit?

Glue (which may be signed) can always be dropped, and also the NS rrset might be 
omitted ( when not requested ).

Just because the @4000 response got fragmented and lost, because it was over 1500, 
doesn't mean an @1400 response will also be over 1500 and fragmented and lost.

If problems are noted/expected, I think a good strategy may be to start at 1400, 
and "fall back" to 4000 on truncation. 

----- Original Message ----- 
From: [email-masked] 
To: Mark Andrews 
Cc: IETF DNSEXT WG ; [email-masked] 
Sent: Friday, June 19, 2009 4:47 PM
Subject: Re: [dnsext] TCP pushback

>    query a chance to succeed before we fallback.

RFC 2671 (§5.3) certainly envisioned that resolvers might cache the EDNS0 capabilities of other servers. 

In such a case then probing @1280 or @1460 should certainly be of some benefit, per the scenario I suggested in my previous e-mail. 

I'm slightly surprised that BIND apparently does not do any such caching.  I can see why in BIND's case you currently argue that EDNS0 fallback to something higher than 512 is unnecessary, notwithstanding that in the DO=1 case falling back to 512 bytes is clearly contrary to RFC 3226. 

Ray

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 19 Jun 2009 09:52:44 -0700

> and "fall back" to 4000 on truncation.

I'd argue that that is backwards.  MOST resolvers do not have b0rken  
middleboxes in the path.  A non-trivial number do.

You shouldn't b0rk the clean-path resolvers for the benefit of the  
broken-path resolver.  Rather, the broken-path resolvers ONLY should  
have the fallback position, and all resolvers should first assume  
clean, then b0rken, when appropriate.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 22 Jun 2009 11:13:26 +1000

In message <[email-masked]>, Florian Weimer writes:
> * Nicholas Weaver:
> If the middlebox (or misconfiguration) is on the server side, *all*
> clients potentially suffer from such brokenness.
> 
> Please don't assume this is exclusively a client-side issue.

Indeed.  Named has max-udp-size to help with exactly such a problem.
However most end user sites have the capacity to handle the resulting
TCP traffic.  Those that don't will take corrective steps.

Mark

---

From: Florian Weimer <[email-masked]>
Date: Sat, 20 Jun 2009 11:48:24 +0200