On Wed, Dec 29, 2004 at 05:04:11PM -0500, Joe Abley wrote:
On 29 Dec 2004, at 16:33, Tony Rall wrote:
But that only affects tcp traffic - it does nothing to help other protocols.
Are there any common examples of the DF bit being set on non-TCP packets?
[root@bofh sabri]# host -t ns verisign.com 192.5.6.30 Using domain server 192.5.6.30: verisign.com name server bay-w1-inf5.verisign.net [root@bofh root]# tcpdump -Xn host 192.5.6.30 tcpdump: listening on fxp0 17:37:53.124955 217.69.153.39.55058 > 192.5.6.30.53: 58565+ NS? verisign.com. (30) 0x0000 4500 003a 5f10 0000 4011 e312 d945 9927 E..:_...@....E.' 0x0010 c005 061e d712 0035 0026 8ac9 e4c5 0100 .......5.&...... 0x0020 0001 0000 0000 0000 0876 6572 6973 6967 .........verisig 0x0030 6e03 636f 6d00 0002 0001 n.com..... 17:37:53.216656 192.5.6.30.53 > 217.69.153.39.55058: 58565- 3/0/3 NS[|domain] (DF) 0x0000 4500 00ca 0000 4000 3111 1093 c005 061e E.....@.1....... 0x0010 d945 9927 0035 d712 00b6 1b79 e4c5 8100 .E.'.5.....y.... 0x0020 0001 0003 0000 0003 0876 6572 6973 6967 .........verisig 0x0030 6e03 636f 6d00 0002 0001 c00c 0002 0001 n.com........... 0x0040 0002 a300 001a 0b62 6179 2d77 312d 696e .......bay-w1-in 0x0050 6635 f5 Here you go. A root-nameserver setting the DF-bit on its replies :) -- Sabri Berisha, SAB666-RIPE - I route, therefore you are http://www.cluecentral.net - http://www.virt-ix.net http://www.bash.org/?78486
On 5-jan-05, at 17:39, Sabri Berisha wrote:
Are there any common examples of the DF bit being set on non-TCP packets?
[...]
Here you go. A root-nameserver setting the DF-bit on its replies :)
This is very bad. With a 296 byte MTU I don't get answers from (a|b|h|j).root-servers.net, *.gtld-servers.net, tld2.ultradns.net and some lesser-known ccTLD servers. I would have thought this impossible, but seeing is believing... Fortunately, this problem won't present itself with regular smaller MTUs, the MTU has to be smaller than around 500 bytes. I haven't tested whether these servers also suffer from the "regular" PMTUD problem where the ICMP messages are ignored, but I'm assuming they don't, so doing all of this over TCP should still work.
In article <A7B004D6-6288-11D9-BA2A-000A95CD987A@muada.com> you write:
On 5-jan-05, at 17:39, Sabri Berisha wrote:
Are there any common examples of the DF bit being set on non-TCP packets?
[...]
Here you go. A root-nameserver setting the DF-bit on its replies :)
This is very bad.
With a 296 byte MTU I don't get answers from (a|b|h|j).root-servers.net, *.gtld-servers.net, tld2.ultradns.net and some lesser-known ccTLD servers.
I would have thought this impossible, but seeing is believing...
Fortunately, this problem won't present itself with regular smaller MTUs, the MTU has to be smaller than around 500 bytes. I haven't tested whether these servers also suffer from the "regular" PMTUD problem where the ICMP messages are ignored, but I'm assuming they don't, so doing all of this over TCP should still work.
Well DNS (not EDNS) is limited to 512 octets so you unless there are real links (not ones artificially constrained to demonstrate a issue) this should not be a issue in practice. The default link mtus for slip/ppp/ethernet are all large enought for a DNS/UDP response to get through without needing fragmentation. For EDNS which will send up to 4k UDP datagrams (current recommended size) this could be a issue in that the clients would have to fall back to DNS after timing out on the EDNS query. e.g. EDNS query EDNS response (dropped due to DF) timeout DNS query DNS response gets through. Note for IPv6 one sets IPV6_USE_MIN_MTU on the UDP socket so this should be a non-issue there. Mark
On 10-jan-05, at 0:08, Mark Andrews wrote:
Well DNS (not EDNS) is limited to 512 octets so you unless there are real links (not ones artificially constrained to demonstrate a issue) this should not be a issue in practice.
No, fortunately not. But it's still VERY wrong and it must be fixed.
Note for IPv6 one sets IPV6_USE_MIN_MTU on the UDP socket so this should be a non-issue there.
In IPv6 PMTUD is handled at the IP layer so the second packet that's too large will be fragmented at the source, so there is no issue.
I receive DNS responses > 500 bytes every day (reported by PIX firewall). So it is an issue, no matter wgat is recomended in RFC. ----- Original Message ----- From: "Mark Andrews" <Mark_Andrews@isc.org> To: <nanog@merit.edu> Sent: Sunday, January 09, 2005 3:08 PM Subject: Re: Broken PMTUD for . + TLD servers, was: Re: Smallest Transit MTU
In article <A7B004D6-6288-11D9-BA2A-000A95CD987A@muada.com> you write:
On 5-jan-05, at 17:39, Sabri Berisha wrote:
Are there any common examples of the DF bit being set on non-TCP packets?
[...]
Here you go. A root-nameserver setting the DF-bit on its replies :)
This is very bad.
With a 296 byte MTU I don't get answers from (a|b|h|j).root-servers.net, *.gtld-servers.net, tld2.ultradns.net and some lesser-known ccTLD servers.
I would have thought this impossible, but seeing is believing...
Fortunately, this problem won't present itself with regular smaller MTUs, the MTU has to be smaller than around 500 bytes. I haven't tested whether these servers also suffer from the "regular" PMTUD problem where the ICMP messages are ignored, but I'm assuming they don't, so doing all of this over TCP should still work.
Well DNS (not EDNS) is limited to 512 octets so you unless there are real links (not ones artificially constrained to demonstrate a issue) this should not be a issue in practice. The default link mtus for slip/ppp/ethernet are all large enought for a DNS/UDP response to get through without needing fragmentation.
For EDNS which will send up to 4k UDP datagrams (current recommended size) this could be a issue in that the clients would have to fall back to DNS after timing out on the EDNS query.
e.g. EDNS query EDNS response (dropped due to DF) timeout DNS query DNS response gets through.
Note for IPv6 one sets IPV6_USE_MIN_MTU on the UDP socket so this should be a non-issue there.
Mark
I receive DNS responses > 500 bytes every day (reported by PIX firewall). So it is an issue, no matter wgat is recomended in RFC.
And you most probable have EDNS clients (nameservers) inside your firewall making EDNS queries which return EDNS responses that are bigger than 512 bytes. EDNS has been standards track for over 5 years now. The majority of the nameservers in the world talk EDNS between themselves and have been for several years now. Only a few queries caused the EDNS response to exceed 512 bytes. With the introduction of the AAAA records for A.GTLD-SERVERS.NET and B.GTLD-SERVERS.NET any EDNS referral from the root servers for COM/NET now exceeds 512 bytes (520 minimum). A plain DNS referral to COM/NET is 509 bytes so any referal for an name longer than xx.com is dropping glue records for the COM/NET servers. The correct thing to do is to fix your firewall to handle the EDNS responses. Mark RFC 2671: Extension Mechanisms for DNS (EDNS0) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On Mon, 10 Jan 2005 22:42:28 +1100, Mark Andrews <Mark_Andrews@isc.org> wrote:
I receive DNS responses > 500 bytes every day (reported by PIX firewall). So it is an issue, no matter wgat is recomended in RFC.
The correct thing to do is to fix your firewall to handle the EDNS responses.
It is a cisco pix, right? Maybe just replacing the thing with a 1U openbsd box will work wonders. -- Suresh Ramasubramanian (ops.lists@gmail.com)
On Mon, 10 Jan 2005 22:42:28 +1100, Mark Andrews <Mark_Andrews@isc.org> wrote :
I receive DNS responses > 500 bytes every day (reported by PIX firewall). So it is an issue, no matter wgat is recomended in RFC.
The correct thing to do is to fix your firewall to handle the EDNS responses.
It is a cisco pix, right? Maybe just replacing the thing with a 1U openbsd box will work wonders.
A PIX firewall can handle EDNS fine. It just has to be told what is the maximum EDNS size being advertised by the internal clients. The defaults assume there is no EDNS (e.g. 512). -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
Yes, it is correct.
It is a cisco pix, right? Maybe just replacing the thing with a 1U openbsd box will work wonders.
A PIX firewall can handle EDNS fine. It just has to be told what is the maximum EDNS size being advertised by the internal clients. The defaults assume there is no EDNS (e.g. 512). -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
participants (5)
-
Alexei Roudnev -
Iljitsch van Beijnum -
Mark Andrews -
Sabri Berisha -
Suresh Ramasubramanian