Re: [Dnsmasq-discuss] Got bad packet: bad compression pointer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Can you easily test newer code? Either git-HEAD or 2.77test3 has a fix for a bug which looks remarkably like this, and it would be good to eliminate that before going further. Cheers, Simon. On 27/02/17 14:08, Igor Lidin wrote: > I'm observing the following problem with dnsmasq 2.76 on arm7 > platform. > > Dnsmasq is responing with bad packet, but shouldn't. This is > somehow related to DNSSEC, ial.ru is signed. > > this is through local dnsmasq forwarding server: > > # dig soa guardian.ial.ru @127.0.0.1 ;; Got bad packet: bad > compression pointer 131 bytes a8 45 83 80 00 01 00 01 00 01 00 01 > 08 67 75 61 .E...gua 72 64 69 61 6e 03 69 61 6c 02 > 72 75 00 00 06 00 rdian.ial.ru 01 c0 0c 00 05 00 01 00 > 00 0e 0f 00 10 08 67 75 ..gu 61 72 64 69 61 6e > 02 75 6b 02 74 6f 00 c0 36 00 ardian.uk.to..6. 06 00 01 00 > 00 0e 10 00 2f 03 6e 73 31 06 61 66 /.ns1.af 72 61 > 69 64 03 6f 72 67 00 08 64 6e 73 61 64 6d > raid.org..dnsadm 69 6e c1 d9 65 76 95 a3 00 01 51 80 00 00 1c 20 > in..evQ. 00 24 ea 00 00 00 0e 10 00 00 29 10 00 00 00 00 > .$). 00 00 00 > ... > > this is though google dns on the same host: > > # dig soa guardian.ial.ru @8.8.8.8 > > ; <<>> DiG 9.10.4-P5 <<>> soa guardian.ial.ru @8.8.8.8 ;; global > options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: > NOERROR, id: 31031 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, > AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; > QUESTION SECTION: ;guardian.ial.ru. IN SOA > > ;; ANSWER SECTION: guardian.ial.ru.12 IN CNAME > guardian.uk.to. > > ;; AUTHORITY SECTION: uk.to. 1666IN SOA > ns1.afraid.org. dnsadmin.afraid.org. 1702270369 86400 7200 2419200 > 3600 > > ;; Query time: 63 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Mon > Feb 27 14:05:09 UTC 2017 ;; MSG SIZE rcvd: 131 > > this is related info: > > # dnsmasq -v Dnsmasq version 2.76 Copyright (c) 2000-2016 Simon > Kelley Compile time options: IPv6 GNU-getopt no-RTC no-DBus no-i18n > no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset Tomato-helper > auth DNSSEC loop-detect inotify > > This software comes with ABSOLUTELY NO WARRANTY. Dnsmasq is free > software, and you are welcome to redistribute it under the terms of > the GNU General Public License, version 2 or 3. > > # uname -a Linux guardian 2.6.36.4brcmarm #1 SMP PREEMPT Thu Feb 2 > 21:42:22 CET 2017 armv7l GNU/Linux > > # drill soa guardian.ial.ru Error: error sending query: Invalid > compression pointer > > # drill -v drill version 1.6.17 (ldns version 1.6.17) Written by > NLnet Labs. > > Copyright (c) 2004-2008 NLnet Labs. Licensed under the revised BSD > license. There is NO warranty; not even for MERCHANTABILITY or > FITNESS FOR A PARTICULAR PURPOSE. > > Best regards, Igor Lidin > > > ___ Dnsmasq-discuss > mailing list Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCAAGBQJYtE1UAAoJEBXN2mrhkTWi1zkP/384h/G/zTrQrbVVbr5ECp7t oflpq7kBhHnxxPIwO0r0O7s7GGghIjTK3XcbXJ0vr8SUls14PKFtIwAyPevxvGhY Ppf0ju9/QVuu3IZBxd+/6xSuMdgPTpz74+gNJx2t7f6LPYTWiQmOzhhJBTVH4Rzf SoDpF1mfDDO6kzpJJCg24uDWJ0FPQVIKb/qcnBog1MOgRsbzdQ06DFl5nIHRzhg9 jXsRIgEGkvPLPPwCSzG9HpErhrRiJYHA4CC2aQWPyo9h8KXH9Ji9JYgysmnWCoNo ky3hYA5UnzlyjEVKapR1hTf6WJRRr7mW7PwQKFX/LPrCCsrS+99KjRYin7h4frSM 23LWcFIyYEE9iGT7ZXqXEshpO63GEbh/z4VGzVPy0n0ZTudru+6t+p0i2yjBdQo0 Qwj3JYxa08d9tlc+Kz9w7F5gI2OzIzPy1aIJcV9m0pcq5HgjeVOj9yWeWFMrLkS0 KXFYvuiV4dbk6hKQLor0ZzwfpvBbOoQb1CCC1TM3jPsS+xU/5+tiBstU1nl+dglY bjBOkC8j7PgjwJ9WJ0eiWBJqJcnrLMMZ7K7KPjnMyxlFUa6HMnZryefGhyfNKSzJ Dg9RLFW/8GPoGi7PtiMofzQbIjiGNfhiNE1Z34w5G6uNkBU4TQtgaWRm9XqG/D9v mMMw92pWtv42aNFkx842 =UkkJ -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Got bad packet: bad compression pointer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OK, that's a bit difficult to correlate the client and upstream, but I can see in the responses coming back from upstream that the order of the RRs in the Auth section of the "no-such name" replies is NSEC RRSIG (for NSEC) SOA RRSIG (for SOA) That's different than for the google public DNS which returns SOA NSEC RRSIG RRSIG Both are valid, but the first exercises code-paths the second doesn't, since the SOA RR has to be moved when the NSEC and its RRSIG are deleted from the packet. The address of the upstream server in the captures is an RFC1918 address. Is there a comcast server at a public address that I can point to and get the same answers? That should allow me to reproduce the bug here. I just tried the first 5 or 6 servers in google's answer to the query "public dns" and they all reply in the SOA-first order. Need to find a public DNS server that replies in the NSEC-first order. Cheers, Simon. On 18/01/17 20:49, Dave Taht wrote: > The offputting part of your outline of what to check for was "some > hairy pointer code". :) I'm in the middle of some crash bugs > elsewhere, and I didn't realize how fast I could get you data > without thinking about the "hairy" parts. > > > dnssec and dnssec-check-unsigned are enabled, and I'm using > cachesize (what's the limit nowadays?) > > I put packet captures of the external interface on the router > (comcast upstream) and captures taken at the client, a log, and > conf file, here: > > http://www.taht.net/~d/dnssecbug/ > > Basically hammering on nslookup for the two internal and internal > captures there. > > Hammering on "dig" later, I was unable to trigger it on A, or > requests. Was able to easily trigger it on a MX request. > > flent-freemont does not exist, btw. Flent-fremont, does. It will > go boom on both. > > > > root@dancer:~/dnssecbug# dig flent-freemont.bufferbloat.net MX ;; > Got bad packet: bad compression pointer 123 bytes a5 c9 81 a0 00 01 > 00 00 00 01 00 01 0e 66 6c 65 .fle 6e 74 2d 66 > 72 65 65 6d 6f 6e 74 0b 62 75 66 66 nt-freemont.buff 65 72 > 62 6c 6f 61 74 03 6e 65 74 00 00 0f 00 01 > erbloat.net. c0 1b 00 06 00 01 00 00 0e 10 00 34 06 61 72 6e > ...4.arn 6f 6c 64 02 6e 73 0a 63 6c 6f 75 64 66 6c 61 72 > old.ns.cloudflar 65 03 63 6f 6d 00 03 64 6e 73 c0 eb 78 9d d7 47 > e.com..dns..x..G 00 00 27 10 00 00 09 60 00 09 3a 80 00 00 0e 10 > ..'`..:. 00 00 29 02 00 00 00 00 00 00 00 > ..) root@dancer:~/dnssecbug# dig > flent-freemont.bufferbloat.net MX > > ; <<>> DiG 9.10.3-P4-Ubuntu <<>> flent-freemont.bufferbloat.net MX > ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: > QUERY, status: NOERROR, id: 34631 ;; flags: qr rd ra ad; QUERY: 1, > ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; > QUESTION SECTION: ;flent-freemont.bufferbloat.net.INMX > > ;; AUTHORITY SECTION: bufferbloat.net.3600INSOA > arnold.ns.cloudflare.com. dns.cloudflare.com. 2023610183 1 2400 > 604800 3600 > > ;; Query time: 72 msec ;; SERVER: 172.26.16.1#53(172.26.16.1) ;; > WHEN: Wed Jan 18 12:42:02 PST 2017 ;; MSG SIZE rcvd: 123 > > > > On Wed, Jan 18, 2017 at 12:01 PM, Dave Taht > wrote: >> On Wed, Jan 18, 2017 at 11:48 AM, Simon Kelley >> wrote: > I won't have access to a MIPS system 'till the weekend. > > I assume you're using the git head code? >>> >>> No. Lede-project head. package claims to be dnsmasq-2.76-6. >>> libc is musl. >>> >>> Box under test was an archer c7v2. Can go try a few other mips >>> boxes like the wndr3800, but I've seen it there too. The arm >>> box (that is working) is an linksys-1200ac. (overall it's >>> looking like a fine release of lede) >>> > Did you manage to see a dump of the upstream reply? >>> >>> Not yet. I'll touch bases with you later in the week. >>> > > > Simon. > > > > On 18/01/17 07:31, Dave Taht wrote: > so far I can only make it happen on mips. Doesn't happen on > arm. Haven't tried harder yet. > >> >> >> >> -- Dave Täht Let's go make home routers and wifi faster! With >> better software! http://blog.cerowrt.org > > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCAAGBQJYhn5+AAoJEBXN2mrhkTWiTS8QAIwA9Ue2ovYfA/orURvb0VHg nc4NIpV4bDdKH6IwbpdrJLh4AO/2xs1ZCYNeb+YKz0QKbK1ycOiZqcwKr0OESWEc tMW1TFNXtdtAy3MHs9hgPJk3tnYzao8VdrsTFOiCUy2rdzexH4OOt17nJ2VC4+Hb xYZx6/cNOXPGYghk1UeZCJuvspV1UzQkcMJ+EDI5To1s33Nk7apaXY7k8XABYOip Aj/2F7SLyAohxPDyUR0Pc4NqNZjJhP9bGUfhotLcDWzEtXnVIpMx9OgapZ9s7e5z q9yYtqorDsPgdAeR9KqyizahjaOcEB3BA9PXshQb0+dutVzgxbrcXhUkBTr41gnY 8dOPA85dFxTasRKAcx1cyVZxZmaSSisP02rfn7FGvq2UmC7/gPlvIS+/2xnYMFqg wQ6fL+E0nEvT3MLENEDKh187QVYtckI2su+9J0enKZ+6w/yU0vHHocEjTBVqRFts n3dIeTRiHfSF0v5n27t7rJaX57bioRrYXRByYP9Lz75nGbLhgg7an7VEf2rz/Kx5 F3/BoisAF/xCc5Q/ves12St10J4JbWsvFaeZJDQVmsFquM6eE3fZ3XvdPFz6NtbJ MGWle5sbZXITLcZcrtusrAS8tDwPc1KZTEtV0
Re: [Dnsmasq-discuss] Got bad packet: bad compression pointer
The offputting part of your outline of what to check for was "some hairy pointer code". :) I'm in the middle of some crash bugs elsewhere, and I didn't realize how fast I could get you data without thinking about the "hairy" parts. dnssec and dnssec-check-unsigned are enabled, and I'm using cachesize (what's the limit nowadays?) I put packet captures of the external interface on the router (comcast upstream) and captures taken at the client, a log, and conf file, here: http://www.taht.net/~d/dnssecbug/ Basically hammering on nslookup for the two internal and internal captures there. Hammering on "dig" later, I was unable to trigger it on A, or requests. Was able to easily trigger it on a MX request. flent-freemont does not exist, btw. Flent-fremont, does. It will go boom on both. root@dancer:~/dnssecbug# dig flent-freemont.bufferbloat.net MX ;; Got bad packet: bad compression pointer 123 bytes a5 c9 81 a0 00 01 00 00 00 01 00 01 0e 66 6c 65 .fle 6e 74 2d 66 72 65 65 6d 6f 6e 74 0b 62 75 66 66 nt-freemont.buff 65 72 62 6c 6f 61 74 03 6e 65 74 00 00 0f 00 01 erbloat.net. c0 1b 00 06 00 01 00 00 0e 10 00 34 06 61 72 6e ...4.arn 6f 6c 64 02 6e 73 0a 63 6c 6f 75 64 66 6c 61 72 old.ns.cloudflar 65 03 63 6f 6d 00 03 64 6e 73 c0 eb 78 9d d7 47 e.com..dns..x..G 00 00 27 10 00 00 09 60 00 09 3a 80 00 00 0e 10 ..'`..:. 00 00 29 02 00 00 00 00 00 00 00 ..) root@dancer:~/dnssecbug# dig flent-freemont.bufferbloat.net MX ; <<>> DiG 9.10.3-P4-Ubuntu <<>> flent-freemont.bufferbloat.net MX ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34631 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;flent-freemont.bufferbloat.net.INMX ;; AUTHORITY SECTION: bufferbloat.net.3600INSOAarnold.ns.cloudflare.com. dns.cloudflare.com. 2023610183 1 2400 604800 3600 ;; Query time: 72 msec ;; SERVER: 172.26.16.1#53(172.26.16.1) ;; WHEN: Wed Jan 18 12:42:02 PST 2017 ;; MSG SIZE rcvd: 123 On Wed, Jan 18, 2017 at 12:01 PM, Dave Taht wrote: > On Wed, Jan 18, 2017 at 11:48 AM, Simon Kelley > wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> I won't have access to a MIPS system 'till the weekend. >> >> I assume you're using the git head code? > > No. Lede-project head. package claims to be dnsmasq-2.76-6. libc is musl. > > Box under test was an archer c7v2. Can go try a few other mips boxes > like the wndr3800, but I've seen it there too. The arm box (that is > working) is an linksys-1200ac. (overall it's looking like a fine > release of lede) > >> Did you manage to see a dump of the upstream reply? > > Not yet. I'll touch bases with you later in the week. > >> >> >> Simon. >> >> >> >> On 18/01/17 07:31, Dave Taht wrote: >>> so far I can only make it happen on mips. Doesn't happen on arm. >>> Haven't tried harder yet. >>> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v2.0.22 (GNU/Linux) >> >> iQIcBAEBCAAGBQJYf8aDAAoJEBXN2mrhkTWiN9UP/2E9D6j/nd3RsubzHgZSvzB/ >> CJPNyk32jnAqZdIa9D3DOH2L9gN5GyBiAtv4iCz5KuzDnB9twBtQWOdzde5sZWWd >> 4t8tSsvJkr0pRZhhRQKelF2oW0k7Y0UM4mD90ZoabX9ytQG4ceTFkHKlwwPLvvTc >> Osh9RmCpX1tsJoE/y+lMpEdT+GlhOe4z2Z9FZlTN7ke/uO9nIarekSIvnxgOnyac >> vrHvgnjyyEHbfr0BNaupdwZz9d/dVABYkFTDUk4dg4tn6MW99AsbD2DaL9alx8U/ >> MsvbFarQe/w8fJkmBJOThWkLMvpO1854XAysc8/m5ldIEwcV4Yge29nYrmDhn9kH >> Evo7wbKSH4AYGskYTiWnssczu1RhQOX9jCD31gv5CVOeTY4Dt7NR3WFCsAH2RYpR >> jcstckC5R1fqfKtQt9B0l2SWmmLukRcMbGM1hiJbqGrZcb++gZ2RYl80AD0iQhkD >> GjLNQAUKwlDwzB7JYXX+Fn0AVvP/G4qrmYBFlcxloddtrCiNqu4icTYIAb1zv0Lo >> opM+0fFcfg1PPPobTQ7FLJQR/uAO93MWZJ43Ht90YEdk6aaBCf7Ego1fU0G6TjCV >> iphmOqvhs96GFfhaBMYwFxvHb1tHNDT+Xzlsvkvk+S8SKyhNOg5GJOL2Dz78vlB/ >> fcImILW4vRf4rIkMDZKL >> =kPYg >> -END PGP SIGNATURE- > > > > -- > Dave Täht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Got bad packet: bad compression pointer
On Wed, Jan 18, 2017 at 11:48 AM, Simon Kelley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > I won't have access to a MIPS system 'till the weekend. > > I assume you're using the git head code? No. Lede-project head. package claims to be dnsmasq-2.76-6. libc is musl. Box under test was an archer c7v2. Can go try a few other mips boxes like the wndr3800, but I've seen it there too. The arm box (that is working) is an linksys-1200ac. (overall it's looking like a fine release of lede) > Did you manage to see a dump of the upstream reply? Not yet. I'll touch bases with you later in the week. > > > Simon. > > > > On 18/01/17 07:31, Dave Taht wrote: >> so far I can only make it happen on mips. Doesn't happen on arm. >> Haven't tried harder yet. >> > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQIcBAEBCAAGBQJYf8aDAAoJEBXN2mrhkTWiN9UP/2E9D6j/nd3RsubzHgZSvzB/ > CJPNyk32jnAqZdIa9D3DOH2L9gN5GyBiAtv4iCz5KuzDnB9twBtQWOdzde5sZWWd > 4t8tSsvJkr0pRZhhRQKelF2oW0k7Y0UM4mD90ZoabX9ytQG4ceTFkHKlwwPLvvTc > Osh9RmCpX1tsJoE/y+lMpEdT+GlhOe4z2Z9FZlTN7ke/uO9nIarekSIvnxgOnyac > vrHvgnjyyEHbfr0BNaupdwZz9d/dVABYkFTDUk4dg4tn6MW99AsbD2DaL9alx8U/ > MsvbFarQe/w8fJkmBJOThWkLMvpO1854XAysc8/m5ldIEwcV4Yge29nYrmDhn9kH > Evo7wbKSH4AYGskYTiWnssczu1RhQOX9jCD31gv5CVOeTY4Dt7NR3WFCsAH2RYpR > jcstckC5R1fqfKtQt9B0l2SWmmLukRcMbGM1hiJbqGrZcb++gZ2RYl80AD0iQhkD > GjLNQAUKwlDwzB7JYXX+Fn0AVvP/G4qrmYBFlcxloddtrCiNqu4icTYIAb1zv0Lo > opM+0fFcfg1PPPobTQ7FLJQR/uAO93MWZJ43Ht90YEdk6aaBCf7Ego1fU0G6TjCV > iphmOqvhs96GFfhaBMYwFxvHb1tHNDT+Xzlsvkvk+S8SKyhNOg5GJOL2Dz78vlB/ > fcImILW4vRf4rIkMDZKL > =kPYg > -END PGP SIGNATURE- -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Got bad packet: bad compression pointer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I won't have access to a MIPS system 'till the weekend. I assume you're using the git head code? Did you manage to see a dump of the upstream reply? Simon. On 18/01/17 07:31, Dave Taht wrote: > so far I can only make it happen on mips. Doesn't happen on arm. > Haven't tried harder yet. > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCAAGBQJYf8aDAAoJEBXN2mrhkTWiN9UP/2E9D6j/nd3RsubzHgZSvzB/ CJPNyk32jnAqZdIa9D3DOH2L9gN5GyBiAtv4iCz5KuzDnB9twBtQWOdzde5sZWWd 4t8tSsvJkr0pRZhhRQKelF2oW0k7Y0UM4mD90ZoabX9ytQG4ceTFkHKlwwPLvvTc Osh9RmCpX1tsJoE/y+lMpEdT+GlhOe4z2Z9FZlTN7ke/uO9nIarekSIvnxgOnyac vrHvgnjyyEHbfr0BNaupdwZz9d/dVABYkFTDUk4dg4tn6MW99AsbD2DaL9alx8U/ MsvbFarQe/w8fJkmBJOThWkLMvpO1854XAysc8/m5ldIEwcV4Yge29nYrmDhn9kH Evo7wbKSH4AYGskYTiWnssczu1RhQOX9jCD31gv5CVOeTY4Dt7NR3WFCsAH2RYpR jcstckC5R1fqfKtQt9B0l2SWmmLukRcMbGM1hiJbqGrZcb++gZ2RYl80AD0iQhkD GjLNQAUKwlDwzB7JYXX+Fn0AVvP/G4qrmYBFlcxloddtrCiNqu4icTYIAb1zv0Lo opM+0fFcfg1PPPobTQ7FLJQR/uAO93MWZJ43Ht90YEdk6aaBCf7Ego1fU0G6TjCV iphmOqvhs96GFfhaBMYwFxvHb1tHNDT+Xzlsvkvk+S8SKyhNOg5GJOL2Dz78vlB/ fcImILW4vRf4rIkMDZKL =kPYg -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Got bad packet: bad compression pointer
so far I can only make it happen on mips. Doesn't happen on arm. Haven't tried harder yet. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Got bad packet: bad compression pointer
On Mon, Jan 16, 2017 at 1:11 PM, Simon Kelley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Host makes A, and MX queries and it's the reply to the MX that's > failing. This all works fine here (dnsmasq and host both running on > the same x86_64 host. The reply to the MX query looks like this. > > > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19992 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;flent-fremont.bufferbloat.net. IN MX > > ;; AUTHORITY SECTION: > bufferbloat.net.1798IN SOA arnold.ns.cloudflare.com. > dns.cloudflare.com. 2023610183 1 2400 604800 3600 > > ;; Query time: 50 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Mon Jan 16 20:27:43 GMT 2017 > ;; MSG SIZE rcvd: 122 > > > Comparing the packet dump you have with the correct answer I'm seeing, > there are a few not-important differences (transaction-id, > time-to-live and SOA serial), the only other difference is the second > domain name in the SOA record, dns.cloudflare.com. That's represented > as the label "dns" and then a compression pointer pointing back to > previous instance of "cloudflare.com" in arnold.ns.cloudflare.com. The > correct pointer is c0 45, the pointer in your dump is c0 f0. (the c0 > is flags, the 45 (or f0) is an offset from the start of the packet). > > This packet has been through some hairy code in dnsmasq which elides > DNSSEC records (RRSIGs etc) and has to fix up the pointers thus > affected. My guess is that that's the problem, somehow, but I'm at a > loss to say why it works for me and breaks for you. It's a mips box supplying dns here. Different rules for alignment? > > Note that if my hypothesis is correct, you'll only see the effect when > the answer comes from upstream, and not when the answer comes from the > dnsmasq cache. > > If you want to try and debug this, first check that you can see the > same error just doing the MX query with a cold cache, then look at > what's happening in rrfilter() in src/rrfilter.c > > The other thing that would be useful is to capture the answer from > usptream complete with the NSEC and RRSIG records that need to be > removed. When I do that, the NSEC and RRSIG records come _after_ the > SOA record, so that the compression pointer in the SOA record doesn't > need to be touched at all, if the order of the records varied, that > could expose bugs in this code. > > Not an answer, but some good clues.. Don't even know if it's over ipv4 or ipv6 at the moment. will check harder. Great clues, thx, I'll get on it after I resolv https://bugs.lede-project.org/index.php?do=details&task_id=388 > > Cheers, > > Simon. > > > > > > > On 16/01/17 18:56, Dave Taht wrote: >> I am testing the dnsmasq-full build on current lede-project head, >> and enabled dnssec. Then : >> >> root@dancer:/# host flent-fremont.bufferbloat.net >> flent-fremont.bufferbloat.net has address 23.239.20.41 >> flent-fremont.bufferbloat.net has IPv6 address >> 2600:3c01::f03c:91ff:fe50:48d4 ;; Got bad packet: bad compression >> pointer 111 bytes 40 41 81 80 00 01 00 00 00 01 00 00 0d 66 6c 65 >> @A...fle 6e 74 2d 66 72 65 6d 6f 6e 74 0b 62 75 66 66 65 >> nt-fremont.buffe 72 62 6c 6f 61 74 03 6e 65 74 00 00 0f 00 01 c0 >> rbloat.net.. 1a 00 06 00 01 00 00 0e 10 00 34 06 61 72 6e 6f >> ..4.arno 6c 64 02 6e 73 0a 63 6c 6f 75 64 66 6c 61 72 65 >> ld.ns.cloudflare 03 63 6f 6d 00 03 64 6e 73 c0 f0 78 9d d7 47 00 >> .com..dns..x..G. 00 27 10 00 00 09 60 00 09 3a 80 00 00 0e 10 >> .'`..:. >> >> >> Filed the bug here: >> https://bugs.lede-project.org/index.php?do=details&task_id=392 >> >> I see a few other references to this phrase elsewhere on the net >> but did not find a resolution. >> >> In this case I've seen this with osx sierra, and "dancer" is a >> pretty recent ubuntu box. The dnssec tests on the web seem to all >> pass, it just shows up with host - and not consistently. I just had >> it happen one time in 4, on a recent test. >> > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQIcBAEBCAAGBQJYfTb0AAoJEBXN2mrhkTWiffYP/Ariw/tDKjfy8pd6/Z2Nixc/ > MW5zcQAh421uxrSIA4NNhJeymiXdiwQNC8CAbvtSPNvwE87Ed8GlnfExnYSzWpig > UvjJS1fXRF+y57e8UcqQmZEXTNtE/wdc5Rs0nqv+TpLaBMXF4nVjABmSsNOzymrw > VQdMOHIrqGx4xmeiRU2JhUXPX57uxLTH1PmJ0PxHj5RPWm9xG8kzq3h7gtzA6hMs > j/SXApIM6trC34D+zrFt/4HrsneJuzFvEiolN9N1MurrdEW8SVlr8k37hayMU48w > fZa5W6EZ3UYS2YDMYMfUlYNDC2aktQO8KWF80aQvzdvDS8LWJNkJ1vcBZFV5gEht > J0AdZdK4b9J/j1Ejxxq37D3xWRG9VKuiyqPkvNlksLkrNeoS+aV3HdBDvqHbejz+ > jDXSEXDvIOQ1Lg5RKFt7dkTZPlWpZnkzJqfFeIR4TsHYypqNUOSpuG+ar+4FfDaq > dMyNYbut75GN2HFuVMpedHiSjKaCQ1Oq90Zbwy4AO4sd81uMirpOILqB/siGghY+ > e1NcfNR/RZJJxpAOS5I0f/TXycB7vgfLwJ+06m1JGwD+EyTKpyVqL16JsK18OsuM > vuBGaKA0/ReUQB+wPyJ1JVFlTmztmgaZLF/ZHg6PsjxkFvsn34GIsGEWMjfekXKc > irEZUnVMT8mWU
Re: [Dnsmasq-discuss] Got bad packet: bad compression pointer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Host makes A, and MX queries and it's the reply to the MX that's failing. This all works fine here (dnsmasq and host both running on the same x86_64 host. The reply to the MX query looks like this. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19992 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;flent-fremont.bufferbloat.net. IN MX ;; AUTHORITY SECTION: bufferbloat.net.1798IN SOA arnold.ns.cloudflare.com. dns.cloudflare.com. 2023610183 1 2400 604800 3600 ;; Query time: 50 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Jan 16 20:27:43 GMT 2017 ;; MSG SIZE rcvd: 122 Comparing the packet dump you have with the correct answer I'm seeing, there are a few not-important differences (transaction-id, time-to-live and SOA serial), the only other difference is the second domain name in the SOA record, dns.cloudflare.com. That's represented as the label "dns" and then a compression pointer pointing back to previous instance of "cloudflare.com" in arnold.ns.cloudflare.com. The correct pointer is c0 45, the pointer in your dump is c0 f0. (the c0 is flags, the 45 (or f0) is an offset from the start of the packet). This packet has been through some hairy code in dnsmasq which elides DNSSEC records (RRSIGs etc) and has to fix up the pointers thus affected. My guess is that that's the problem, somehow, but I'm at a loss to say why it works for me and breaks for you. Note that if my hypothesis is correct, you'll only see the effect when the answer comes from upstream, and not when the answer comes from the dnsmasq cache. If you want to try and debug this, first check that you can see the same error just doing the MX query with a cold cache, then look at what's happening in rrfilter() in src/rrfilter.c The other thing that would be useful is to capture the answer from usptream complete with the NSEC and RRSIG records that need to be removed. When I do that, the NSEC and RRSIG records come _after_ the SOA record, so that the compression pointer in the SOA record doesn't need to be touched at all, if the order of the records varied, that could expose bugs in this code. Not an answer, but some good clues.. Cheers, Simon. On 16/01/17 18:56, Dave Taht wrote: > I am testing the dnsmasq-full build on current lede-project head, > and enabled dnssec. Then : > > root@dancer:/# host flent-fremont.bufferbloat.net > flent-fremont.bufferbloat.net has address 23.239.20.41 > flent-fremont.bufferbloat.net has IPv6 address > 2600:3c01::f03c:91ff:fe50:48d4 ;; Got bad packet: bad compression > pointer 111 bytes 40 41 81 80 00 01 00 00 00 01 00 00 0d 66 6c 65 > @A...fle 6e 74 2d 66 72 65 6d 6f 6e 74 0b 62 75 66 66 65 > nt-fremont.buffe 72 62 6c 6f 61 74 03 6e 65 74 00 00 0f 00 01 c0 > rbloat.net.. 1a 00 06 00 01 00 00 0e 10 00 34 06 61 72 6e 6f > ..4.arno 6c 64 02 6e 73 0a 63 6c 6f 75 64 66 6c 61 72 65 > ld.ns.cloudflare 03 63 6f 6d 00 03 64 6e 73 c0 f0 78 9d d7 47 00 > .com..dns..x..G. 00 27 10 00 00 09 60 00 09 3a 80 00 00 0e 10 > .'`..:. > > > Filed the bug here: > https://bugs.lede-project.org/index.php?do=details&task_id=392 > > I see a few other references to this phrase elsewhere on the net > but did not find a resolution. > > In this case I've seen this with osx sierra, and "dancer" is a > pretty recent ubuntu box. The dnssec tests on the web seem to all > pass, it just shows up with host - and not consistently. I just had > it happen one time in 4, on a recent test. > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCAAGBQJYfTb0AAoJEBXN2mrhkTWiffYP/Ariw/tDKjfy8pd6/Z2Nixc/ MW5zcQAh421uxrSIA4NNhJeymiXdiwQNC8CAbvtSPNvwE87Ed8GlnfExnYSzWpig UvjJS1fXRF+y57e8UcqQmZEXTNtE/wdc5Rs0nqv+TpLaBMXF4nVjABmSsNOzymrw VQdMOHIrqGx4xmeiRU2JhUXPX57uxLTH1PmJ0PxHj5RPWm9xG8kzq3h7gtzA6hMs j/SXApIM6trC34D+zrFt/4HrsneJuzFvEiolN9N1MurrdEW8SVlr8k37hayMU48w fZa5W6EZ3UYS2YDMYMfUlYNDC2aktQO8KWF80aQvzdvDS8LWJNkJ1vcBZFV5gEht J0AdZdK4b9J/j1Ejxxq37D3xWRG9VKuiyqPkvNlksLkrNeoS+aV3HdBDvqHbejz+ jDXSEXDvIOQ1Lg5RKFt7dkTZPlWpZnkzJqfFeIR4TsHYypqNUOSpuG+ar+4FfDaq dMyNYbut75GN2HFuVMpedHiSjKaCQ1Oq90Zbwy4AO4sd81uMirpOILqB/siGghY+ e1NcfNR/RZJJxpAOS5I0f/TXycB7vgfLwJ+06m1JGwD+EyTKpyVqL16JsK18OsuM vuBGaKA0/ReUQB+wPyJ1JVFlTmztmgaZLF/ZHg6PsjxkFvsn34GIsGEWMjfekXKc irEZUnVMT8mWUyBPZ4p2 =aDdB -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
