-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Host makes A, AAAA 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. 1798 IN SOA arnold.ns.cloudflare.com. dns.cloudflare.com. 2023610183 10000 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 188.8.131.52 > 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 Dnsmasqfirstname.lastname@example.org http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss