Re: [Dnsmasq-discuss] IPv6 on OpenWRT

[Eric Luehrsen]

Hi Alec,

Have you tried setting `--dhcp-option=option6:dns-server,[fd00::]` for auto 
fill in of ULA or `--dhcp-option=option6:dns-server,[::]` auto ~ GA? 

By default dnsmasq will send [fe80::] LL in RA and DHCPv6, but some clients do 
not like DNS on LL. It also can break down in some virtual-bridge situations. 
The client network driver forgets (or software resolver bug doesnt enter) which 
interface to route [fe80::] on. IT often requires %eth0 or some such. The above 
options will override this [fe80::] address, and make the situation more 
robust..

>2016-12-26 18:56 GMT-02:00 Alec Robertson :  
> Hi all, 
> 
> I am using dnsmasq on OpenWRT and I have configured the DHCPv6 server and 
> it is working well with the clients connected to the router. However, the 
> DNS is not working; IPv6 requests are not successful. 
> 
> The clients are given the router’s IP for DNS, like they are with IPv4 but 
> the DNS is not working. How do I configure the DNS servers on dnsmasq 
> correctly? I am using a 6in4 tunnel via Hurricane Electric. 
> 
> ___ 
> Dnsmasq-discuss mailing list 
> Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss 
> 
___
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

[Dave Taht]

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

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

[Simon Kelley]

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

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

[Dave Taht]

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_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.

-- 
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] [solved] Re: Finding actual DNS server used

[Chris Green]

On Mon, Jan 16, 2017 at 02:10:05PM +0100, Beniamino Galvani wrote:
> 
> In the next version of NetworkManager (1.6) it will be possible to
> show the DNS configuration in the output of 'nmcli' [1], as:
> 
Ah, now that seems to be a sensible approach.  :-)

-- 
Chris Green

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [solved] Re: Finding actual DNS server used

[Beniamino Galvani]

On Mon, Jan 16, 2017 at 08:36:05AM +0200, Lars Noodén wrote:
> Thanks. That's it.  I somehow missed it there in the manual page:
> 
>   When it receives a SIGUSR1, dnsmasq writes  statistics
>   to  the  system log.  … For each upstream server
>   it  gives  the  number  of  queries sent, and the
>   number which resulted in an error.
>   …
> 
> That gives me the information I was looking for regarding verifying
> which server dnsmasq is using.

Hi,

in addition to the suggested methods, an alternative way is to grep
system logs for:

 dnsmasq[6620]: setting upstream servers from DBus
 dnsmasq[6620]: using nameserver 192.168.10.1#53(via ens3)

In the next version of NetworkManager (1.6) it will be possible to
show the DNS configuration in the output of 'nmcli' [1], as:

 $ nmcli
 ens3: connected to internet+
"Realtek RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (QEMU Virtual 
Machine)"
ethernet (8139cp), 52:54:00:F1:61:81, hw, mtu 1500
ip4 default
inet4 192.168.10.166/24
 [...]
 DNS configuration:
servers: 10.0.0.1
domains: foobar.com
interface: tun0
type: vpn

servers: 192.168.10.1
interface: ens3

Beniamino

[1] 
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=20bf5ce35907e2a59fd1f1f9595b8eb202facc0f

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss