Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
Mark Andrews wrote: So? Fragmented packets *do* get through the network. Where they don't it slows up DNS resolution and the firewall usually gets fixed to allow fragments. Yes, hopefully within a decade or two, some firewall maybe fixed. So? Actually the firewalls get fixed pretty quickly in most cases. If you are thinking of ideal world with relatively new firewalls, maybe. The problem is that, in the real world, there are a lot of firewalls with maintenance period expired. But, even today, how much, in your opinion, is the assured-to-be- safe DNS message size over IPv6 with 1280B of MTU? Well we have space for around 700 bytes of additional header space before EDNS@512 will fail due to fragments being dropped. Now I'm sure one could artificially consume those 700 bytes but for the moment I'm not worried. You haven't answered my question. How much, in your opinion, is the assured-to-be-safe DNS message size over IPv6 with 1280B of MTU? Without such size, statements like: BIND 9.10 changes the first state to do variable-size probing: it will try 512, 1232, 1432, and 4096, starting at the bottom and working up and down depending on what works. The middle numbers come from the minimum IPv6 MTU minus space for headers, and the ethernet MTU minus v4 and v6 headers to allow for tunneling. can not be made. Masataka Ohta PS It should be noted that my modest proposal to have some (e.g. 256B) reasonable limit on the extension header length with an explanation that applications such as DNS need some limit was formally rejected by IPv6 WG (in Danvers meeting in 1995, IIRC) that you should expect more. IPv6 is produced by collective stupidity. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
i think there's a necessary and healthy tension between the installed base and new technology. i would not like to see every new application designed to run inside TCP/80, even though that's the only universal wide area protocol. and we won't see any new application that requires a forklift upgrade of the whole internet before it can be used -- no market. in this case i think mark's approach is right, because it works better for people who fix their firewalls, but it finds a way to work, no matter what. this puts a little bit of pressure on middlebox makers who mindlessly constrain future protocols. sardonically, the reason i chose fragmentation for EDNS rather than a new MD (More Data) bit in the flags and a new fragment number N of M option in the OPT RR, is that i imagined getting EDNS deployed in less than five years. now that it's been almost fifteen years and we're still fiddling with it, i can see that i made the wrong choice in RFC 2671. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
David Conrad wrote: The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”. This could be a bit of an issue when the DNSSEC root key is rolled. It is not, if separate RR types are used for different set of authentication algorithms and, during roll over, separate RR types are used for the current most and the second (and third or more, if necessary) current information, as I mentioned decades ago. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
In message 53d734ea.3010...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes: Tony Finch wrote: BIND 9.10 changes the first state to do variable-size probing: it will try 512, 1232, 1432, and 4096, starting at the bottom and working up and down depending on what works. The middle numbers come from the minimum IPv6 MTU minus space for headers, and the ethernet MTU minus v4 and v6 headers to allow for tunneling. Your assumption is that there is no extension headers exist. But, the problem of current IPv6 specification allows for very long extension headers (more than 60KB is allowed), some of which are automatically inserted not under transport/application layer control. So? Fragmented packets *do* get through the network. Where they don't it slows up DNS resolution and the firewall usually gets fixed to allow fragments. The break points above only come into play when there are firewalls that block fragmented traffic. One can always add more break points in the future. As for 60K headers, I'll worry about them when they start happening. So, as Fernando Gont wrote: While this issue/question may be currently masqueraded by the fact that we still have IPv4, I wonder what's the plan for the IPv6 case (at some point, we'll have to rely on whatever such plan is). The first thing to do is to obsolete extension headers and related gotcha in IPv6 specification. Even a fragmentation header has annoying requirement. Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi David, On 07/28/2014 04:05 PM, David Conrad wrote: Hi, On Jul 28, 2014, at 5:48 AM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote: The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”. This could be a bit of an issue when the DNSSEC root key is rolled. Could someone point me to a writeup and/or data as to how we know the above decree? (I'm not disagreeing, I just haven't really been following this for a while). The solution is to detect and fallback on EDNS0 MTU to retry at 1400B first (rather than directly down to 512b), and properly handle truncation. How many shipping resolvers actually do this? Unbound implements this. Since version 1.4.19 (dec 2012) at sizes 1472 and 1232. Earlier it also did this in version 1.4.14 (dec 2011) at sizes of 1480 and 1260 (but those are slightly wrong and that could cause issues if the 1480-response has a size 1472..1480). The logic in these versions is: if there is a timeout on EDNS0-4096 then retry with the 1400 version. Handle truncation with TCP. Like Nicholas suggests above. There is more logic that eventually falls back to non-EDNS (and the non-EDNS-ness is cached) but that is not pertinent to your question. Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT12KCAAoJEJ9vHC1+BF+NLsUP/iGjbFJ/FzfnteLscxIYMXMj 0hoY9z6NfmO4YVr0Cp2RgyzyDKRQDxSB1DZzzYy3ohjmuxsIczPjEnz7w2zFtZm3 bYAD5quK4abHJP975bHigTbY8X6EvnS9dqFsx5aca1ABw1FIapo4eIEvHzIh42Sx RCAITFbPeZYXs3xM/mE+5S63sjpXm3UOyxrQA+ie1k5yfU6KXVYN9IV8aP1cRq6L PtQlXdvvslc6cGw9nElUnmJWz1w3/RM6CPDs+lHR1EBWgusomNJbW+CLjm238xLx /bQWTLUvmIo3nzsFIcfseRNfmUkbQtc1SSEwXaCibgeIAMUy9SyXFETLqVP3srS2 8NCpA38pSFUEP0mgUK1n/lICWcKdYUMpgwYsMbv+zqH9SHXLUtY7vTtwQgM0 QOxY+BV5h1zGVrMnzXSzKbnkYKuPt6joSW/AEwvgU6O/+YDYUfoxNJdVq7BN0mcG g2qV1bdpMNpwG8zcOotRkz0aRaesZO2MAyTTmjEyrRHuxVAoi1CWVA3YEuSDz5Q/ iY6RX+QqN3jElLBPsJSqLBv0FoVNh0gOJUnjaoUnq8BlfC1vu+Z8//8aWOtPz+sH 2nOyYITwyGTo7hCAH/PM51VqkFywe9Bj8d9ZZbIiN+SnlktzGD4b9Usw7P6qC4ly epVir7Em3VEg9sM/ALom =sgn7 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
W.C.A. Wijngaards wou...@nlnetlabs.nl wrote: Unbound implements this. Since version 1.4.19 (dec 2012) at sizes 1472 and 1232. Does anyone have useful data on the amount that sub-ethernet MTUs cause problems? I am thinking particularly that tunnels are likely to break fragmentation and a stack like UDP/IPv6/crypto/UDP/IPv6 is likely to have 128 bytes of header. I suppose the fallback to the IPv6 minimum MTU will catch most of them. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Humber: Variable 4 but northerly 4 or 5 for a time in east, becoming northwesterly 4 or 5 later. Slight or moderate. Showers then fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
Mark Andrews wrote: But, the problem of current IPv6 specification allows for very long extension headers (more than 60KB is allowed), some of which are automatically inserted not under transport/application layer control. So? Fragmented packets *do* get through the network. Where they don't it slows up DNS resolution and the firewall usually gets fixed to allow fragments. Yes, hopefully within a decade or two, some firewall maybe fixed. So? As for 60K headers, I'll worry about them when they start happening. I know most of you have been short sighted to expect too much in the future. But, even today, how much, in your opinion, is the assured-to-be- safe DNS message size over IPv6 with 1280B of MTU? Masataka Ohta So, as Fernando Gont wrote: While this issue/question may be currently masqueraded by the fact that we still have IPv4, I wonder what's the plan for the IPv6 case (at some point, we'll have to rely on whatever such plan is). The first thing to do is to obsolete extension headers and related gotcha in IPv6 specification. Even a fragmentation header has annoying requirement. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
In message 53d82885.1030...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes: Mark Andrews wrote: But, the problem of current IPv6 specification allows for very long extension headers (more than 60KB is allowed), some of which are automatically inserted not under transport/application layer control. So? Fragmented packets *do* get through the network. Where they don't it slows up DNS resolution and the firewall usually gets fixed to allow fragments. Yes, hopefully within a decade or two, some firewall maybe fixed. So? Actually the firewalls get fixed pretty quickly in most cases. As for 60K headers, I'll worry about them when they start happening. I know most of you have been short sighted to expect too much in the future. But, even today, how much, in your opinion, is the assured-to-be- safe DNS message size over IPv6 with 1280B of MTU? Well we have space for around 700 bytes of additional header space before EDNS@512 will fail due to fragments being dropped. Now I'm sure one could artificially consume those 700 bytes but for the moment I'm not worried. Masataka Ohta So, as Fernando Gont wrote: While this issue/question may be currently masqueraded by the fact that we still have IPv4, I wonder what's the plan for the IPv6 case (at some point, we'll have to rely on whatever such plan is). The first thing to do is to obsolete extension headers and related gotcha in IPv6 specification. Even a fragmentation header has annoying requirement. Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNS, fragmentation, and IPv6 extension headers
Folks, (Apologies if this has been debated to death already). At the last IEPG meeting we presented some results regarding the filtering of packets that employ IPv6 extension headers (please see: http://www.iepg.org/2014-07-20-ietf90/iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0.pdf). The packet drop rates range from 10% to over 50%, depending on the dataset (FWIW, these packets drops have nothing to do with DNS-specific packet-drops caused by sloppy firewalls or the like). This essentially raises the question of What's the plan for transporting DNS queries/responses in IPv6? At different venues (including the IETF), I've received/listened_to different opinions. Quite a few folks usually argue oh, that's simple: we'll use TCP, while others tend to argue that one should be careful when thinking about relying on TCP for DNS queries/responses (e.g. see http://www.iepg.org/2013-11-ietf88/2013-11-Time-Value-DNS.pdf). While this issue/question may be currently masqueraded by the fact that we still have IPv4, I wonder what's the plan for the IPv6 case (at some point, we'll have to rely on whatever such plan is). If the answer is fall-back to TCP if UDP doesn't work, my next question would be does popular DNS server software implement mitigations for TCP-based attacks? (zero-windows, FIN-WAIT-X flooding, etc.) Thoughts? Thanks! -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
On Mon, Jul 28, 2014 at 08:24:59AM -0400, Fernando Gont ferna...@gont.com.ar wrote a message of 43 lines which said: The packet drop rates range from 10% to over 50%, depending on the dataset Annoying. This essentially raises the question of What's the plan for transporting DNS queries/responses in IPv6? Why do we need a plan? We serve DNS over IPv6 for now ten years and it works (not I think it works but it is monitored so I'm certain it works). The problem with extension headers is annoying but, today, they are not used (of course, it's partially a chicken and egg problem, similar to the problm of IPv4 options: they are not transported reliably so people don't use them, so there is no motivation to make them reliable, etc). Quite a few folks usually argue oh, that's simple: we'll use TCP, There are many good reasons to use TCP but, in that case, I do not see why we need it. First, IPv6 users typically don't use extension headers and, second, if the problem is in IP, why would changing from UDP to TCP work? does popular DNS server software implement mitigations for TCP-based attacks? (zero-windows, FIN-WAIT-X flooding, etc.) Is it something that should be done in every application, and not in TCP itself? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
On Jul 28, 2014, at 8:42 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: Quite a few folks usually argue oh, that's simple: we'll use TCP, There are many good reasons to use TCP but, in that case, I do not see why we need it. First, IPv6 users typically don't use extension headers and, second, if the problem is in IP, why would changing from UDP to TCP work? Because the big issue is fragments: The IPv4 net decreed “Fragment’s don’t really work”. The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”. The solution is to detect and fallback on EDNS0 MTU to retry at 1400B first (rather than directly down to 512b), and properly handle truncation. But you do that, and things do work. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
Hi, Stephane, Thanks so much for your prompt response. Comments in-line... On 07/28/2014 08:42 AM, Stephane Bortzmeyer wrote: This essentially raises the question of What's the plan for transporting DNS queries/responses in IPv6? Why do we need a plan? We serve DNS over IPv6 for now ten years and it works (not I think it works but it is monitored so I'm certain it works). Just curious: How do you check that the UDP-based DNS replies actually get to the node that sent the query? The problem with extension headers is annoying but, today, they are not used (of course, it's partially a chicken and egg problem, similar to the problm of IPv4 options: they are not transported reliably so people don't use them, so there is no motivation to make them reliable, etc). Agreed. Quite a few folks usually argue oh, that's simple: we'll use TCP, There are many good reasons to use TCP but, in that case, I do not see why we need it. First, IPv6 users typically don't use extension headers and, How do you send responses larger than , say, ~1500 bytes without fragmentation? second, if the problem is in IP, why would changing from UDP to TCP work? Because TCP can avoid fragmentation. does popular DNS server software implement mitigations for TCP-based attacks? (zero-windows, FIN-WAIT-X flooding, etc.) Is it something that should be done in every application, and not in TCP itself? There are some mitigations that can be implemented in the kernel, while others make more sense to implement at the app (yes, it'd be ugly to duplicate code in multiple apps, but) Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
On 07/28/2014 08:48 AM, Nicholas Weaver wrote: There are many good reasons to use TCP but, in that case, I do not see why we need it. First, IPv6 users typically don't use extension headers and, second, if the problem is in IP, why would changing from UDP to TCP work? Because the big issue is fragments: The IPv4 net decreed “Fragment’s don’t really work”. The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”. The solution is to detect and fallback on EDNS0 MTU to retry at 1400B first (rather than directly down to 512b), and properly handle truncation. But you do that, and things do work. Is this standard behavior, or rather an implementation thing? (ie.., t what extent may one expect this mechanism to be widely implemented?) Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
Hi, On Jul 28, 2014, at 5:48 AM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote: The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”. This could be a bit of an issue when the DNSSEC root key is rolled. Could someone point me to a writeup and/or data as to how we know the above decree? (I'm not disagreeing, I just haven't really been following this for a while). The solution is to detect and fallback on EDNS0 MTU to retry at 1400B first (rather than directly down to 512b), and properly handle truncation. How many shipping resolvers actually do this? Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
David Conrad d...@virtualized.org wrote: On Jul 28, 2014, at 5:48 AM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote: The solution is to detect and fallback on EDNS0 MTU to retry at 1400B first (rather than directly down to 512b), and properly handle truncation. How many shipping resolvers actually do this? I don't know what Unbound does. BIND 9.9 and earlier have three states in the default configuration: EDNS 4096, EDNS 512, and no-EDNS. It would start at the top and work down in response to failures. There is a knob to adjust the starting buffer size. BIND 9.10 changes the first state to do variable-size probing: it will try 512, 1232, 1432, and 4096, starting at the bottom and working up and down depending on what works. The middle numbers come from the minimum IPv6 MTU minus space for headers, and the ethernet MTU minus v4 and v6 headers to allow for tunneling. The (fixed) EDNS 512 and no-EDNS states remain. Unfortunately starting with a UDP size of 512 provokes masses of horrible truncation bugs in authority servers which causes more breakage (in my experience) than fragmentation does. It is particularly unfortunate when BIND decides to send no-EDNS queries for DNSSEC zones :-( I've hacked my BIND to drop the fixed EDNS 512 state and to start the variable-size probing at 1232 which seems to work a lot better. http://dnssec-deployment.org/pipermail/dnssec-deployment/2014-July/007080.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Cyclonic 4 or 5, becoming northerly 5 to 7 in north. Slight or moderate, becoming moderate or rough in north. Fog patches at first in east. Moderate or good, occasionally very poor at first in east. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
On Mon, Jul 28, 2014 at 08:52:06AM -0400, Fernando Gont ferna...@gont.com.ar wrote a message of 60 lines which said: Just curious: How do you check that the UDP-based DNS replies actually get to the node that sent the query? 1) Because, otherwise, we would see retransmissions by the client. 2) Because we tested from various places (see a trace attached). 3) Because nobody complained (the weakest argument...) How do you send responses larger than , say, ~1500 bytes without fragmentation? I really did not understand your point at all: when you said extension headers, I did not think of fragmentation but of Destination Options, things like that. I thought that your point was that extension headers do not work. So, your point is actually that fragmentation does not work? If so, there are other solutions such as decreasing the buffer size of the server, under the MTU (.com name servers do it). This also helps against amplification attacks. % dig -6 @d.ext.nic.fr ANY fr ; DiG 9.8.4-rpz2+rl005.12-P1 -6 @d.ext.nic.fr ANY fr ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 48851 ;; flags: qr aa rd; QUERY: 1, ANSWER: 20, AUTHORITY: 0, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;fr.IN ANY ;; ANSWER SECTION: fr. 172800 IN SOA nsmaster.nic.fr. hostmaster.nic.fr. ( 549502 ; serial 3600 ; refresh (1 hour) 1800 ; retry (30 minutes) 360; expire (5 weeks 6 days 16 hours) 5400 ; minimum (1 hour 30 minutes) ) fr. 0 IN RRSIG NSEC3PARAM 8 1 0 20140914071832 ( 20140716071832 47116 fr. frc2CPwNg8uhi79qD7HRRuLHHc9tBIUebEOOHxRqnq0H v5hYZCxahoZ2ZyO4oIf4uqjAIrB3IF8YUdebujJkhYiZ v0vcS5eHrnZRbWhn0tZEdxBYPaD51zGNrKENrQhdApbR iWUVL9ZjkfOPKAHvtgvSlQlCUhDamxpvOkmeAFM= ) fr. 0 IN NSEC3PARAM 1 0 1 33629585 fr. 172800 IN RRSIG DNSKEY 8 1 172800 20140914071832 ( 20140716071832 20122 fr. V47KfKfpCkwh0oC13es9Tr/dqNrG63SRLyhWYdwDWTXH +wRMQNrIXLDVWRk7ZqwFadYABP2ler5PTMQ7bM0sjMAa NmPou3Pj+xOr7mT9MAvIXzVNKehETh4dN9MtlTzLLAmO wCv9yBxby0197w+wDZYjkTTBMzVgXuUkj5ymWwENQmIU F9fs6RuTRY9ZNweczjWMQmQDwL9FBgLOHtO3o7fmYMOR 3oSUlFpXvg1U4ou8z28euz7+hoX4N4rKClSzwzdkQSWj es2nI+DB/QqhXAnkL0UxH3sYd953ejbzxAv8MtZG1up7 nNZb117VRmnL+eMe6AG0fuE/OSFaUBv6xw== ) fr. 172800 IN RRSIG DNSKEY 8 1 172800 20140914071832 ( 20140716071832 47116 fr. e1Yka0xOaumQgPgyvwhjlYxVTre+m1b9KmM1jvCyT0HV g80llLLzZVq8Ndj/iR+UXH7Ba2VxMZ47WhzdnQ67s/QR cVcXDNILHdurIurPiIpqZuixI3s+nylWYRhUpzaznIKH BznIXCgqIOVFnVowFaBMUvnMiSW2/yvv2jiPtxg= ) fr. 172800 IN DNSKEY 257 3 8 ( AwEAAa2sILZ4XD/QqobSU6NKFRzXwBV3OpHn21LWcGgz 84+g9emlizfjWv51lwsERFSgK+AqmKpYegptTY/PQJrg rCAvOEoQBZi3WvnjZFmMvqnZpeFlymIAiRgfAsHdF+Nx o/5eItUoJv3YjquFXcSQXpZJz5w6S/I2n+7W44GuWv3A iNuVJNG6qsy7sEZRc2SpOgM8RPtAQpwcA+YHPuMdIdba O7BEzlnmUN6bOSguVRz1SQR6+5xcLciZ264+whSTKtOy fjLvrrbTyZtXu8s++5xJkDQ8U/yUpBbtNaUVtlKeLFTe Ad8K6xd3ggAR2qLvUMp2XZYBBKF7Lfwn6fcEq6E= ) ; key id = 20122 fr. 172800 IN DNSKEY 256 3 8 ( AwEAAbSTCfGdqPiLkqwzc1MTj0lpXSTS0yKfhgeRXeaO VmDCzSJ2Xo4pWb0ByV6OA9qefTriLiwvXCiPnh3l9rEd T6qBo5AqnMaFhM723DebNr1BVLSZcZP5hadMLTMFexLH +ysquEbPgszN5ZqXTLtcuA9B0wmuX8a/66qq6xUIDq51 ) ; key id = 63211 fr. 172800 IN DNSKEY 256 3 8 ( AwEAAaxxBitg7Axk/Ra7HliE/AFvaGqZ49qMpQDPB/lo Ba2/VuswG3IrDqnWzkV/Gdex6MoIFEf9ty6yfdPhwdOh T9sr8auuN/BxMhB0pd7ZkZYYaVzDxN9Zl0k/90BmCNuh
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
On Mon, Jul 28, 2014 at 10:05 AM, David Conrad d...@virtualized.org wrote: Hi, On Jul 28, 2014, at 5:48 AM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote: The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”. This could be a bit of an issue when the DNSSEC root key is rolled. Could someone point me to a writeup and/or data as to how we know the above decree? (I'm not disagreeing, I just haven't really been following this for a while). As one data point, the current top DNSKEY response sizes for TLDs (all using UDP) are: xn--fiq228c5hs. 1669 xn--6frz82g. 1657 xn--3ds443g. 1657 rich. 1629 post. 1629 pink. 1629 info. 1629 blue. 1629 asia. 1629 red. 1625 org. 1625 onl. 1625 kim. 1625 sc. 1621 pr. 1621 mn. 1621 me. 1621 lc. 1621 in. 1621 gi. 1621 bz. 1621 ag. 1621 bg. 1567 xn--fiqz9s. 1505 xn--fiqs8s. 1505 am. 1479 cn. 1473 dk. 1459 All of the above result in IPv6 fragmentation, and nearly all also result in IPv4 fragmentation---both assuming a 1500-byte PMTU and a resolver using an EDNS UDP payload value sufficient to hold the entire payload. This list has changed over time, through key rollovers and such. Has there been empirical or anecdotal evidence to suggest that DNSSEC validation has been broken for these TLDs for some population? I'm not suggesting that fragmentation is pretty, and I'm quite aware of path problems with fragmentation (some of them having been worked around by resolver implementations and configurations, as Tony indicated). Casey ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
Tony Finch wrote: BIND 9.10 changes the first state to do variable-size probing: it will try 512, 1232, 1432, and 4096, starting at the bottom and working up and down depending on what works. The middle numbers come from the minimum IPv6 MTU minus space for headers, and the ethernet MTU minus v4 and v6 headers to allow for tunneling. Your assumption is that there is no extension headers exist. But, the problem of current IPv6 specification allows for very long extension headers (more than 60KB is allowed), some of which are automatically inserted not under transport/application layer control. So, as Fernando Gont wrote: While this issue/question may be currently masqueraded by the fact that we still have IPv4, I wonder what's the plan for the IPv6 case (at some point, we'll have to rely on whatever such plan is). The first thing to do is to obsolete extension headers and related gotcha in IPv6 specification. Even a fragmentation header has annoying requirement. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
