Subject: Re: [dnsext] EDNS Page Option to handle large responses

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Jun 2009 09:22:45 +1000

In message <02A2F6D0BF4D4DF9A277E1B9604F869D@localhost>, "George Barwood" write
s:
> 
> ----- Original Message ----- 
> From: "Michael Graff" <[email-masked]>
> To: "George Barwood" <[email-masked]>
> Cc: "Mark Andrews" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, June 16, 2009 4:10 PM
> Subject: Re: [dnsext] EDNS Page Option to handle large responses
> 
> 
> > George Barwood wrote:
> > 
> >> All Zone administrators still need to be aware that oversize responses 
> >> are vulnerable to Dos attack ( by fragment and then the TCP fallback ).
> > 
> > How are servers today not vulnerable to a DDoS over TCP?  That is, what
> > does a large response size actually change for this risk?
> 
> The vulnerability of TCP has not changed, what has changed is the risk of needing to use it.
> Ordinary DNS (excluding zone transfers) never needs to fall back to TCP in normal use.

There have always been responses that have needed TCP.  TCP is a
normal part of the DNS and you have to go to extraordinary lengths
to stop fallback to TCP occuring.

The roots have had to fallback to TCP return referrals over plain
DNS on occasions.

What we are arguing over is the amount of TCP fallback.  When it
will occur and how often.  If you are sitting behind a firewall
that only allow 512 byte packets though and have not configured the
nameserver to send 512 byte packets the fallback path is extreemly
slow and no one who has a choice will want to continue to operate
in that state.  Go configure your firewall to only allow through
512 byte UDP/DNS packets and see for yourself. 

Mark

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

--
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: Mark Andrews <[email-masked]>
Date: Wed, 17 Jun 2009 16:12:49 +1000

In message <DBA6BB5BF9124D9CA48F4ED38ABF2FC6@localhost>, "George Barwood" writes:
> From: "Mark Andrews" <[email-masked]>
> Cc: "Michael Graff" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, June 17, 2009 12:22 AM
> Err.. no you don't. You just don't enable EDNS, and have a 512 byte response buffer.
> I have operated a resolver in this way that doesn't fall back to TCP, and have not 
> found something that does not resolve in many months of use. The priming query 
> and some referrals may have truncated additional sections, but that doesn't matter.

	Well you are lucky then or you use a recursive nameserver
	which violates the DNS standards by chopping up the answer
	section.

	EDNS, by itself, actually reduces the probability that you
	will have to fallback to TCP, it doesn't prevent it.

	DNSSEC increases the probability that you will fallback to
	TCP over EDNS alone.

	Plain DNS and DNSSEC with a 4069 byte EDNS clean path should
	have similar levels of TCP fallback.  You will get more TCP
	fallback with DNSSEC and EDNS@1200 and more fallback still
	with EDNS@512.

> > What we are arguing over is the amount of TCP fallback.  
> 
> Right, which is why I said 
> 
> "Ordinary DNS (excluding zone transfers) never needs to fall back to TCP in normal use."

	Ordinary DNS responses do fallback to TCP.  You will find
	that your stub resolvers and you recursive resolver will
	do this automatically.  Anyone who says differently really
	does not know what happens in the real world.
 
	This is the response to a ordinary query.  Note EDNS was
	not used and it fell back to using TCP.

;; Truncated, retrying in TCP mode.

; <<>> DiG 9.3.6-P1 <<>> dnskey se
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58614
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;se.				IN	DNSKEY

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

;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jun 17 15:44:28 2009
;; MSG SIZE  rcvd: 1016

> > When it

---

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Jun 2009 17:30:26 +1000

In message <C01EF232867944E48F95FBD97A1600EB@localhost>, "George Barwood" write
s:
> By "Ordinary" I mean pre-DNSSEC. DNSSEC is the change.
> 
> "The vulnerability of TCP has not changed, what has changed is the risk of needing to use it."

	Repeating something that is patently incorrect doesn't make
	it correct.  The fact that you have not experienced TCP
	fallback occuring doesn't mean that it doesn't happen.

	I've seen lots of cases where adminstrators have thought
	they could get away with not offering DNS over TCP just to
	have it backfire.  Microsoft did it at one point.  See
	attached.  Note there are no DNSSEC records involved and
	no EDNS either.

	Mark

Subject: Broken firewall.
From: [email-masked]
To: [email-masked]
Date: Tue, 01 May 2001 01:54:33 +1000

	Can you please either make your answers fit in a UDP response
	or allow DNS/TCP through the firewall.  At the moment your
	servers are telling the client to retry using TCP but you
	are not allowing the TCP connection to be established.

	Mark

; <<>> DiG 8.3 <<>> -x +ignore ptr @DNS4.CP.MSFT.NET 
; (1 server found)
;; res options: init igntc recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43996
;; flags: qr aa tc rd ra; QUERY: 1, ANSWER: 19, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;;	126.177.68.207.in-addr.arpa, type = PTR, class = IN

;; ANSWER SECTION:
126.177.68.207.in-addr.arpa.  1H IN PTR  c.compaq.net.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.fr.msn.ca.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.ktmsn.co.kr.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.latam.msn.com.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.msn.ca.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.msn.co.in.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.msn.co.jp.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.msn.co.kr.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.msn.co.nz.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.msn.com.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.msn.com.br.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.msn.com.hk.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.msn.com.mx.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.msn.com.my.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.msn.com.sg.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.msn.com.tw.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.msnbc.com.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.msretech.com.
126.177.68.207.in-addr.arpa.  1H IN PTR  c.t1msn.com.mx.

;; Total query time: 313 msec
;; FROM: drugs.dv.isc.org to SERVER: DNS4.CP.MSFT.NET  207.46.138.11
;; WHEN: Tue May  1 01:49:35 2001
;; MSG SIZE  sent: 45  rcvd: 504

drugs# tcpdump -n -p -s 1500 host DNS4.CP.MSFT.NET and port 53
tcpdump: listening on ep0
01:45:41.451316 130.155.191.236.2003 > 207.46.138.11.53: S 1043405316:1043405316(0) win 16384 <mss 1460> (DF)
01:45:44.444614 130.155.191.236.2003 > 207.46.138.11.53: S 1043405316:1043405316(0) win 16384 <mss 1460> (DF)
01:45:47.444653 130.155.191.236.2003 > 207.46.138.11.53: S 1043405316:1043405316(0) win 16384 <mss 1460> (DF)
01:45:50.444697 130.155.191.236.2003 > 207.46.138.11.53: S 1043405316:1043405316(0) win 16384 <mss 1460> (DF)
01:45:53.444747 130.155.191.236.2003 > 207.46.138.11.53: S 1043405316:1043405316(0) win 16384 <mss 1460> (DF)
01:45:56.444795 130.155.191.236.2003 > 207.46.138.11.53: S 1043405316:1043405316(0) win 16384 <mss 1460> (DF)
01:46:02.444884 130.155.191.236.2003 > 207.46.138.11.53: S 1043405316:1043405316(0) win 16384 <mss 1460> (DF)

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

---

From: Michael Graff <[email-masked]>
Date: Thu, 18 Jun 2009 16:10:29 -0500

Dean Anderson wrote:

> Once one abandons the socket/filedescriptor/kernel implementation of
> TCP, there is no need to worry about state.

... Other than the retransmit buffers.  TCP data is sequenced, and you
can't just drop data on the floor mid stream in the case a packet needs
to be retransmitted.

Doing a raw socket means that the application needs to implement TCP,
which would still need to have at hand, or be able to recreate, the data
for retransmit.  I just don't see this happening.

- --Michael