Re: [Dnsmasq-discuss] Windows ipv6 hostname

[Toke Høiland-Jørgensen]

Markus Hartung <m...@hartmark.se> writes:

> On 2016-12-19 06:18, Toke Høiland-Jørgensen wrote:
>> Markus Hartung <m...@hartmark.se> writes:
>>
>> ...
>> My guess is that Windows 10 implements RFC7217:
>> https://tools.ietf.org/html/rfc7217
>>
>> If this is the case, there is no way for dnsmasq to predict the IPv6
>> address of a new client (which is what ra-names relies on), and so you
>> can't get the  record.
>
> It's a shame the windows 10 IPv6 implementation lacks those stuff.

Well, arguably the Windows 10 behaviour is a feature - RFC7217 was
written because the EUI-64 based approach has privacy issues (the client
will use the same address on every network). So I would expect more and
more clients to adopt the privacy-preserving approach. I believe
NetworkManager has support for it on Linux, but am not sure if it's
enabled by default.

>> A way to get naming is to use ohybridproxy:
>> https://github.com/sbyx/ohybridproxy - this will query mdns on the
>> network for  records when asked. However, I am not sure if there is
>> a way to integrate this with the authoritative server in dnsmasq (but if
>> there is, I would love to know about it).

> Thanks for the information, but I have managed to compile ohybridproxy
> and have no idea on how to use it.

Haven't had time to play with it myself yet, so can't be of much help
there; but as I understand it, the idea is that you configure the proxy
to use a particular domain, and then point dnsmasq at it with --server.
Don't think this will integrate with the auth server mechanism in
dnsmasq, though; not sure if there's a way to achieve that.

The alternative is to turn off the private addresses in Windows 10, of
course (as Michael suggested).

-Toke

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

Re: [Dnsmasq-discuss] Windows ipv6 hostname

[Toke Høiland-Jørgensen]

Markus Hartung  writes:

> Hello,
>
> Anyone here that is more knowledgeable about IPv6 and Windows 10 hosts?
>
> I have set up my dnsmasq as a authoritative DNS server and have enable ra with
> these options:
>
> enable-ra
> dhcp-range=tag:eno1,::1,::,constructor:eno1,ra-names,24h
>
> It seems that my linux hosts are correctly getting a IPv6 address and 
> registers
> correctly a -record in the DNS server.
>
> My Windows 10 host gets an IPv6 address but doesn't get any -record.
>
> Can anyone shed any light on the situation? Do the linux and windows
> hosts get their IPv6 differently? And is there a way to get windows to
> register an -record?

My guess is that Windows 10 implements RFC7217:
https://tools.ietf.org/html/rfc7217

If this is the case, there is no way for dnsmasq to predict the IPv6
address of a new client (which is what ra-names relies on), and so you
can't get the  record.

A way to get naming is to use ohybridproxy:
https://github.com/sbyx/ohybridproxy - this will query mdns on the
network for  records when asked. However, I am not sure if there is
a way to integrate this with the authoritative server in dnsmasq (but if
there is, I would love to know about it).

-Toke

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

Re: [Dnsmasq-discuss] Dnsmasq doesn't reply to queries made over (link-local) IPv6

[Toke Høiland-Jørgensen]

Simon Kelley  writes:

> Duplicate MAC addresses, leading to duplicated link-local addresses?

Yeah, there seems to be plenty of those. But changing the MAC address of
the affected interface (i.e. eth1.1) doesn't help. And the box that
works has even more duplicate addresses.

Guess I'll try to cook up a small test program and see if I can
reproduce the effect outside of dnsmasq. When I get some more time to
burn on this, that is.

In the meantime, I guess I'll just disable DHCPv6 on the affected hosts...

-Toke

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

Re: [Dnsmasq-discuss] Dnsmasq doesn't reply to queries made over (link-local) IPv6

[Toke Høiland-Jørgensen]

Simon Kelley  writes:

> The traces you've both posted look good to me: dnsmasq is providing
> the correct value in the sin6_scope_id field of the destination
> address when sending the reply.
>
> The obvious difference between the failing case and the working one is
> that Toke is using an interface to a VLAN, eth1.1, whilst I used a
> standard physical interface and Kevin used a bridge interface. Toke,
> could you try on a interface other than a tagged VLAN, and see if you
> get the same effect?
>
> Also, try doing a packet capture on the physical interface underlying
> the VLAN interface, to see if that gives you the packets that you're n
> not seeing by capturing the VLAN interface.

Tried all that, doesn't help. However, I have another box where things
work fine; "only" difference being the hardware. So I guess it's not a
bug in dnsmasq at least. Thanks for the help in debugging... :)

-Toke

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

Re: [Dnsmasq-discuss] Dnsmasq doesn't reply to queries made over (link-local) IPv6

[Toke Høiland-Jørgensen]

Simon Kelley  writes:

> OK, naive attempts to reproduce this have failed entirely, it just works
> for me :-)
>
> Can you run dnsmasq under strace -e trace=network and see what syscalls
> it makes, specifically, if it's calling sendmsg() with the reply?
>
> This is what I see, not that sin6_scope_id is correct in both calls.
>
> recvmsg(6, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(40524),
> inet_pton(AF_INET6, "fe80::224:d6ff:feb0:75a2", _addr),
> sin6_flowinfo=0, sin6_scope_id=if_nametoindex("wlan0")},
> msg_iov(1)=[{"?9\1
> \0\1\0\0\0\0\0\1\3mit\3edu\0\0\1\0\1\0\0)\20\0\0\0"..., 4096}],
> msg_controllen=40, {cmsg_len=36, cmsg_level=SOL_IPV6, cmsg_type=, ...},
> msg_flags=0}, 0) = 36
> dnsmasq: query[A] mit.edu from fe80::224:d6ff:feb0:75a2
> dnsmasq: cached mit.edu is 104.64.165.212
> sendmsg(6, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(40524),
> inet_pton(AF_INET6, "fe80::224:d6ff:feb0:75a2", _addr),
> sin6_flowinfo=0, sin6_scope_id=if_nametoindex("wlan0")},
> msg_iov(1)=[{"?9\201\200\0\1\0\1\0\0\0\1\3mit\3edu\0\0\1\0\1\300\f\0\1\0\1\0"...,
> 52}], msg_controllen=36, {cmsg_len=36, cmsg_level=SOL_IPV6, cmsg_type=,
> ...}, msg_flags=0}, 0) = 52

I see something similar:

recvmsg(10, {msg_name={sa_family=AF_INET6, sin6_port=htons(50214), 
inet_pton(AF_INET6, "fe80::c23f:d5ff:fe62:22ac", _addr), 
sin6_flowinfo=htonl(0), sin6_scope_id=if_nametoindex("eth1.1")}, 
msg_namelen=28, 
msg_iov=[{iov_base="\243\307\1\0\0\1\0\0\0\0\0\0\6google\3com\0\0\1\0\1", 
iov_len=4096}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_IPV6, 
cmsg_type=0x32}], msg_controllen=32, msg_flags=0}, 0) = 28
dnsmasq: query[A] google.com from fe80::c23f:d5ff:fe62:22ac
socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 16
bind(16, {sa_family=AF_INET6, sin6_port=htons(25784), inet_pton(AF_INET6, "::", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 0
sendto(16, "%\316\1\0\0\1\0\0\0\0\0\1\6google\3com\0\0\1\0\1\0\0)\20"..., 39, 
0, {sa_family=AF_INET6, sin6_port=htons(5333), inet_pton(AF_INET6, "::1", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 39
dnsmasq: forwarded google.com to ::1
recvfrom(16, 
"%\316\201\200\0\1\0\6\0\0\0\1\6google\3com\0\0\1\0\1\300\f\0\1"..., 5131, 0, 
{sa_family=AF_INET6, sin6_port=htons(5333), inet_pton(AF_INET6, "::1", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 135
dnsmasq: dnssec-query[DS] com to ::1
socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 17
bind(17, {sa_family=AF_INET6, sin6_port=htons(18533), inet_pton(AF_INET6, "::", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 0
sendto(17, "B0\1\0\0\1\0\0\0\0\0\1\3com\0\0+\0\1\0\0)\20\0\0\0\200\0\0\0", 32, 
0, {sa_family=AF_INET6, sin6_port=htons(5333), inet_pton(AF_INET6, "::1", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 32
recvfrom(17, 
"B0\201\200\0\1\0\2\0\0\0\1\3com\0\0+\0\1\300\f\0+\0\1\0\1Q\200\0"..., 5131, 0, 
{sa_family=AF_INET6, sin6_port=htons(5333), inet_pton(AF_INET6, "::1", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 239
dnsmasq: reply com is DS keytag 30909, algo 8, digest 2
dnsmasq: dnssec-query[DS] google.com to ::1
socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 17
bind(17, {sa_family=AF_INET6, sin6_port=htons(60387), inet_pton(AF_INET6, "::", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 0
sendto(17, "\6s\1\0\0\1\0\0\0\0\0\1\6google\3com\0\0+\0\1\0\0)\20"..., 39, 0, 
{sa_family=AF_INET6, sin6_port=htons(5333), inet_pton(AF_INET6, "::1", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 39
recvfrom(17, "\6s\201\200\0\1\0\0\0\6\0\1\6google\3com\0\0+\0\1 CK0"..., 5131, 
0, {sa_family=AF_INET6, sin6_port=htons(5333), inet_pton(AF_INET6, "::1", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 760
dnsmasq: dnssec-query[DNSKEY] com to ::1
socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 18
bind(18, {sa_family=AF_INET6, sin6_port=htons(19389), inet_pton(AF_INET6, "::", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 0
sendto(18, "V\252\1\0\0\1\0\0\0\0\0\1\3com\0\\0\1\0\0)\20\0\0\0\200\0\0\0", 
32, 0, {sa_family=AF_INET6, sin6_port=htons(5333), inet_pton(AF_INET6, "::1", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 32
recvfrom(18, 
"V\252\201\200\0\1\0\3\0\0\0\1\3com\0\\0\1\300\f\\0\1\0\1P>\0"..., 
5131, 0, {sa_family=AF_INET6, sin6_port=htons(5333), inet_pton(AF_INET6, "::1", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 743
dnsmasq: reply com is DNSKEY keytag 27452, algo 8
dnsmasq: reply com is DNSKEY keytag 30909, algo 8
dnsmasq: reply google.com is no DS
dnsmasq: validation result is INSECURE
dnsmasq: reply google.com is 173.194.222.139
dnsmasq: reply google.com is 173.194.222.138
dnsmasq: reply google.com is 173.194.222.113
dnsmasq: reply google.com is 173.194.222.100
dnsmasq: reply google.com is 173.194.222.101
dnsmasq: reply google.com is 173.194.222.102
sendmsg(10, {msg_name={sa_family=AF_INET6, sin6_port=htons(50214), 
inet_pton(AF_INET6, "fe80::c23f:d5ff:fe62:22ac", 

Re: [Dnsmasq-discuss] Dnsmasq doesn't reply to queries made over (link-local) IPv6

[Toke Høiland-Jørgensen]

Simon Kelley  writes:

> My first thought is that it's probably replying to the wrong
> interface: link local addresses can't be routed: you have to specify
> the interface they're connected to. This insight came late to me, and
> there's a chance that the dnsmasq code is still messing it up. I'll
> take a closer look in the next day or two.

Awesome, thanks! :)

-Toke

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

Re: [Dnsmasq-discuss] Quicker IPv6 connectivity recovery when using ra-stateless mode

[Toke Høiland-Jørgensen]

Xander Victory  writes:

> You laptop should send an ipv6 router solicit (which should trigger an
> advertisement). Do you see this looking at tcpdump for icmpv6?
> What OS & version is it running?

Ah, I see. No, my laptop doesn't seem to be sending router solicitation
messages, even though the relevant sysctls are set to their default
values. I'm running Arch Linux on kernel 4.6.4, using systemd-networkd
to configure the interface.

It may be that there's some timing issues with the connection not being
available even though the interface appears to be up from the kernel's
point of view. Haven't been able to see any router solicitations go out
at all, though.

Aha, and there appears to be a systemd bug opened on this:
https://github.com/systemd/systemd/issues/3664 -- will investigate
further... thanks for the pointer :)

-Toke

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

[Dnsmasq-discuss] Quicker IPv6 connectivity recovery when using ra-stateless mode

[Toke Høiland-Jørgensen]

So I've been noticing that when resuming my laptop from suspend (and
reconnecting to the WiFi network), I will get IPv4 connectivity a lot
sooner than IPv6. I'm using dnsmasq in ra-stateless mode.

Looking at tcpdump output, it seems that my laptop will send a DHCP
solicit message (for both IPv4 and IPv6) immediately when the interface
connects to the WiFi, and it does get an IPv6 reply from dnsmasq. But it
takes a while before a router advertisement arrives, so there will be no
default route installed on the laptop.

Provided I'm interpreting what is happening correctly, would it be
possible to have dnsmasq trigger a router advertisement on an interface
whenever it replies to DHCP requests? Not sure if the RA spec allows
unicasting advertisements; if it does, unicasting it to the host that
asks for DHCP would be a way to cut down on multicast traffic. But
simply sending an additional multicast RA would also work, I suppose.

-Toke

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

[Dnsmasq-discuss] Failure on dnssec-check-unsigned for Cloudflare re-delegated domains

[Toke Høiland-Jørgensen]

I recently moved one of my domains to Cloudflare DNS. This has caused
some issues with resolving through dnsmasq when dnssec-check-unsigned is
enabled. Cloudflare supports DNSSEC and resolving the hostnames directly
specified in their DNS works fine. The issue is with subdomains that are
re-delegated with a subsequent NS record (insecurely; to dnsmasq
instances, incidentally, but that's beside the point here).

I *think* that the issue is that the NSEC record for the subdomain
includes a spurious null byte:

$ host -t NSEC brohuset.milos.dk
brohuset.milos.dk has NSEC record brohuset\000.milos.dk. NS RRSIG NSEC

Dnsviz seems to think that the NSEC record matches, and that the
delegation is insecure (as expected). Although it gives a bunch of other
errors: http://dnsviz.net/d/brohuset.milos.dk/dnssec/


So I'm actually not sure if this is an issue with dnsmasq or if
Cloudflare's DNS is buggy. Unbound does seem to resolve the domain,
though.

This is with dnsmasq 2.76.

-Toke

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

Re: [Dnsmasq-discuss] Multiple subnets question

[Toke Høiland-Jørgensen]

Chris Green c...@isbd.net writes:

 On Wed, Jul 08, 2015 at 01:26:30PM +0200, Hartmut Krafft wrote:
 Hi Chris,
 
 snip

 Is it possible to somehow tell a router (the W311R+) to pass DHCP
 requests on to its WAN side and then get dnsmasq to assign an IP in
 the correct range for the W311R+.
 
 From the top of my mind: Set the LANside of the W311 to the same subnet
 as the rest, don't use the WAN port, connect the cable to the LANport.
 DHCP broadcasts should reach dnsmasq if the WiFi and LAN ports are bridged.
 
 Yes, I hoped/thought this should work but it would appear not.  Maybe
 it's a quirk/failing of this particular wireless router (I'm only
 using it because I happened to have it).

Another option is using something like this: http://linux.die.net/man/8/dhcrelay

-Toke

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

Re: [Dnsmasq-discuss] Multiple subnets question

[Toke Høiland-Jørgensen]

Chris Green c...@isbd.net writes:

 But that would require that there's a Linux box permanently on the LAN
 side of the W311R+ wouldn't it?

Yeah, it would. Or on that box itself if you can persuade it to run
openwrt :)

-Toke

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

Re: [Dnsmasq-discuss] dnsmasq segfault

[Toke Høiland-Jørgensen]

I've hit this as well (but not the crash). https://bugs.archlinux.org/task/45485

-Toke

On 6 July 2015 20:04:13 CEST, Simon Kelley si...@thekelleys.org.uk wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

That works. The wrinkle is that you have to replace /etc/resolv.conf
with a dangling symlink, rather than using --resolv-file to make
dnsmasq look in some other place where you put a dangling symlink,
because the segfault comes from writing to a constant string.

Actually making this work with inotify, rather than generating an
error in this case, is more difficult. realpath() has unhelpful
semantics when there's a dangling symlink, and there doesn't seem to
be an equivalent that follows the the symlinks and tell you where the
last one points.

Cheers,

Simon.


On 06/07/15 14:24, Dave Reisner wrote:
 On Sun, Jul 05, 2015 at 10:44:24PM +0100, Simon Kelley wrote: This
 clearly a dnsmasq bug: it shouldn't segfault, but the description 
 relies of lots of other stuff which makes it difficult to work
 out what systemd is doing to provoke the problem. It there a way to
 find out how systemd is invoking dnsmasq (ie the command-line) and
 how it differs between the systemd-resolved stopped and
 systemd-resolvd started?
 
 
 Cheers,
 
 Simon.
 
 
 It should be simple enough to make /etc/resolv.conf a symlink to 
 nowhere, and start dnsmasq. Building from git, it produces a
 crash where the top frame is:
 
 #0  inotify_dnsmasq_init () at inotify.c:65 d = 0x5559b030
 /resolv.conf path = 0x5559b02c /etc/resolv.conf res =
 0x557ae428
 
 The likely reason /etc/resolv.conf is a symlink to nowhere is
 because it points to /run/systemd/resolve/resolv.conf, which is
 the real file with the resolver configuration. Ideally, dnsmasq
 should wait for the symlink to point to a regular file, or
 monitor the target of the symlink for existence. As a stop-gap
 measure, users can add an 'After' ordering on 
 'systemd-resolved.service' in dnsmasq.service. I don't consider
 this to be a real solution because systemd-resolved is just one
 instance of a daemon managing a resolv.conf file on tmpfs, which
 /etc/resolv.conf could point to.
 
 HTH, Dave
 
 
 On 05/07/15 20:17, R wrote:
 dnsmasq segfaults at boot and systemd fails to load the
 service. ( http://sysv.se/journal.txt ) after the boot
 process systemd can start dnsmasq successfully through
 'systemctl start dnsmasq' and everything works.
 
 This started happening after I switched from using netctl +
 dhcpcd to configure my interfaces to using systemd-networkd
 + systemd-resolved.
 
 I was able to reproduce the segfault after the system had
 started by stopping systemd-resolved. When systemd-resolved
 was stopped, 'systemctl start dnsmasq' again segfaulted.
 
 Starting systemd-resolved again, systemctl start dnsmasq
 worked without problems.
 
 I'm using dnsmasq - dnscrypt_proxy - opendns on latest Arch
 Linux fully updated as of the date of this message.
 
 
 
 ___
 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
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVmsMcAAoJEBXN2mrhkTWiy/gQAIeYEqixdyIdEbhXOS0vtQG3
BeEf6SquKS7R0ZId7Cf0fM+rZv7VZuy9Ze8k4326/QBfquSwY6qNqpi9v3KvRTRe
8Qwq9G7kJXowpkQXAyHgdOMAeOwXSG0SGLwPrsbcK5xx6HSVOYwQuf6qLboAbbuH
0N4Dx8vPvfIGx7D1nP28Z3sJPWJpTCMdU0wdBy+vtM4cPLj2MlZafW7lAvnvIcDe
FyMntbsWRDoMfjT5O5QUvXdBnAsz+7Vn2Yl/9z6e6xOoENHOId7dxdLyBCSLnOcH
MX+UUb5EsKUzIl4SZDgWXtdmF2jCWgJ5FPLtyWSt3elsan0SCgJoy/oo2BgzRMRO
ZefDzEtI5imO4A27q6nqT5U+sZKTdcnef/6pSnBBXOfvSbURJMFdQuYpuUFkzW7H
Yb95/M7aji9cb+Vs52kLMTzEdsYHiGFlxoTB2ZrCMzTd7o+ptwsThhXyDHTE508q
uSxQmmdKcf4C7PxMa9iwVXObZ6kNwU8bmzV3bBC7RFMeZTLe6F95mbnp9RUVUyOP
YixDZ14abLR3yrzIQ9cB2mUPqwG8W8fUqqkYT7x00fZb6ungvSnieRi9RB/npB+x
UiH58mBKVMmgmqwPFidWYj9p4K5J53Ra5r6MbnLcmBvv/zH4YvNwX9m2Yh+7BbpZ
GFcph+OaUwudnfBSzQ0k
=hGIW
-END PGP SIGNATURE-

___
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] DNSSEC failure with v2.73rc10

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk writes:

 Thanks Toke, finding these failure cases and fixing them, one at a
 time, is very necessary, but somewhat gruelling.

Yup, mapping out the DNS tree one corner case at a time. Appreciate the
effort, and glad I can help in a small way! :)

 The two CNAME domains are signed, but the eurovps.com isnt.

 Hence the result of the A query is not validatable, and check-unsigned
 has to prove that's OK, by showing that there's a secure denial of a DS
 record covering the query

Figured it probably had something to do with the transition from a
signed to an unsigned domain.

 The code got lost somewhere in the CNAMES when trying to prove
 non-existence of the DS. I've just checked in a fix, and it behaves
 now.

Cool, thanks a bunch!

-Toke

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

[Dnsmasq-discuss] DNSSEC failure with v2.73rc10

[Toke Høiland-Jørgensen]

So I'm getting getting DNSSEC failures when trying to lookup the domain
'database.srku.dk'.

'dnssec' and 'dnssec-check-unsigned' are both enabled in the dnsmasq config.

The relevant dnsmasq log with log-queries enabled:

Jun 11 17:56:35 gauss dnsmasq[29455]: query[A] database.srku.dk from 10.42.8.5
Jun 11 17:56:35 gauss dnsmasq[29455]: forwarded database.srku.dk to ::1
Jun 11 17:56:35 gauss dnsmasq[29455]: dnssec-query[DNSKEY] srku.dk to ::1
Jun 11 17:56:35 gauss dnsmasq[29455]: dnssec-query[DS] srku.dk to ::1
Jun 11 17:56:35 gauss dnsmasq[29455]: reply srku.dk is DS keytag 2083
Jun 11 17:56:35 gauss dnsmasq[29455]: reply srku.dk is DNSKEY keytag 37065
Jun 11 17:56:35 gauss dnsmasq[29455]: reply srku.dk is DNSKEY keytag 2083
Jun 11 17:56:35 gauss dnsmasq[29455]: dnssec-query[DNSKEY] studenterraad.dk to 
::1
Jun 11 17:56:35 gauss dnsmasq[29455]: dnssec-query[DS] studenterraad.dk to ::1
Jun 11 17:56:35 gauss dnsmasq[29455]: reply studenterraad.dk is DS keytag 12253
Jun 11 17:56:35 gauss dnsmasq[29455]: reply studenterraad.dk is DNSKEY keytag 
12253
Jun 11 17:56:35 gauss dnsmasq[29455]: reply studenterraad.dk is DNSKEY keytag 
36045
Jun 11 17:56:35 gauss dnsmasq[29455]: dnssec-query[DS] 
database.studenterraad.dk to ::1
Jun 11 17:56:35 gauss dnsmasq[29455]: reply database.studenterraad.dk is BOGUS 
DS
Jun 11 17:56:35 gauss dnsmasq[29455]: validation database.srku.dk is BOGUS
Jun 11 17:56:35 gauss dnsmasq[29455]: reply database.srku.dk is CNAME
Jun 11 17:56:35 gauss dnsmasq[29455]: reply database.studenterraad.dk is CNAME
Jun 11 17:56:35 gauss dnsmasq[29455]: reply web21.sd.eurovps.com is 
77.235.54.116

Trying the query with dig seems to work:

$ dig +trace +dnssec database.studenterraad.dk @8.8.8.8

;  DiG 9.9.2-P2  +trace +dnssec database.studenterraad.dk @8.8.8.8
;; global options: +cmd
.   3175IN  NS  l.root-servers.net.
.   3175IN  NS  j.root-servers.net.
.   3175IN  NS  c.root-servers.net.
.   3175IN  NS  f.root-servers.net.
.   3175IN  NS  g.root-servers.net.
.   3175IN  NS  b.root-servers.net.
.   3175IN  NS  k.root-servers.net.
.   3175IN  NS  d.root-servers.net.
.   3175IN  NS  i.root-servers.net.
.   3175IN  NS  a.root-servers.net.
.   3175IN  NS  e.root-servers.net.
.   3175IN  NS  m.root-servers.net.
.   3175IN  NS  h.root-servers.net.
.   3175IN  RRSIG   NS 8 0 518400 2015062017 
2015061016 48613 . AVDPr19HNLu7NCcaE0NEJA++XTWfAzXdPe6x0uPW7ejcE62PAUl/MfEo 
FGM6+ogRDYFT0X0qpMhLhaUNtsqJ3drCZfRnlt7yZk7uS6QWXokqDE7j 
A6iyVF1C148QV5cEndaGpv2L6yS16zF3JUSJBhCtflrnjvrYNUQb27Iy WO4=
;; Received 397 bytes from 8.8.8.8#53(8.8.8.8) in 21 ms

dk. 172800  IN  NS  b.nic.dk.
dk. 172800  IN  NS  a.nic.dk.
dk. 172800  IN  NS  l.nic.dk.
dk. 172800  IN  NS  c.nic.dk.
dk. 172800  IN  NS  s.nic.dk.
dk. 172800  IN  NS  p.nic.dk.
dk. 86400   IN  DS  61294 8 2 
7512ABC9F08F74085D4AEC9E7CC6DC402A689F146F9AAFDAE11FCE5D 3ADCA25E
dk. 86400   IN  RRSIG   DS 8 1 86400 2015062105 
2015061104 48613 . MdgBbP0CuPMGNATQrtCEetXyGNzpAyxOPHWgwRUynnAhDcE62A+V10KD 
YWzADm9HynztDvJXUOehr3sNU5GGKKpUMlI81x3qo8UliNH6MBfBNoaN 
kaKOjeCt4+KH13CsbII5If1a5knH1NqdXIr7YASsYpf4c8nMLlfcsHZP Hf8=
;; Received 569 bytes from 192.228.79.201#53(192.228.79.201) in 190 ms

studenterraad.dk.   86400   IN  NS  ns2.gratisdns.dk.
studenterraad.dk.   86400   IN  NS  ns4.gratisdns.dk.
studenterraad.dk.   86400   IN  NS  ns5.gratisdns.dk.
studenterraad.dk.   86400   IN  NS  ns1.gratisdns.dk.
studenterraad.dk.   86400   IN  NS  ns3.gratisdns.dk.
studenterraad.dk.   7200IN  DS  12253 5 1 
225802A8082D4C8E6FA9F494DDB3A2689809FA7D
studenterraad.dk.   7200IN  RRSIG   DS 8 2 7200 20150708024337 
20150610020313 1804 dk. 
v1N9I/nBESCEQ7Sakcz+eriU4uWF41DUGq9pubjcsYe8n6THEdfWp4ds 
PKLp1MSV9RalAyspdjxp84He9QloRx0KIkgCy3EZX6RlrdK8miyzzyo7 
7uNa5vzaJBNILz2V64H8dLqlk9fx3TBwQeAS6msZRdT4fV/VEs3STVMb 
xXVLj37+KgoehwtldZ3SgAr7fTJQYuGESsCH5YDwiCtU30h/Cen8SZFH 
YGW8BYazgBgG+fneRRluuPwHPrZBIpggq+Ump80uJWXLhduPEJ3gj8o4 
5jtKAbvDrlpo8Ai/kmcyFJdRgDzGIJzRpl5KFjdlhkX2BnqoaYG08PZT vIt6AA==
;; Received 672 bytes from 2001:678:78:42:ad::53#53(2001:678:78:42:ad::53) in 
36 ms

database.studenterraad.dk. 43200 IN CNAME   web21.sd.eurovps.com.
database.studenterraad.dk. 43200 IN RRSIG   CNAME 5 3 43200 20150711144201 

Re: [Dnsmasq-discuss] seeing www.ietf.org fail dnssec with dnsmasq rc7

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk writes:

 It's difficult to see how that would work in practise for DNS. Take
 the Google-public-DNS example. It's clearly not sane for Google's
 servers to do PMTU on the address of every client, just to send one
 UDP packet, and caching PMTU for clients is going to get hard, fast.
 If the reply-size is bigger than the PMTU what happens anyway?
 Presumably a truncated response, to force fallback to TCP.

Well, IPv6 also mandates a minimum PMTU of 1280 bytes. So a source host
that doesn't do PMTU discovery should either limit itself to 1280 bytes
packets or fragment at the source. Routers are not going to do it. See
https://tools.ietf.org/html/rfc2460#section-5 :)

 I guess it could work the other way around, and the client finds the
 PMTU to the server, and puts that in the EDNS0 max packet field. Are
 PMTU symetric?

I guess that would be reasonable. Or just be on the safe side and always
set the max packet field to 1280 bytes when querying over IPv6?

 In any case, good luck updating every stub resolver in the world to do
 this..

Well in theory the people updating those same stub resolvers to speak
IPv6 should pay attention to this, I guess. I'm not holding my breath,
though... :P

-Toke

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

Re: [Dnsmasq-discuss] seeing www.ietf.org fail dnssec with dnsmasq rc7

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk writes:

 Using ping6 2001:4860:4860:: -s packet size

 (that's the Google public DNS server)

 I see answers up to packet size 1344.

I get answers up to -s 1432. This is on an he.net tunnel.

-Toke

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

Re: [Dnsmasq-discuss] seeing www.ietf.org fail dnssec with dnsmasq rc7

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk writes:

 But if they fragment, what size should they fragment to? I guess inthe
 absence of any information to the contrary, 1280 bytes.

Yes, I would think so. Also, the RFC has this to say about the size of
the packets pre-fragmentation:

   A node must be able to accept a fragmented packet that, after
   reassembly, is as large as 1500 octets.  A node is permitted to
   accept fragmented packets that reassemble to more than 1500 octets.
   An upper-layer protocol or application that depends on IPv6
   fragmentation to send packets larger than the MTU of a path should
   not send packets larger than 1500 octets unless it has assurance that
   the destination is capable of reassembling packets of that larger
   size.

So I don't see much hope for that 1625 byte 'DNSKEY org' answer...

 I wonder if the Google public DNS is failing to do that, or if it is,
 and the path to me is dropping fragments?

No idea. I figure they probably do whatever Linux does?

-Toke

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

Re: [Dnsmasq-discuss] seeing www.ietf.org fail dnssec with dnsmasq rc7

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk writes:

 The MTU if the SIXXs IPv6 network interface is 1428. Failure to
 receive UDP packets larger than the MTU is a bigger bug than DNS, but
 I don't know if it's a SIXXS problem or a wider IPv6 one.

Well, IPv6 doesn't fragment packets; hosts are supposed to do PMTU
discovery and transmit at the MTU that works end-to-end. I've found this
to be broken way too often for comfort... Even encountered operators who
just told me to increase the MTU at my end rather than fix their
discovery mechanism (though this was when I was running with the minimum
1280 MTU and they were doing ethernet max-sized packets).

-Toke

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

Re: [Dnsmasq-discuss] Dnsmasq stops resolving addresses after return from suspend and wlan re-assoc

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk writes:

 Try git now. realpath() is my friend.

Seems to work; I get the expected bunch of reloads of the file upon
returning from suspend, picking up the right nameserver once it appears.

Thanks a bunch! :)

-Toke

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

Re: [Dnsmasq-discuss] Dnsmasq stops resolving addresses after return from suspend and wlan re-assoc

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk writes:

 I just pushed code into git which uses inotify to track changes.
 Dnsmasq should now re-read the file whenever it is closed after being
 open for write, or when it's moved into the parent directory.

 I'm pretty sure (unless I've done it wrong) that this will fix your
 problem. Please could you try it?

Hmm, the problem remains even with the inotify patch. This is what I see
in my syslog after a return from suspend:

Dec 12 08:05:04 alrua-x1 kernel: wlan0: associated
Dec 12 08:05:06 alrua-x1 wpa_actiond[2303]: Interface 'wlan0' reestablished 
connection to network 'tohojo'
Dec 12 08:05:06 alrua-x1 systemd-networkd[1841]: wlan0   : gained 
carrier
Dec 12 08:05:06 alrua-x1 systemd-networkd[1841]: wlan0   : DHCPv4 
address 10.42.8.59/27 via 10.42.8.33
Dec 12 08:05:06 alrua-x1 avahi-daemon[2720]: Joining mDNS multicast group on 
interface wlan0.IPv4 with address 10.42.8.59.
Dec 12 08:05:06 alrua-x1 dnsmasq[5465]: reading /etc/dnsmasq-resolv.conf
Dec 12 08:05:06 alrua-x1 avahi-daemon[2720]: New relevant interface wlan0.IPv4 
for mDNS.
Dec 12 08:05:06 alrua-x1 avahi-daemon[2720]: Registering new address record for 
10.42.8.59 on wlan0.IPv4.
Dec 12 08:05:06 alrua-x1 dnsmasq[5465]: ignoring nameserver 127.0.0.1 - local 
interface

Looking at the file:

$ cat /etc/dnsmasq-resolv.conf 
# This file is managed by systemd-resolved(8). Do not edit.
#
# Third party programs must not access this file directly, but
# only through the symlink at /etc/resolv.conf. To manage
# resolv.conf(5) in a different way, replace the symlink by a
# static file or a different symlink.

nameserver 127.0.0.1
nameserver 10.42.8.33


I'm guessing it might have something to do with this:

$ ls -l /etc/dnsmasq-resolv.conf 
4,0K lrwxrwxrwx 1 root root 32 Jun 26 18:19 /etc/dnsmasq-resolv.conf - 
/run/systemd/resolve/resolv.conf

Changing the dnsmasq conf to point to /run/systemd/resolve/resolv.conf
directly, things seem to work right; I see seven reloads of the file
after returning from suspend, the last one picking up the right
nameserver...

Maybe dnsmasq should resolve symlinks before setting up the inotify?

-Toke

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

Re: [Dnsmasq-discuss] Dnsmasq stops resolving addresses after return from suspend and wlan re-assoc

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk writes:

 That sounds sensible, I shall continue my tour around the farther
 reaches of the Unix file API. Later

Great, thanks! I'll use the direct path in the meantime :)

-Toke

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

Re: [Dnsmasq-discuss] Dnsmasq stops resolving addresses after return from suspend and wlan re-assoc

[Toke Høiland-Jørgensen]

Friendly bump on this? :)

-Toke

 I've been bothered for a while that my laptop (which runs a local
 dnsmasq instance for caching) stops resolving names after returning from
 suspend, and sometimes spontaneously as well. Restarting dnsmasq would
 always fix this.

 It finally started bothering me enough to debug it, and what I think
 happens is something like this:

 - Dnsmasq is configured to use the resolv.conf file maintained by
   systemd-resolved, the nameserver manager component of
   systemd-networkd. This file is updated whenever nameservers change
   from DHCP or configuration.

 - Sometimes, it seems, systemd-resolved rewrites this file twice within
   a fairly short time; once empty and again shortly after with the right
   nameservers. Dnsmasq only picks up the first rewrite:

 Oct 19 19:44:50 alrua-x1 dnsmasq[30391]: reading /etc/dnsmasq-resolv.conf
 Oct 19 19:44:50 alrua-x1 dnsmasq[30391]: ignoring nameserver 127.0.0.1 - 
 local interface

 But subsequently touching the file makes dnsmasq pick up on the change
 and name resolution works again:

 Oct 19 19:49:30 alrua-x1 sudo[2104]: alrua : TTY=pts/4 ; PWD=/home/alrua ; 
 USER=root ; COMMAND=/usr/bin/touch /run/systemd/resolve/resolv.conf
 Oct 19 19:49:30 alrua-x1 sudo[2104]: pam_unix(sudo:session): session opened 
 for user root by (uid=0)
 Oct 19 19:49:30 alrua-x1 sudo[2104]: pam_unix(sudo:session): session closed 
 for user root
 Oct 19 19:49:33 alrua-x1 dnsmasq[30391]: reading /etc/dnsmasq-resolv.conf
 Oct 19 19:49:33 alrua-x1 dnsmasq[30391]: ignoring nameserver 127.0.0.1 - 
 local interface
 Oct 19 19:49:33 alrua-x1 dnsmasq[30391]: using nameserver 10.61.32.1#53
 Oct 19 19:49:33 alrua-x1 dnsmasq[30391]: using nameserver 1.1.1.1#53

 Oddly enough, when first connecting to a network, there's a delay
 between the two writes of the resolv-file, which means things work:

 Oct 19 20:05:59 alrua-x1 systemd-networkd[960]: wlan0   : gained 
 carrier
 Oct 19 20:05:59 alrua-x1 systemd-networkd[960]: wlan0   : DHCPv4 
 address 10.71.0.250/20 via 10.71.0.1
 Oct 19 20:05:59 alrua-x1 dnsmasq[22661]: reading /etc/dnsmasq-resolv.conf
 Oct 19 20:05:59 alrua-x1 dnsmasq[22661]: ignoring nameserver 127.0.0.1 - 
 local interface
 Oct 19 20:06:03 alrua-x1 dnsmasq[22661]: reading /etc/dnsmasq-resolv.conf
 Oct 19 20:06:03 alrua-x1 dnsmasq[22661]: ignoring nameserver 127.0.0.1 - 
 local interface
 Oct 19 20:06:03 alrua-x1 dnsmasq[22661]: using nameserver 10.61.32.1#53
 Oct 19 20:06:03 alrua-x1 dnsmasq[22661]: using nameserver 1.1.1.1#53

 Either way, fixing dnsmasq to always notice the updated files would be
 desirable. Not sure if the recently posted nanosecond resolution patch
 is the way to go about it, but consider this a motivation to do
 *something* :)

 -Toke

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

[Dnsmasq-discuss] Dnsmasq stops resolving addresses after return from suspend and wlan re-assoc

[Toke Høiland-Jørgensen]

I've been bothered for a while that my laptop (which runs a local
dnsmasq instance for caching) stops resolving names after returning from
suspend, and sometimes spontaneously as well. Restarting dnsmasq would
always fix this.

It finally started bothering me enough to debug it, and what I think
happens is something like this:

- Dnsmasq is configured to use the resolv.conf file maintained by
  systemd-resolved, the nameserver manager component of
  systemd-networkd. This file is updated whenever nameservers change
  from DHCP or configuration.

- Sometimes, it seems, systemd-resolved rewrites this file twice within
  a fairly short time; once empty and again shortly after with the right
  nameservers. Dnsmasq only picks up the first rewrite:

Oct 19 19:44:50 alrua-x1 dnsmasq[30391]: reading /etc/dnsmasq-resolv.conf
Oct 19 19:44:50 alrua-x1 dnsmasq[30391]: ignoring nameserver 127.0.0.1 - local 
interface

But subsequently touching the file makes dnsmasq pick up on the change
and name resolution works again:

Oct 19 19:49:30 alrua-x1 sudo[2104]: alrua : TTY=pts/4 ; PWD=/home/alrua ; 
USER=root ; COMMAND=/usr/bin/touch /run/systemd/resolve/resolv.conf
Oct 19 19:49:30 alrua-x1 sudo[2104]: pam_unix(sudo:session): session opened for 
user root by (uid=0)
Oct 19 19:49:30 alrua-x1 sudo[2104]: pam_unix(sudo:session): session closed for 
user root
Oct 19 19:49:33 alrua-x1 dnsmasq[30391]: reading /etc/dnsmasq-resolv.conf
Oct 19 19:49:33 alrua-x1 dnsmasq[30391]: ignoring nameserver 127.0.0.1 - local 
interface
Oct 19 19:49:33 alrua-x1 dnsmasq[30391]: using nameserver 10.61.32.1#53
Oct 19 19:49:33 alrua-x1 dnsmasq[30391]: using nameserver 1.1.1.1#53


Oddly enough, when first connecting to a network, there's a delay
between the two writes of the resolv-file, which means things work:

Oct 19 20:05:59 alrua-x1 systemd-networkd[960]: wlan0   : gained carrier
Oct 19 20:05:59 alrua-x1 systemd-networkd[960]: wlan0   : DHCPv4 
address 10.71.0.250/20 via 10.71.0.1
Oct 19 20:05:59 alrua-x1 dnsmasq[22661]: reading /etc/dnsmasq-resolv.conf
Oct 19 20:05:59 alrua-x1 dnsmasq[22661]: ignoring nameserver 127.0.0.1 - local 
interface
Oct 19 20:06:03 alrua-x1 dnsmasq[22661]: reading /etc/dnsmasq-resolv.conf
Oct 19 20:06:03 alrua-x1 dnsmasq[22661]: ignoring nameserver 127.0.0.1 - local 
interface
Oct 19 20:06:03 alrua-x1 dnsmasq[22661]: using nameserver 10.61.32.1#53
Oct 19 20:06:03 alrua-x1 dnsmasq[22661]: using nameserver 1.1.1.1#53


Either way, fixing dnsmasq to always notice the updated files would be
desirable. Not sure if the recently posted nanosecond resolution patch
is the way to go about it, but consider this a motivation to do
*something* :)

-Toke

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

Re: [Dnsmasq-discuss] Announce: dnsmasq-2.69rc1

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk writes:

 Note that you may want to add --dnssec-check-unsigned to the
 configuration. That will cause dnsmasq to ensure that unsigned replies
 are legit by ensuring that there exists secure denial of existence of
 a DS record somewhere on the path from the DNS root to the domain.
 That should be added to the example config file before the final
 release.

It's also missing from the man page in the rc... :)

-Toke


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

Re: [Dnsmasq-discuss] Announce: dnsmasq-2.69rc1

[Toke Høiland-Jørgensen]

 Hmm, Debian has a useful character, '~' which sorts after everything
 else, and the packaging scripts turn 2.69test1 into 2.69~~test1 and
 2.69rc1 into 2.69~rc1 to avoid this problem. Does the same facility
 exist in Arch?

No idea; pretty sure it doesn't have a way to do it automatically, at
least. Could be wrong, though.

 Good point. I have a well-known GPG key (not massively signed, but
 with some web-of-trust support, and in the Debian keyring). I'll
 organise to sign releases with that. The test and rc releases will
 probably be signed with a different key (signed in turn with the one
 above) since they are made automatically with git hooks, so the key
 will need to be on the git server and not have a passphrase.

 DNSSEC for thekelleys.org.uk should be possible too: looks like my
 registrar supports it.

Sounds good! :)

-Toke


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

Re: [Dnsmasq-discuss] Subnet specifications for authoritative dns

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk
writes:

 Try 2.67test6. The documentation changes are bigger than the code
 changes :-)

Works great for IPv4. Thanks!

However, I'm seeing some IPv6 records that shouldn't be there. I.e. I
have 2001:::1::/64, 2001:::3::/64 and
2001:::4::/64 in auth-zone but am seeing addresses in
2001:::: show up in auth DNS and zone transfers?

I've previously had 2001::::/48 configured, which would of
course include them; is it possible that the old records have not been
flushed after a config change?

-Toke


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

Re: [Dnsmasq-discuss] Subnet specifications for authoritative dns

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk
writes:

 The zone-transfer refresh time is set to 1200 seconds, so it's quite
 possible that the old records could be hanging around in your
 secondaries. If you can get an old record from a query direct to
 dnsmasq, then there's something wrong.

Right. Well I do get an IPv6 reply directly from dnsmasq, and the
updated zone transfer to the secondary server has the A records removed
as expected, but still retains the  records...

-Toke


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

Re: [Dnsmasq-discuss] Subnet specifications for authoritative dns

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk
writes:

 Are you using constructed DHCP ranges for IPv6? There's an exception for them
 from the auth-zone subnet filtering.

Yep: dhcp-range=::1,::400,constructor:gw00,ra-names,ra-stateless

Why the exception? :)

-Toke


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

Re: [Dnsmasq-discuss] Subnet specifications for authoritative dns

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk
writes:

 Because the actual prefix is not known in advance, so can't be put in
 the auth-zone configuration. The only way to export such a prefix is
 to assume that all such prefixes are exportable, at least at the
 moment.

Right, because prefixes can come and go over the lifetime of a dnsmasq
instance?

So if I put in the prefix manually, it should filter it out?

-Toke


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

Re: [Dnsmasq-discuss] Subnet specifications for authoritative dns

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk
writes:

 In your case, to delegate 192.168.1.0-127 or 192.168.1.128-255 isn't
 possible using this scheme. There is a workaround involving CNAMES,
 but it's complicated for a simple-to-setup scheme, which is what
 dnsmasq is trying to provide.

Right, well basically what I'm trying to achieve is for dnsmasq to still
provide the (reverse) DNS service for the whole /24 subnet internally,
but to filter out the addresses in the upper /25 and not answer those in
queries on the authoritative interface (and exclude them from zone
transfer also). It's not critically important, it just irks me to
provide random people on the guest network with global DNS entries in my
namespace, even if it's only for RFC1918 addresses... :)

-Toke


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

Re: [Dnsmasq-discuss] Subnet specifications for authoritative dns

[Toke Høiland-Jørgensen]

/dev/rob0 r...@gmx.co.uk writes:

 Then perhaps your simple solution is a little bit of network
 restructuring to replace your /24 with a /23 and your /25 with a /24?
 RFC1918 gives us lots of room; stretch out and enjoy some of it. :)

Yeah, considered that. But right now I'm using a separate /24 for each
physical site (VPN'ed together), and the first three octets being the
mnemonic for the physical site is kinda nice. Also, restructuring all
the networks would be too much hassle for what is really a 'nice to
have' thing... If implementing filtering is too much hassle, I can live
with a bit of DNS pollution, just thought I'd ask... :)

-Toke


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

Re: [Dnsmasq-discuss] Subnet specifications for authoritative dns

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk
writes:

 For reverse queries, it would be necessary to be authoritative for the
 whole of (eg) 1.168.192.in-addr.arpa, but we could easily return
 NXDOMAIN for addresses not in a (smaller) subnet.

Yeah, it's something like this I'm looking for. :)

-Toke


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

[Dnsmasq-discuss] Subnet specifications for authoritative dns

[Toke Høiland-Jørgensen]

Hi

What's the rationale behind limiting subnet definitions in auth-zone to
(for IPv4) /8, /16 and /24?

I'd like to limit the hosts that show up in authoritative DNS to a
smaller subnet (/25 in this case), to prevent hosts on my guest network
From being globally named.

-Toke


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

Re: [Dnsmasq-discuss] Authoritative and regular DNS on same interface

[Toke Høiland-Jørgensen]

Simon Kelley si...@thekelleys.org.uk
writes:

 You _can_ specify auth-server per IP address

 --auth-server=example.com,192.168.1.1

Ah, neat. And it's even in the man page; bugger my reading comprehension
skills... :P

 Is that the solution to your problem, or have I missed something?

Indeed it is; thanks a bunch! :)

-Toke


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