[Dnsmasq-discuss] Got bad packet: bad compression pointer

Simon Kelley simon at thekelleys.org.uk
Mon Jan 16 21:11:16 GMT 2017


-----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 at 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-----



More information about the Dnsmasq-discuss mailing list