Re: [Dnsmasq-discuss] dnsmasq 2.90 reply truncated
___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss -- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Implement --no-dns-interface?
Hi, as a workaround you can do something like this: Let the alternative DNS server run on another port, like 1053. Then for all vlan interfaces that should use the alternative server include a PREROUTING iptables rule to redirect the post just on those interfaces to port 1053. DNS will announce itsself on the DHCP, but as the packets get redirected before they reach dnsmasq, the alternative server takes over. This will redirect port 53 on interfac|e "||vlanintf|" to port 1053 on same interface for UDP and TCP (some DNS packets go via TCP, too). It has rules for both IPv6 and IPv4: |iptables -A PREROUTING -t nat -i vlanintf -p udp --dport 53 -j REDIRECT --to-port 1053 ||iptables -A PREROUTING -t nat -i |||vlanintf |-p tcp --dport 53 -j REDIRECT --to-port 1053| |ip6tables -A PREROUTING -t nat -i |||vlanintf |-p udp --dport 53 -j REDIRECT --to-port 1053| |ip6tables -A PREROUTING -t nat -i |||vlanintf |-p tcp --dport 53 -j REDIRECT --to-port 1053| Hope that helps, Uwe || Am 21.04.2023 um 03:18 schrieb Tony Zhou: Hi, I am running dnsmasq 2.86 on openwrt, and have multiple vlans in my network. dnsmasq works great for dhcp purposes (for both dynamic and static leases) that I need for all interfaces/vlans. However, some of the vlans I do not need/want to have dnsmasq providing dns, but another dns server for content filtering purposes. I'd prefer to keep both dns servers on the same host/router, but the way dnsmasq works, either binding to interfaces, or wildcard, binds to all port 53, so that the 2nd dns server can't bind. It appears that when dnsmasq is set to bind to interfaces, it has to either offer both dns and dhcp, or skip dhcp by "--no-dhcp-interface" argument, but there is no counterpart "--no-dns-interface". Setting port=0 disables dns service on all interfaces, which is not what I wanted as well. I did found there were two discussions regarding this: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2011q4/005335.html https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q3/015429.html Running two instances of dnsmasq doesn't resolve this issue, since I still rely on dnsmasq's dhcp. Thanks. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss -- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail:u...@thetaphi.de ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Where does dnsmasq get upstream DNS servers by default?
Hi Chris However this brings me back to where my original question came from, since there is no 'nameserver' entry pointing at localhost will dnsmasq cache? Or do I have to manually add a 'nameserver 127.0.0.1' somewhere? Dnsmasq will cache for requests coming from localhost (like local tools, ssh,...) and also from other devices on your local network. Local programs on same machine like SSH, browsers, webservers, mailservers,... work because of your /etc/resolv.conf file: It points to dnsmasq. Dnsmasq caches and forwards unknown requests to the server provided by NetworkManager (which does similar stuff like resolvconf package). Somebody should change the /etc/default/dnsmasq comment and say "resolvconf or NetworkManager"). Uwe Am 29.05.2022 um 16:18 schrieb Chris Green: With the default /etc/default/dnsmasq file on Ubuntu it says:- # If the resolvconf package is installed, dnsmasq will use its output # rather than the contents of /etc/resolv.conf to find upstream # nameservers. Uncommenting this line inhibits this behaviour. # Note that including a "resolv-file=" line in # /etc/dnsmasq.conf is not enough to override resolvconf if it is # installed: the line below must be uncommented. #IGNORE_RESOLVCONF=yes I'm pretty sure I don't have resolvconf (or openresolv) so, in this case how does dnsmasq find the upstream servers. /etc/resolv.conf is :- # Generated by resolvconf nameserver 127.0.0.1 search zbmc.eu Which is a bit odd since I don't have resolvconf. The system works OK, DNS works, but I'd like to know how. -- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss -- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Where does dnsmasq get upstream DNS servers by default?
Hi, /etc/resolv.conf may have this header, because at some point resolvconf was installed on your system. If resolvconf is (or was) installed, the main /etc/resolv.conf file is a symlink to some autogenerated file (/run/resolvconf/resolv.conf). This autogenerated file is created because resolvconf wants all local apps (except) dnsmasq to use dnsmasq as DNS server. It is NOT used as upstream server by dnsmasq, it is for downstream programs on local machine (like ssh, mail server,...). Plain simple? So in short, your /etc/resolv.conf is correct. If you dont have resolvconf package installed (check with 'dpkg -l | grep resolv') it is a relic, but the contents are correct. The upstream resolver used by dnsmasq is also maintained by resolvconf (if enabled) and passed via command line. It is also in the /run/resolvconf folder. If you don't have resolvconf pkg installed, you HAVE TO add your own "resolv-file=" or "server=ip" to dnsmasq config file, otherwise it won't work. There's no default on Ubuntu. Uwe Am 29.05.2022 um 16:18 schrieb Chris Green: With the default /etc/default/dnsmasq file on Ubuntu it says:- # If the resolvconf package is installed, dnsmasq will use its output # rather than the contents of /etc/resolv.conf to find upstream # nameservers. Uncommenting this line inhibits this behaviour. # Note that including a "resolv-file=" line in # /etc/dnsmasq.conf is not enough to override resolvconf if it is # installed: the line below must be uncommented. #IGNORE_RESOLVCONF=yes I'm pretty sure I don't have resolvconf (or openresolv) so, in this case how does dnsmasq find the upstream servers. /etc/resolv.conf is :- # Generated by resolvconf nameserver 127.0.0.1 search zbmc.eu Which is a bit odd since I don't have resolvconf. The system works OK, DNS works, but I'd like to know how. -- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Prefix delegation with DNSmasq
Hi, although this is no longer fully related to dnsmasq, just a few sentences on top: > >> There's a slightly more special case for us: We have one central firewall > (which > >> gets the full /56 net on the upstream interface routed to it) and most > gateways > >> are separate nodes > >> (i.e. most VLANs are not connected to the central FW). > >> So I believe in that case I just need an ip6tables rule (per /64 subnet) > >> on the > >> central firewall to redirect all traffic to the gateway for the /64 subnet, > right? > > > > It's important to don't have the /56 or /64 network assigned to an interface > on the router (otherwise you would need proxyNDP)! > > Noted. Indeed, that's reasonable, and achieved by design for those VLANs not > connected to the central router ;-). > > > If it's prefix delegation, don't assign the 64 or 54 subnet to any > > interface on > the main router, just bring interfaces up and assign link-local-addresses to > them! On the central firewall just do routing with link-local addresses > (basically, this subnet goes to this adaptor and this mac address - as link > local > addresses are basically MAC addresses). Of course the packet filtering uses > the > global addresses, but the routing is done with link-local. > > > > The router box gets the packets from the provider all delegated to its own > link-local address of the upstream interface (that's what most providers do, > including DSL providers with PPP or servers in data centers like Hetzner). So > all > incoming packets are sent to the same fe80: address based on the MAC > known to upstream or negotiated via PPP and the router just forwards them > based on the global address inside of the packets. > > In our case, they waste a dedicated /64 global address network for the > connection network between our firewall and their endpoint... That also works, > but it's rather wasteful of course ;-). That's not so bad, because you get a global IPv6 address on the upstream router, so it can appear on traceroutes (see below). So that's not too bad. If you won't have that, to correctly make the router inbetween appear in traceroutes, you would have to assign some other IPv6 from another /64 subnet. Now you have that one on the upstream interface, the router can respond with ICMPv6 messages as reply on traceroute or unroutable addresses. Otherwise the response from e.g., traceroute would get lost. > > In the routing table of the main firewall you just add entries like global > subnetA/64 goes to link-local address fe80: on interface XY, and so on. If > you don't like the automatic assigned link-local-addresses based on the mac > interface you can easily change them. In my office I have the router assigned > fe80::1, you could assign fe80::2, fe80::3 to the secondary routers's network > interfaces and then routing tables look easy: > > > > 2001:abcd:1234:1::/64 => fe80::2@en1 > > 2001:abcd:1234:2::/64 => fe80::3@en1 > > 2001:abcd:1234:3::/64 => fe80::4@en1.24 (a VLAN #24 on en1) > > 2001:abcd:1234:3::/64 => fe80::4@en2 (other network interface) > > > > Fe80::2, 3, 4 are the separate boxes which route the traffic and have the > dnsmasq. If you don't want to use fe80 link-local addresses, you can use ULAs, > but for routing purposes the link-local ones with interface name are the > easiest. > > Thanks, that example clarified it for me. Good thinking in using the > link-local > addresses here, that's completely sufficient. It really helps to talk about > these > things to clear up my mind from the IPv4 legacy of thinking. This is generally known as "next-hop routing". A router just gives the correct link-local address, so the packet with a global address can get closer to its target. This makes routing tables easy to maintain. The general recommendation is to always only use link-local addresses in routing tables (because otherwise the router would need to send NDP packets on its own, just to find the next-hop target! Nevertheless, each router should have a global address, too (so it can be pinged). You can assign it to the interface with the corresponding prefix. On the upstream router / firewall it would be the one from the "wasted network" (see above); on the client-facing router one from the target /64 network (2001:xx::1). Between upstream router and client facing routers, only link-local addresses are used. > > Another idea is to use one of the /64 subnets as the "inter-router" > communication, but that's not needed for IPv6, because we have link-local- > addresses for that purpose! As noted before, nevertheless all nodes on the route *should* have a global address, too (but those should not be used in the routing table). The global/routeable address is needed to transfer ICMPv6 messages. The router can't otherwise be pinged by traceroute or tell the client that a route is not working via ICMP. > > On the internal routers you only assign the full global 64 subnet to the > > client >
Re: [Dnsmasq-discuss] Prefix delegation with DNSmasq
Hi, > thanks for the elaborate reply! No problem! > There's a slightly more special case for us: We have one central firewall > (which > gets the full /56 net on the upstream interface routed to it) and most > gateways > are separate nodes > (i.e. most VLANs are not connected to the central FW). > So I believe in that case I just need an ip6tables rule (per /64 subnet) on > the > central firewall to redirect all traffic to the gateway for the /64 subnet, > right? It's important to don't have the /56 or /64 network assigned to an interface on the router (otherwise you would need proxyNDP)! If it's prefix delegation, don't assign the 64 or 54 subnet to any interface on the main router, just bring interfaces up and assign link-local-addresses to them! On the central firewall just do routing with link-local addresses (basically, this subnet goes to this adaptor and this mac address - as link local addresses are basically MAC addresses). Of course the packet filtering uses the global addresses, but the routing is done with link-local. The router box gets the packets from the provider all delegated to its own link-local address of the upstream interface (that's what most providers do, including DSL providers with PPP or servers in data centers like Hetzner). So all incoming packets are sent to the same fe80: address based on the MAC known to upstream or negotiated via PPP and the router just forwards them based on the global address inside of the packets. In the routing table of the main firewall you just add entries like global subnetA/64 goes to link-local address fe80: on interface XY, and so on. If you don't like the automatic assigned link-local-addresses based on the mac interface you can easily change them. In my office I have the router assigned fe80::1, you could assign fe80::2, fe80::3 to the secondary routers's network interfaces and then routing tables look easy: 2001:abcd:1234:1::/64 => fe80::2@en1 2001:abcd:1234:2::/64 => fe80::3@en1 2001:abcd:1234:3::/64 => fe80::4@en1.24 (a VLAN #24 on en1) 2001:abcd:1234:3::/64 => fe80::4@en2 (other network interface) Fe80::2, 3, 4 are the separate boxes which route the traffic and have the dnsmasq. If you don't want to use fe80 link-local addresses, you can use ULAs, but for routing purposes the link-local ones with interface name are the easiest. Another idea is to use one of the /64 subnets as the "inter-router" communication, but that's not needed for IPv6, because we have link-local-addresses for that purpose! On the internal routers you only assign the full global 64 subnet to the client facing network adaptors. The connection to the router uses a link-local address only (as described before). No additional firewalling is needed, you just need to setup routing entries like above (the other way round). > > Just some recommendation: I'd NOT go with DHCPv6, as no Chromebook or > Android device supports it. I'd go for SLAAC. Very easy. As you can setup a > separate /64 subnet (up to 256 of them), you have enough flexibility to handle > all of them in a separate network with full /64 SLAAC address space. Each of > those networks have firewalling on the router box and are delegate to the > network switch .e.g, via VLANs. > > I know (while I knew about Android, good point about the Chromebooks!). Our > main usecase is addressing of Linux servers (i.e. there will only be "DHCP > reserved" entries). > Indeed, for a general purpose network (one of those /64s), we need to think > whether we'll go with DHCPv6 (and lose Android and Chromebooks) or really > stay with DHCPv6. For now, I'll plan with DHCPv6 ;-). No problem. You can have both, depending on subnet. Uwe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Prefix delegation with DNSmasq
Hi > I have a setup in mind and wonder whether dnsmasq is the correct tool (since I > have not found the necessary functionality in the documentation yet). > > We have a /56 IPv6 network, and plan to use pure DHCPv6 (no stateless > autoconfiguration) in several /64 networks. That's perfect. Looks much like a standard German DSL account. > There are several subnets (currently NATed IPv4), such as — for example — a > WireGuard VPN network, or a local isolated subnet. > While with IPv4, the answer was the use of private addresses and NAT every > time, potentially using a DHCP fowarder, for IPv6, the answer should be to use > Global Unicast addresses everywhere (right?). > How do I approach this correctly? That's very easy because you have a /56 net. > Three options come to mind to handle such subnets: > - Use ULAs and NAT (but that does not feel like IPv6...). No no no, bad idea and very stupid for such a large network. > - Delegate a prefix from the large network (where we'd use dnsmasq) to the > "gateway" machine, which then would be a router. > However, I am not aware if dnsmasq can delegate prefixes? This should all be done on the central router. For each subnet you have a separate dnsmasq. > - Use ProxyNDP (via npdpd or Linux kernel functionality). But I'm not sure if > that scales well to a larger number of machines? No need to do that (see below). ProxyNDP is only needed if you want delegate some global addresses to devices that are in the same subnet but behind another machine (MAC address). You don't need this. All can be done with plain simple routing. > - Use static routes on the central machine which send the /64 subnet to the > "gateways" and use dnsmasq on the gateways. That's the way to go and it will just work! Explanation: The provider delegates a /56 prefix to you. How this is done depends, but for DSL (dynamic) or also at Hetzner (static) the whole thing works on the link level addresses. For DSL you have the PPP-Daemon wo gets a link local address on the end point assigned. For DSL you get a prefix delegated using DHCP-PD (prefix delegation), for static roulds (e.g., Hetzner) you get all traffic routed to the link-local address of your router (that's coming from the mac address of router known to provider). On the router you just assign the subnets and their primary address (:1) to a separate interface or VLAN in portions of /64. The linux kernel will then just automatically route all incoming packets from the WAN interface (PPP or Ethernet) to the correct (virtual) network adaptor. On each of those network adaptors you have a dnsmasq listening. Just some recommendation: I'd NOT go with DHCPv6, as no Chromebook or Android device supports it. I'd go for SLAAC. Very easy. As you can setup a separate /64 subnet (up to 256 of them), you have enough flexibility to handle all of them in a separate network with full /64 SLAAC address space. Each of those networks have firewalling on the router box and are delegate to the network switch .e.g, via VLANs. If you are interested how to setup the Prefix Delegation with PPP, just ask. The usual howtos seen on internet with wide-dhcpd are outdated and not very modern and relying on a broken tool which should not be used anymore. The correct way for that is "dhcpcd" client daemon listening on the PPP interface and waiting for DHCP-PD packets. The dhcpcd config file can then automatically split the delegated /56 network and assign it to various real/virtual interfaces each with a /64 subnet, where a separate dnsmasq is handling everything. No hacks needed, just plain routing on the bx (its enough to enable ip forwarding unless you want to firewall). All on a single box. I have set this up multiple times. Uwe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] How to prevent LAN DNS for remote guests
Hi, I think you should have 2 DNSMASQ instances running, one for each interface. So each one only registers their own known DHCP clients (I assume the DHCP is also different for both subnets) and also returns them. You just need to make DNSMASQ bind to the interfaces directly (see bind-interfaces) option. Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen <https://www.thetaphi.de> https://www.thetaphi.de eMail: u...@thetaphi.de From: Dnsmasq-discuss On Behalf Of Koos Pol Sent: Saturday, December 21, 2019 9:11 AM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: [Dnsmasq-discuss] How to prevent LAN DNS for remote guests Hi, I'm setting up my openwrt modem as an internet gateway for remote guests. The modem is running openvpn and dnsmasq. The guests arrive at their own interface (tun1 = openvpn) with a different subnet. Guest > LAN forwarding is disabled in the firewall for security reasons. However, once the guests have connected, dnsmasq will resolve the LAN for them. Although guests won't be able to connect to anything on the LAN (forwarding is off) they are still able to go on a fishing expedition thanks to DNS. I don't want to turn off DNS completely. So --except-interface=tun1 is not an option. So, for anything connecting to tun1, how can I enable DNS resolving the internet space, while preventing resolving my LAN? Thanks! Koos ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Why does dnsmasq append .home to a plain hostname?
Hi, The reason for this is a “default domain” entry in the Windows 7 laptop configuration, so it is sent by the client in the case of a missing domain. It was not added by dnsmasq, but by the Windows client. On the other hand, this still resolves, because you seem to also have a “domain = home” in your dnsmasq config, so the “mymovies” entry working also for the deafult domain on the dnsmasq side. As the windows device (using dnsmasq also for DHCP) gets the default domain by the above entry. I am not sure what your problem is, to me it looks like it’s configured correctly. If you want “.ncp” your preferred domain, set “domain = ncp” and only keep the first entry. Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de From: Dnsmasq-discuss On Behalf Of Sean Warner Sent: Tuesday, October 22, 2019 2:25 AM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: [Dnsmasq-discuss] Why does dnsmasq append .home to a plain hostname? Hello, I have these two lines in my /etc/dnsmasq.conf address=/mymovies/192.168.1.124 address=/mymovies.ncp/192.168.1.124 Dnsmasq is running on a Pi. Also on the same LAN is my Win 7 laptop. When I make this request from Chrome on the laptop… http://mymovies this is what I get in the dnsmasq log file: Oct 21 23:38:12 dnsmasq[19823]: query[A] mymovies.home from XX.XX.XXX.XXX Oct 21 23:38:12 dnsmasq[19823]: config mymovies.home is 192.168.1.124 However when I make this request from Chrome http://mymovies.ncp this is what I get in the dnsmasq log file: Oct 21 23:41:54 dnsmasq[19823]: query[A] mymovies.ncp from XX.XX.XXX.XXX Oct 21 23:41:54 dnsmasq[19823]: config mymovies.ncp is 192.168.1.124 Apologies if this is a really basic question, I am a beginner with dnsmasq. Why is .home appended to a hostname when it is just a plain simple word without any domain or tld? Thank you, Flex ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Ready for dnssec key signing key rollover on Oct 11?
Hi, by default in the Debian/Ubuntu package it looks like this: root@sirius:~# dpkg -l | fgrep dnsmasq ii dnsmasq 2.79-1all Small caching DNS proxy and DHCP/TFTP server ii dnsmasq-base 2.79-1 amd64Small caching DNS proxy and DHCP/TFTP server ii dnsmasq-utils 2.79-1 amd64Utilities for manipulating DHCP leases The new anchor was included long ago: root@sirius:~# cat /usr/share/dnsmasq-base/trust-anchors.conf # The root DNSSEC trust anchor, valid as at 10/02/2017 # Note that this is a DS record (ie a hash of the root Zone Signing Key) # If was downloaded from https://data.iana.org/root-anchors/root-anchors.xml trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D (this is shipped with the above mentioned “dnsmasq-base” package). In the default config file of dnsmasq, there is this line: root@sirius:/etc# cat dnsmasq.conf.dpkg-dist | fgrep trust #conf-file=%%PREFIX%%/share/dnsmasq/trust-anchors.conf So everything is there to configure it correctly. By default DNSSEC is not enabled anyways, but a user who wants to enable it can easily do it by uncommenting and fixing the above path. IMHO, it could be improved in the debian package to have the correct path in the default file (instead of %%PREFIX%%). This looks like a bug in the debian package installer. Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de <http://www.thetaphi.de/> eMail: u...@thetaphi.de From: Dnsmasq-discuss On Behalf Of Neil Jerram Sent: Monday, October 8, 2018 12:19 PM To: logana...@gmail.com Cc: dnsmasq-discuss Subject: Re: [Dnsmasq-discuss] Ready for dnssec key signing key rollover on Oct 11? On Sun, Oct 7, 2018 at 12:05 PM Loganaden Velvindron mailto:logana...@gmail.com> > wrote: On Sun, Oct 7, 2018 at 2:13 PM Rick Thomas mailto:rbtho...@pobox.com> > wrote: > > What do I need to do to be ready for the DNSSEC Root KSK (key signing key) > rollover on October 11, 2018? > Well, dnsmasq already commited a patch for the new trust anchor : http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=05da782f8f45933915af0ef3cc1ba35e31d20c59 I was also looking into this last week, and would appreciate if anyone wanted to review and confirm or correct my observations. If I've understood correctly: - An installation of dnsmasq can only possibly be impacted by the KSK rollover if it - was built with HAVE_DNSSEC enabled; AND - is configured (--dnssec) to use DNSSEC at runtime; AND - is actually used as a DNS server / forwarder. - There is no cross-dependency between DNSSEC and dnsmasq's DHCP and RA function. So if you're mainly using dnsmasq for DHCP and RA, as OpenStack does, that function can't be degraded by not having installed or configured the new DNSSEC KSK. - While it is true that the dnsmasq repo has included the new KSK fingerprint since February 2017 (as in the commit cited above), I couldn't see anything hardcoded in the dnsmasq code to read and use the content of trust-anchors.conf. So, even if you have that file in your dnsmasq install, and it includes the new KSK fingerprint, I _think_ you still need to configure dnsmasq somehow to read that file and trust the fingerprints in it (presumably at the same time as you'd configure --dnssec). Any comments much appreciated. Neil ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] clients of DHCPv6 with constructed IPv6 address range are not notified on address range change
Hi Simon, unfortunately that problem is seen often with providers in Germany, although the large ones no longer do it (or allow to disable the disconnect). The problem is that German providers automatically disconnect the PPPoE connection every 24 hrs. After reconnecting you get a new address (IPv4) and prefix (IPv6). Since the changes we did (deprecating prefixes) this works fine for standard router advertisements. But won't help for DHCPv6. My recommendation to the reporter: - Don't use stateful DHCPv6 in Germany, that does not work well. You clients should get the addresses using router advertisements. For static hosts assign static names in your own domain. The "ra-names" assigns both the IPv4 and IPv6 address to the SLAAC name, so lookup works fine. With router advertisements, DNSmasq will send "deprecated" prefixes for some time when it figures out that the prefix changed and sends the new prefix at the same time. This allows to have no interruption (except the forced PPP disconnect). In general, in IPv6 world you should forget about static addresses, it's also better for privacy. - Alternatively use a very short DHCPv6 lease time. E.g., if router advertisements last a maximum time of 30 minutes, also set the lease time to 30 minutes for IPv6. This requires clients to renew more often, but the change gots faster. If you force the router to disconnect during nights at a fixed time, the effect won't be so large. Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Dnsmasq-discuss > On Behalf Of Simon Kelley > Sent: Sunday, September 9, 2018 11:49 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] clients of DHCPv6 with constructed IPv6 > address range are not notified on address range change > > Dnsmasq doesn't implement RECONFIGURE. It probably should. The main > problem, from a quick look at the RFC, is that RECONFIGURE mandates use > of security mechanism, and dnsmasq doesn't implement that either! > > The intention is that address change is a gradual process. The old > address gets deprecated whilst the new one is added, and after a while > the old address disappears. DHCP lease times are shorter than the time > taken for an address to disappear. This gives time for hosts to move to > the new address. > > What's happening in your case seems a bit brutal. Even if you can push > the change to all the clients fast, you're still going to break every > on-going connection at address-change time. > > > Cheers, > > Simon. > > > > On 09/09/18 22:07, Andrey Vakhitov wrote: > > Thanks for a great dnsmasq software. > > > > > > > > I’m using dnsmasq 2.79 in combination with IPv6 prefix delegation. The > > prefixes are changing daily due to daily reconnect of upstream router. > > Dhcpcd is used to handle prefix delegation on external interface and > > apply new address to internal interface (dmz0). Dnsmasq picks up the > > prefix assigned to the internal interface by dhcpcd and server RA and > > DHCPv6 server. > > > > > > > > dhcp-range=set:dmz6,::,constructor:dmz0,ra-stateless,ra-names > > > > dhcp- > host=id:00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18,set:dmzfix6,[::56],dmzhos > t > > > > > > > > Initially the host gets IPv6 address via DHCPv6 correctly, DNS > > resolution works as expected, everything seems to be ok. But after > > reconnect (and according prefix change) the client stays with the IPv6 > > address from old prefix and doesn’t update it. I’ve used tcpdump to > > monitor DHCP-related traffic and could not see DHCPv6 RECONFIGURE > > message sent by dnsmasq to clients on prefix change. I assume that this > > is the cause of the problem: DHCP clients are not aware of changed > > prefix and can’t act without corresponding notification from server. > > > > As dhcp client I use build-in DHCP client from system-networkd, just for > > info, maybe it matters… > > > > > > > > If I’m wrong with my assumption I’d appreciate any explanation helping > > me to configure dnsmasq and DHCP client properly. > > > > > > > > Best regards, > > > > -- > > > > Andrey Vakhitov > > > > > > > > E-Mail: and...@vakhitov.net <mailto:and...@vakhitov.net> > > Stuttgart, Germany > > > > > > > > > > > > ___ > > 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 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] CERT Vulnerability VU#598349
Hey, > > The question is, should the above configuration be "baked in" to the code? > > As I understand, this vulnerability arises from the Web Proxy Automatic > Discovery (WPAD) protocol, not from dnsmasq itself. And, dnsmasq > configuration provides - or will provide - a configuration mechanism to > obviate the shortcomings of the WPAD protocol. My inclination would be to > *not* change the code, on the off-chance that someone might consider this > specific function of the WPAD protocol to be a "feature", and instead, to rely > upon the proper dnsmasq configuration, which would make overt to the > network administrator just how the "wpad" sub-domain is being handled. > And then, for instance, as you say, > dhcp-name-match=set:wpad-ignore,wpad > dhcp-ignore-names=tag:wpad-ignore > could be recommended in the default dnsmasq configuration file. > > Also, the CERT note says "Other autodiscovery names, such as, ISATAP, > autodiscovery and autoconf may also be exploitable." And dnsmasq could > be playing "wack-a-mole" with sub-domain names in the code, if handled > that way. It's easier to play "wack-a-mole" from the configuration file. I fully agree with this. IMHO, the new 2.80 config settings for name matches to ignore should maybe added to default config. dhcp-name-match=set:wpad-ignore,wpad dhcp-ignore-names=tag:wpad-ignore By the way, I'd also like to "ignore" the name "localhost", as exposed by Samsung SmartTVs. This is annoying, as it registers "localhost" as a domain name. It should just ignore that hostname, if provided by the DHCP client. If the above option helps to provide this "ignores", then we can add more hostnames like this that cannot be taken by DHCP clients. Uwe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPV6
The combination of a range and ra-names can't work. RA is router advertisement and the IP addresses are then given by slaac, so the range must only be a prefix and must have size exactly 64 bits. If you want real DHCP like in ipv4, you must use stateful DHCP, but that won't work with Android phones. Am May 7, 2018 2:16:01 PM UTC schrieb "Merell L. Matlock, Jr." <mlmatlo...@gmail.com>: >Interesting reads. I even understood 1/4 of them :) > >My router does not (as far as I can tell, digging thru IPV6 settings) >do >GUA addressing. I think I understand how to get dnsmasq issue ULA's, >based upon a previous message from you (Sun Aug 20 14:33:35 BST 2017). > >Based upon this: > >dhcp-range=set:ula6,fd7a:d:e:f::1:0,fd7a:d:e:f::1:,64,12h > >Would I then comment out the line from my config: > >dhcp-range=::100,::1ff,constructor:eth0,ra-names,slaac,168h > >I assume that would give me fc00::/7 addresses for my clients, with >global addresses coming from the router? > >I get a /64 from my ISP: (2600:8807::27::/64) > >Thanks, > >Merell > > > > > >On 05/05/2018 09:37 PM, M. Buecher wrote: >> Hi there, >> >> IPv6 is by definition "multi-homed", so you would do Global Unicast >> Addresses (GUA; Prefix 2000::/3; RFC 4291) via your router and Unique >> Local Addresses (ULA; Prefix fc00::/7; RFC 4193) via dnsmasq. >> >> If you want to manager GUA also via dnsmasq, then you need to do >DHCP-PD >> from dnsmasq to your router. >> >> What kind of prefix do you get from your ISP? /48, /56, /60, /64? >> >> Regards >> Maddes >> >> >> >> On 2018-05-06 01:48, Merell Matlock wrote: >> >>> Hoping for some help/insight it my attempting to setup IPV6 DHCP; I >must >>> not seem to be able to input the right search terms, because I keep >>> going around in circles. >>> >>> My Setup: >>> >>> ISP <> Modem <> Router <> home network >>> >>> DNS/DHCP on an RPi3 (DNSMASQ/Pi-hole, behind the router). >>> >>> V4 DHCP from the RPi works flawlessly. >>> >>> My router is pulling V6 from the ISP via DHCP-PD, and I can't >fine-tune >>> the routers' RA to only send out route info, and if I disable the RA >>> from the router, no IPV6 at all (ifconfig/ipconfig only shows >link-local >>> addresses), no matter what I try with DNSMASQ. >>> >>> IPV6 pass-through on the router has the same result. >>> >>> Here is what I have from .conf files (all from pi-hole interface): >>> >>> enable-ra >>> dhcp-option=option6:dns-server,[::] >>> dhcp-range=::100,::1ff,constructor:eth0,ra-names,slaac,168h >>> ra-param=*,high,60,0 >>> >>> I changed the ra-param in an attempt to bypass the routers' RA. >>> >>> Option6 is working as expected. >>> >>> Any ideas, or am I just looking at a pipe dream (wanting host names >in >>> the pi-hole query log, instead of IPV6 addresses). >>> >>> Thank you, >>> >>> >>> Merell Matlock >>> >>> ___ >>> Dnsmasq-discuss mailing list >>> Dnsmasq-discuss@lists.thekelleys.org.uk >>> <mailto: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 -- Uwe Schindler Achterdiek 19, 28357 Bremen https://www.thetaphi.de___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] IPv6 host registration in DNS
Hi, The problem is with SLAAC addresses: DNSMASQ has no idea in an IPv6-only network about the hostnames (it has not seen any DHCP request containing a host name) nor it knows about the actual IP addresses. In SLAAC mode, dnsmasq only sends RA packets around and the client builds the IP address on its own. But the generated IP address is never reported back, the client just uses it. With the cool dnsmasq workaround called "ra-names", the trick is to use some information from the previous IPv4 DHCP request: dnsmasq learns about the host name and the MAC address of the client! It then builds the SLAAC address on its own and tries by ping if the IP address responds. And if that's the case, it registers a hostname for the SLAAC address. But it needs both the MAC and the hostname! Unfortunately this does not work with Windows, if random identifiers are enabled (which is by default) and if firewall is enabled. To register hostnames in IPv6-only environments, you need to use stateful DHCPv6 and disable SLAAC. But unfortunately not all clients work with DHCPv6! Some only listen to RAs by default! Currently e.g. Windows uses DHCPv6 if announced by the RA to do so, but Android phones are not able to do this. With SLAAC disabled they won't get an address. Another approach would be to allow both: SLAAC and stateful DHCPv6. All clients that support DHCPv6 would get 2 addresses (a SLAAC one and stateful one), but the hostname would always point to the stateful one. Problem in DSL environments is the fact that the lease time works against you. The stateful address would be kept assigned until its lease times out and this can be a lot later that the PPP link went down. So it's not recommeneded at all for PPP links with dynamic IPs. Hope this explanation helps, Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Dnsmasq-discuss [mailto:dnsmasq-discuss- > boun...@lists.thekelleys.org.uk] On Behalf Of Robert N > Sent: Saturday, September 16, 2017 2:50 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: [Dnsmasq-discuss] IPv6 host registration in DNS > > Hello all, > > I'm trying to replace the DNS/DHCP of my FritzBox home router with > dnsmasq. > > For IPv4 everything seems to work fine, i.e. when clients request an > IPv4 address, dnsmasq registers their hostnames, so name resolution for > local machines works. > > But it does not seem to work for IPv6. I want the clients to do SLAAC > but still dnsmasq should serve records for local hosts if asked > for. > If I understood correctly, then dnsmasq will only register the hostnames > for which it receives a DHCP request. Does this require the hosts to > request an IP address? Or will the hostnames be added to DNS also if > just the DNS server information is requested? > > So I probably should configure what is called stateless DHCPv6: > > > no-resolv > server=8.8.8.8 > server=8.8.4.4 > server=2001:4860:4860:: > server=2001:4860:4860::8844 > > domain=home.example.net > local=/home.example.net/ > domain-needed > bogus-priv > expand-hosts > stop-dns-rebind > > enable-ra > ra-param=high > > read-ethers > dhcp-option=option6:dns-server,[fd00::] > dhcp-option=option6:domain-search,home.example.net > dhcp-range=::,constructor:lan,ra-names,ra-stateless > > # This will tell DHCP clients to not ask for proxy information > # Some clients, like Windows 7, will constantly ask if not told NO > # > https://wiki.openwrt.org/doc/howto/dhcp.dnsmasq#log_continuously_filled > _with_dhcpinformdhcpack > dhcp-option=252,"\n" > > log-async=10 > log-dhcp > > > However, I don't get dnsmasq to return records for local hostnames. > Is this configuration basically correct? Or am I missing something? > > > Best regards, > Robert > > ___ > 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] Windows ipv6 hostname
Hi, > > Windows hosts generally have 2 problems, so assigning a DNS name with > > IPv6 address using "ra-names" only works under the following > > circumstances: > > > > - The Windows firewall must allow ICMP Echo (PING) requests to go > > through (IPv6). And here comes the problem: By default the Windows > > firewall blocks pings on IPv4 and IPv6. Dnsmasq pings the possible SLAAC > > defined IPv6 address to see if it is valid. And that does not work by > > default. > > Ah, so firewall settings. Anyway for correct IPv6 setup you should not disable > ICMPv6. As ICMPv6 messages are critical part of whole network. ECHO is > probably not needed, but PACKET-TOO-BIG is *required*. By default the windows firewall blocks ICMPv4 and ICMPv6 ECHO requests, not ICMP in general. This causes several issues, so whenever I setup a Windows machine this is one of the first thing to disable. > > - Windows has to assign the IPv6 address using the official > > SLAAC algorithm! Unfortunately with randomized-ideftifiers enabled (also > > the default), the auto-assigned IPv6 addresses are not created form the > > MAC address using the SLAAC algorithm. You have to disable > > randomized-identifiers to make this work. > > SLAAC is not used when A(utonomous) bit is not announced in RA prefix and > in case M(anaged) bit is present DHCPv6 should be used. > > And I think this setup is used, so SLAAC algorithm does not matter here. Markus' mails were initially saying that he uses "ra-names", so ist definitely not stateful DHCPv6. Mabye he changed inbetween, but I wanted to post this here, what one must do for "ra-names" to work correct: - Disable firewall rule to block ICMP v4 and also ICMP v6 ECHO - Disable randomized-identifiers and reboot: netsh interface ipv6 set global randomizeidentifiers=disabled store=active netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent Uwe > > With above default, Windows hides its IPv6 address completely and you > > cannot guess it. > > > > Important: Randomized-Identifiers has nothing to do with privacy > > extensions (with privacy extensions, the IPv6 address is still SLAAC > > conform, but IPv6 hosts use a second address for *outgoing* connections > > only. The SLAAC address is still there and can be pinged). > > > > On my windows machines I have disabled randomized-identifiers, but they > > still use privacy extensions. In additions pinging is enabled in the > > firewall. Then everything works. This is not the fault of dnsmasq, there > > is nothing it can do better - maybe instead of pinging it can use some > > different approach to "verify" the IP address (something like a IPv6 > > like ARP request only). > > Hm, I think this is not an optimal implementation in dnsmasq. ICMPv6 ND > packet should be used instead ICMPv6 ECHO. > > As ECHO is (as you wrote) by default blocked on Windowses and ND is > "equivalent" for ARP I suggest to change implementation to ND. This is why I asked here. Ra-names never woks on Windows with default firewall rules. So something like a ICMP ND would be better to check for existence of IPs. Maybe dnsmasq has an option to do this, but the last time I tried, the only way to get ra-names work with Windows is to disable this stupid Windows-Firewall rule. The problem is more people visiting me and have those misconfigured windowses :-( > > > > > think of: > > > > > 1) Dnsmasq configuration (dhcp-host options) > > > > > 2) /etc/ethers if enabled > > > > > 3) suggested with the DHCPv4 request by the client With "ra-names" it does the latter. It uses the hostname from the original DHCPv4 request of the client and registers it in its own DNS. But it has no IPv6 address for it, as this is unknown for stateless RA (as you have enabled with "enable-ra" and "ra-names"). It can only guess and verify the hostname. It does this with the above checkes, which fail if you use "randomized-identifiers" on Windows (default) and the Windows Firewall blocks PING requests. Because of this its impossible to guess the right IPv6 address and not even verify it to be correct! > > > > > I think Windows 10 should suggest a hostname (3), at least it seems > > > > > to do for me. I have manually assigned > > > > > a hostname on the Windows computer, and dnsmasq knows and > assigns > > > > > it. Yes, for IPv4 this works. For IPv6 with "ra-names" it needs more. In addition: Since Windows 10 Anniversary update, the DHCPv6 Client of Windows is completely broken. It does not send DHCP6-INFORMATION requests anymore to discover the DNS server. This is known to Microsoft an they work on a solution to make stateless DHCPv6 work again. Uwe ___ 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
Hi, Windows hosts generally have 2 problems, so assigning a DNS name with IPv6 address using "ra-names" only works under the following circumstances: - The Windows firewall must allow ICMP Echo (PING) requests to go through (IPv6). And here comes the problem: By default the Windows firewall blocks pings on IPv4 and IPv6. Dnsmasq pings the possible SLAAC defined IPv6 address to see if it is valid. And that does not work by default. - Windows has to assign the IPv6 address using the official SLAAC algorithm! Unfortunately with randomized-ideftifiers enabled (also the default), the auto-assigned IPv6 addresses are not created form the MAC address using the SLAAC algorithm. You have to disable randomized-identifiers to make this work. With above default, Windows hides its IPv6 address completely and you cannot guess it. Important: Randomized-Identifiers has nothing to do with privacy extensions (with privacy extensions, the IPv6 address is still SLAAC conform, but IPv6 hosts use a second address for *outgoing* connections only. The SLAAC address is still there and can be pinged). On my windows machines I have disabled randomized-identifiers, but they still use privacy extensions. In additions pinging is enabled in the firewall. Then everything works. This is not the fault of dnsmasq, there is nothing it can do better - maybe instead of pinging it can use some different approach to "verify" the IP address (something like a IPv6 like ARP request only). Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Dnsmasq-discuss [mailto:dnsmasq-discuss- > boun...@lists.thekelleys.org.uk] On Behalf Of Pali Rohár > Sent: Thursday, December 22, 2016 1:49 PM > To: Markus Hartung <m...@hartmark.se> > Cc: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] Windows ipv6 hostname > > On Thursday 22 December 2016 11:24:53 Markus Hartung wrote: > > On 2016-12-21 14:08, Michael Stilkerich wrote: > > > Well, dnsmasq needs to get the hostname to assign to a machine from > > > someplace. I don't know > > > all the possible places (search the manual page for that), but I > > > can > > > > > > think of: > > > 1) Dnsmasq configuration (dhcp-host options) > > > 2) /etc/ethers if enabled > > > 3) suggested with the DHCPv4 request by the client > > > > > > I think Windows 10 should suggest a hostname (3), at least it seems > > > to do for me. I have manually assigned > > > a hostname on the Windows computer, and dnsmasq knows and assigns > > > it. > > > > On 2016-12-20 12:53, Pali Rohár wrote: > > > Another option is to stop using SLAAC and start using DHCPv6 where > > > you have full control of assigned IPv6 addresses. > > > > > > Such feature like host will "randomly" chose address is unsuitable > > > for setup when you need to have control of which address is > > > assigned to which device (e.g in this setup when you want to > > > assign record). > > > > I have managed to get DHCPv6 working now, I thought that windows 10 > > didn't have any support for it. > > Windows Vista has (good quality) support for DHCPv6 and IIRC new > versions of Windowses uses same/similar implementation. So I think > Windows 10 should work (no idea if some advanced configuration is > needed)... Also at that time Windows Vista had correct implementation of > using RA prefix together with assigned DHCPv6 address. (In contrast > common linux ISC DHCPv6 client is still broken and hardcode /64 prefix > even if RA announce different). > > > It turned out that my ufw on my > > ubuntu server were blocking the DHCPv6. I was in my simple mind just > > assuming that DHCP and DHCPv6 used same ports > > It is common behaviour that all firewalls block everything except some > exceptions. It is also good for security reasons. > > DHCP is using IPv4 and DHCPv6 is obviously using IPv6. And IPv6 network > stack is independent of IPv4, so you need to configure your firewall > differently for IPv4 and IPv6 (e.g. iptables vs. ip6tables). > > And because DHCP and DHCPv6 are *different* protocols, they should not > be used on same ports. If you look at DNS there is no DNSv6 or so. DNS > is same over IPv4 and IPv6. > > You cannot ask for IPv6 address via DHCP or IPv4 via DHCPv6. But you can > resolve record (IPv6) via IPv4 connection to DNS, so hence DNS is > only one. > > If you cannot memorize number of tcp or udp ports for some services, > just look into /etc/services file. > > $ grep -E -i 'dhcp|bootp' /etc/services > bootps
Re: [Dnsmasq-discuss] DNSSEC on lookups of *.paypal.com no longer work
Hi Simon, > > Well, that's the smoking gun. Dnsmasq is doing the right thing, and your > > upstream server at 212.202.215.1 is broken. I realise that doesn't solve > > the problem, but at least you know where to work now :) > > > > > > (the reason dnsmasq is returning SERVFAIL is that there's a > > chain-of-trust from the root that says paypal.com is signed, If the > > answer to the paypal.com query isn't signed, it may be a false answer, > > so it can't be trusted.) > > Of course this is the right thing to do! > > I will contact the upstream provider and ask them to fix this! > > Interestingly, two of their three IPv4 DNS servers have the problem. The 3rd > one and all three IPv6 DNS servers are working fine. This explains why it > sometimes worked. > > Maybe a good idea is: If a DNSSEC query fails and DNSMASQ knows more > servers, retry on others, too? What do you think about this proposal? Uwe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNSSEC on lookups of *.paypal.com no longer work
Hi Simon, > Well, that's the smoking gun. Dnsmasq is doing the right thing, and your > upstream server at 212.202.215.1 is broken. I realise that doesn't solve > the problem, but at least you know where to work now :) > > > (the reason dnsmasq is returning SERVFAIL is that there's a > chain-of-trust from the root that says paypal.com is signed, If the > answer to the paypal.com query isn't signed, it may be a false answer, > so it can't be trusted.) Of course this is the right thing to do! I will contact the upstream provider and ask them to fix this! Interestingly, two of their three IPv4 DNS servers have the problem. The 3rd one and all three IPv6 DNS servers are working fine. This explains why it sometimes worked. Maybe a good idea is: If a DNSSEC query fails and DNSMASQ knows more servers, retry on others, too? Uwe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Wildcard Domain resolving does not work with DNSSEC
Hi, I found out that resolving of DNSSEC signed wildcard domains does not work correctly with dnsmasq. I think the problem is that it looks for a signature of the requested domain name and not the wildcard. The following fails: $ dig issues.pangaea.de ; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> issues.pangaea.de ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59252 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;issues.pangaea.de. IN A ;; Query time: 18 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Jan 04 15:43:42 CET 2016 ;; MSG SIZE rcvd: 46 The reason is: "issues.pangaea.de" is covered by a star domain "*.pangaea.de" that is correctly signed (tested from another server - not using dnsmasq): $ dig +dnssec *.pangaea.de ; <<>> DiG 9.8.1-P1 <<>> +dnssec '*.pangaea.de' ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8436 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;*.pangaea.de. IN A ;; ANSWER SECTION: *.pangaea.de. 28790 IN A 134.1.2.171 *.pangaea.de. 28790 IN RRSIG A 7 2 28800 20160109144508 20151226151023 12714 pangaea.de. jwQUt4OJRlBEE3PUF6cEWJA6gOLWPpBWYbJHLIkR4tdGJh/kmtOk7T9Q MlSbChj51bhkV6oCQ++OhrsogYJ9qFpcVz8kVlEEfs08/Z1kNBe/dg3m HaAiyVVwONdyfe6dSfcYR3ZrH1PBWuxHDdbO8zGI8xGThSuZiIi1WEFC L64= ;; AUTHORITY SECTION: pangaea.de. 28790 IN NS ns2.domaindiscount24.net. pangaea.de. 28790 IN NS ns3.domaindiscount24.net. pangaea.de. 28790 IN NS ns1.domaindiscount24.net. pangaea.de. 28790 IN RRSIG NS 7 2 28800 20160109071640 20151226151023 12714 pangaea.de. l7sVnSXwN21lXvsANvjVxGyeh3c3rxlmg3ctfAShdvZpS/otk7L/HN8p O3sSJ83HFfl7QAmfoF/P3cy2yilmykJv3von/ojzXVeS3tpTAUzfALql maoKds12FcjyLVJDgEzi0xKG/DTmm2KG1bZHzXPzMVb4beZnzFN5twLK W+g= ;; Query time: 0 msec ;; SERVER: 85.25.128.10#53(85.25.128.10) ;; WHEN: Mon Jan 4 14:42:43 2016 ;; MSG SIZE rcvd: 471 How should this be solved? This is another one where dnssec fails, so clearly a bug. There is a test page about exactly that case, which fails for me when resolving through dnsmasq: http://0skar.cz/dns/en/ Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Wildcard Domain resolving does not work with DNSSEC
Please note: I fixed the example domain to have a real A record. Try any other fake name instead: e.g., "dummy.pangaea.de", also referring to wildcard domain. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message----- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Monday, January 04, 2016 3:49 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Wildcard Domain resolving does not work with DNSSEC > > Hi, > > I found out that resolving of DNSSEC signed wildcard domains does not work > correctly with dnsmasq. I think the problem is that it looks for a signature > of > the requested domain name and not the wildcard. > > The following fails: > > $ dig issues.pangaea.de > > ; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> issues.pangaea.de > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59252 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;issues.pangaea.de. IN A > > ;; Query time: 18 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Mon Jan 04 15:43:42 CET 2016 > ;; MSG SIZE rcvd: 46 > > > The reason is: "issues.pangaea.de" is covered by a star domain > "*.pangaea.de" that is correctly signed (tested from another server - not > using dnsmasq): > > $ dig +dnssec *.pangaea.de > > ; <<>> DiG 9.8.1-P1 <<>> +dnssec '*.pangaea.de' > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8436 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;*.pangaea.de. IN A > > ;; ANSWER SECTION: > *.pangaea.de. 28790 IN A 134.1.2.171 > *.pangaea.de. 28790 IN RRSIG A 7 2 28800 20160109144508 > 20151226151023 12714 pangaea.de. > jwQUt4OJRlBEE3PUF6cEWJA6gOLWPpBWYbJHLIkR4tdGJh/kmtOk7T9Q > MlSbChj51bhkV6oCQ++OhrsogYJ9qFpcVz8kVlEEfs08/Z1kNBe/dg3m > HaAiyVVwONdyfe6dSfcYR3ZrH1PBWuxHDdbO8zGI8xGThSuZiIi1WEFC L64= > > ;; AUTHORITY SECTION: > pangaea.de. 28790 IN NS ns2.domaindiscount24.net. > pangaea.de. 28790 IN NS ns3.domaindiscount24.net. > pangaea.de. 28790 IN NS ns1.domaindiscount24.net. > pangaea.de. 28790 IN RRSIG NS 7 2 28800 20160109071640 > 20151226151023 12714 pangaea.de. > l7sVnSXwN21lXvsANvjVxGyeh3c3rxlmg3ctfAShdvZpS/otk7L/HN8p > O3sSJ83HFfl7QAmfoF/P3cy2yilmykJv3von/ojzXVeS3tpTAUzfALql > maoKds12FcjyLVJDgEzi0xKG/DTmm2KG1bZHzXPzMVb4beZnzFN5twLK W+g= > > ;; Query time: 0 msec > ;; SERVER: 85.25.128.10#53(85.25.128.10) > ;; WHEN: Mon Jan 4 14:42:43 2016 > ;; MSG SIZE rcvd: 471 > > How should this be solved? This is another one where dnssec fails, so clearly > a bug. > > There is a test page about exactly that case, which fails for me when > resolving through dnsmasq: http://0skar.cz/dns/en/ > > Uwe > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Wildcard Domain resolving does not work with DNSSEC
Hi, Yeah, works. Just rebuilt debian package with "2.76test3" - all fine now. It could be that this has fixed it: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=13480e8c2a0e170a5e070f82c46e6ae00c464a89 (although this talks about a wildcard pointing to a CNAME). Maybe Simon can inform us which commit fixed this issue. Thanks for the quick reply! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Kevin Darbyshire-Bryant [mailto:ke...@darbyshire-bryant.me.uk] > Sent: Monday, January 04, 2016 5:19 PM > To: Uwe Schindler <u...@thetaphi.de> > Cc: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] Wildcard Domain resolving does not work > with DNSSEC > > > > On 04/01/2016 16:05, Uwe Schindler wrote: > > Hi, > > > > Was there a change in dnsmasq related to this? Would be good to get some > feedback. I'll try this version now. Currently I am running 2.75 (Debian > testing > pkg 2.75-1) > Yes. BIG changes. See the git log: > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=summary > > In fact I see I am far behind the times - test3 out 12 minutes ago :-) > > Do you have dnssec enabled? > Yes. > > Kevin ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Wildcard Domain resolving does not work with DNSSEC
Hi, Was there a change in dnsmasq related to this? Would be good to get some feedback. I'll try this version now. Currently I am running 2.75 (Debian testing pkg 2.75-1) Do you have dnssec enabled? Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Dnsmasq-discuss [mailto:dnsmasq-discuss- > boun...@lists.thekelleys.org.uk] On Behalf Of Kevin Darbyshire-Bryant > Sent: Monday, January 04, 2016 4:40 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] Wildcard Domain resolving does not work > with DNSSEC > > > > On 04/01/16 14:48, Uwe Schindler wrote: > > Hi, > > > > I found out that resolving of DNSSEC signed wildcard domains does not > work correctly with dnsmasq. I think the problem is that it looks for a > signature of the requested domain name and not the wildcard. > > > > > > > > ;; Query time: 0 msec > > ;; SERVER: 85.25.128.10#53(85.25.128.10) > > ;; WHEN: Mon Jan 4 14:42:43 2016 > > ;; MSG SIZE rcvd: 471 > > > > How should this be solved? This is another one where dnssec fails, so > clearly a bug. > > > > There is a test page about exactly that case, which fails for me when > resolving through dnsmasq: http://0skar.cz/dns/en/ > > > > Uwe > > > > - > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > > I just tried that page using dnsmasq276test2 and got 'green' for all tests. > > Kevin > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] CPU spin in master
Hi, I'll try. Unfortunately I have to provoke the spinning somehow. I just installed the test version, was happy, and a few minutes back it was no longer responding. TOP showed 99% CPU. By the way, box is a VIA C7 standard x86 box (32 bits), not MIPS like Kevin's. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Simon Kelley [mailto:si...@thekelleys.org.uk] > Sent: Monday, January 04, 2016 6:04 PM > To: Uwe Schindler <u...@thetaphi.de> > Cc: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] CPU spin in master > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Yes, the fix is in test3. Can you build with debug symbols > > make CFLAGS=-g > > > and run under gdb, to find where it's spinning? > > > Cheers, > > Simon > > > On 04/01/16 17:01, Uwe Schindler wrote: > > Hi, > > > > ALARM: I compiled "2.76test3" and now it is spinning with 100% CPU > > on my box, box responds slow or not at all on DNS query. Was the > > fix included in "test3"? I updated from 2.75 to 2.76test3 because > > of the previously mentioned wildcard dnssec issue. > > > > Uwe > > > > - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de eMail: u...@thetaphi.de > > > > > >> -Original Message- From: Dnsmasq-discuss > >> [mailto:dnsmasq-discuss- boun...@lists.thekelleys.org.uk] On > >> Behalf Of Simon Kelley Sent: Monday, January 04, 2016 5:15 PM To: > >> dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: > >> [Dnsmasq-discuss] CPU spin in master > >> > > Think that one's fixed then :) Many thanks. > > > > > > Simon. > > > > > > On 03/01/16 10:42, Kevin Darbyshire-Bryant wrote: > >>>> Router survived the night. No obvious problems noted :-) > >>>> > >>>> -- Cheers, > >>>> > >>>> Kevin Sent from my phone, apologies for brevity, spelling & > >>>> top posting > >>>> > >>>>> On 2 Jan 2016, at 17:20, Kevin Darbyshire-Bryant > >>>>> <ke...@darbyshire-bryant.me.uk> wrote: > >>>>> > >>>>> > >>>>> > >>>>>> On 01/01/16 20:27, Simon Kelley wrote: > >>>>>>> On 01/01/16 11:28, Kevin Darbyshire-Bryant wrote: Hi > >>>>>>> Simon, > >>>>>>> > >>>>>>> So this is a pretty vague report of something lurking > >>>>>>> in very recent code.# > >>>>>> It's pretty good really. I stared at the ARP-caching code > >>>>>> and found a fault in the linked list code that could > >>>>>> introduce a cycle and create exactly the symptoms you're > >>>>>> seeing. > >>>>>> > >>>>>> > >>>>>> Git HEAD or 2.76test2 should do it. Please could you try > >>>>>> it? > >>>>> It's compiling as I type - will report back :-) > >>>>>> > >>>>>> > >>>>>> And many thanks for testing my new code! > >>>>> Well if we all played it safe and avoided the bleeding > >>>>> edge stuff nothing would get spotted & fixed would it :-) > >>>>> Someone has to try and I'd hardly regard my home router as > >>>>> life critical (although my niece would have a different > >>>>> opinion on that if she were visiting) > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Kevin > >>>>> > >>>>> > >>>>> ___ > 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 > >> > >> > >>>>> > ___ > >> 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) > > iQIcBAEBCAAGBQJWiqX4AAoJEBXN2mrhkTWisoUP/0H9v94uMpBTdm19ySoL > H2EV > SWrq7uPuR7QHkJMILoyHZTLq4lk7N6SD0WkHWV9mxIZ5+J1y7PK1SSWBTAQ > VtpKD > xGlMfpmgEfAOk/eH1Txc3+WwRfKxXPu03DXBFLPlhQpwZSMgHZYngdP3ITlyC > 9ob > 41kgWUlM3z4mwe35m3GC/MKsXHF7ZYiFmpar2R+Lnwh8Q00cMFUnJs8PYbV > yk6Ql > uGqnrW4QnT+VemOHv2ZF6X9zWw63F2TtzJ1wzIItUC9biVn8PDpnr9ayH06UN > Rdo > 3Y8uHIMLp2hex28SuCpVyYPfiwbEm/44z1/Un7txx6x64Tv0AcgDscMDMQwW > LbPZ > VJhO05Mba9u0G/xAnu48MvvyAZo3aQ0M+n4LGUnXCI7Tv3iD1BBcKus2pqflV > uYG > QH4Z7aEnxfH+I+WHboPi1yY8zUcXKGlbZBAkEtJ5DMO/l5czYrz69xCrnift9Wi1 > NdqtOpj72nnNuSxfiQnBQ1FcjNR05iG4dD5Vdgash7phVPi839ipJ5NgSRFK+sG > N > 8/nRaOwAxluj2ZMnfVEs06fiikNa9Hjen8c3+x+DwkLVtmqHrVKeVRXleV67Rtn > x > uE7Xr93Cn3yPC3SsBMrsUKaZW2VAfaTCInJ7YFsFuogwbrSzDsHgxosRIPOnuS > wF > MSMtK6L+LnARO4qnby2o > =DZau > -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] CPU spin in master
Hi, ALARM: I compiled "2.76test3" and now it is spinning with 100% CPU on my box, box responds slow or not at all on DNS query. Was the fix included in "test3"? I updated from 2.75 to 2.76test3 because of the previously mentioned wildcard dnssec issue. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Dnsmasq-discuss [mailto:dnsmasq-discuss- > boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Monday, January 04, 2016 5:15 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] CPU spin in master > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Think that one's fixed then :) Many thanks. > > > Simon. > > > On 03/01/16 10:42, Kevin Darbyshire-Bryant wrote: > > Router survived the night. No obvious problems noted :-) > > > > -- Cheers, > > > > Kevin Sent from my phone, apologies for brevity, spelling & top > > posting > > > >> On 2 Jan 2016, at 17:20, Kevin Darbyshire-Bryant > >> <ke...@darbyshire-bryant.me.uk> wrote: > >> > >> > >> > >>> On 01/01/16 20:27, Simon Kelley wrote: > >>>> On 01/01/16 11:28, Kevin Darbyshire-Bryant wrote: Hi Simon, > >>>> > >>>> So this is a pretty vague report of something lurking in very > >>>> recent code.# > >>> It's pretty good really. I stared at the ARP-caching code and > >>> found a fault in the linked list code that could introduce a > >>> cycle and create exactly the symptoms you're seeing. > >>> > >>> > >>> Git HEAD or 2.76test2 should do it. Please could you try it? > >> It's compiling as I type - will report back :-) > >>> > >>> > >>> And many thanks for testing my new code! > >> Well if we all played it safe and avoided the bleeding edge > >> stuff nothing would get spotted & fixed would it :-) Someone has > >> to try and I'd hardly regard my home router as life critical > >> (although my niece would have a different opinion on that if she > >> were visiting) > >> > >> Thanks, > >> > >> Kevin > >> > >> > >> ___ 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 v2.0.22 (GNU/Linux) > > iQIcBAEBCAAGBQJWipp4AAoJEBXN2mrhkTWiOs4P/0Vm32VFtw9CYnMvNTR > eOcDu > UTNWgFHtE3cVbgiuUqTcuU0h7txR5lCfusoA5P3ed1Q37XcoNr6Vmgk6gaVk6q > y5 > dG0zNOb2r+hYiP6HyxG0tL0DluA5XOA9eb7T6BEN7KfvwS4ZRKrPOVK0sQXu2T > IL > YNmho2nixjjMDj51IbjovFhJaAFCipZipSS+OwsdpC+KJ63upraccP/9/6+4DX9R > rq1l8tJZhkDWygESHsd+Wsxtfe/4oOvl4QSkOakIsse0kurXjLZiA7DPUaObOeG0 > gVTM+rXdOFmeWKFUPlOb18ZhYEUPZCcKgSvfzy7Aj2wJ5l3VR5YQJ+wKWQFl > gVRA > MDJK/2y8eBOrBZOxNzcX41/33CE2fh2mKNaeRsBBf5vhYsMXq5QKePCdwDhy > vHN6 > hLUy1Um0VytaWuJE6tbWLrH3Y2DPNVp4ZJWuBz3h6uLBE/eeG4ZAnFtIwM0j > Bjd+ > kVBXOkTjhYdnYpWS0MRus0v3kpy4iUSiELzyjUOW+97oZbtPWhDVeL0mxqyF > bmj3 > gzbzgfS+K9ApJbEdUt3THwYShRRTllq3YSdUPE2aFPmDC56rVdUapCZMtLapIup > 9 > tRiTTp30uCYDp7pIPUJHFByCEGLWr460ZXKpJxzsINcwScY/kTe5R6VcZCDpiCFR > VK5MYc4AFdfXIXSDIRKb > =u1u4 > -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] Wildcard Domain resolving does not work with DNSSEC
Hi, > I just tried the git-HEAD code, and pangaea.de is OK, both > issues.pangea.de, which is a genuine record, and simon.pangea.de which > is an expansion of the wildcard I changed issues.pangaea.de to a genuine record already (this is how I identified the issue). The test with simon.pangaea.de now also passes (test4), but this one is broken with 2.75. Sorry for changing the DNS record after I submitted to this mailing list. > ;simon.pangaea.de.IN A > > ;; ANSWER SECTION: > simon.pangaea.de. 21599 IN A 134.1.2.171 > simon.pangaea.de. 21599 IN RRSIG A 7 2 28800 20160109144508 > 20151226151023 12714 pangaea.de. > jwQUt4OJRlBEE3PUF6cEWJA6gOLWPpBWYbJHLIkR4tdGJh/kmtOk7T9Q > MlSbChj51bhkV6oCQ++OhrsogYJ9qFpcVz8kVlEEfs08/Z1kNBe/dg3m > HaAiyVVwONdyfe6dSfcYR3ZrH1PBWuxHDdbO8zGI8xGThSuZiIi1WEFC L64= > > ;; AUTHORITY SECTION: > pangaea.de. 21599 IN NS ns2.domaindiscount24.net. > pangaea.de. 21599 IN NS ns3.domaindiscount24.net. > pangaea.de. 21599 IN NS ns1.domaindiscount24.net. > pangaea.de. 21599 IN RRSIG NS 7 2 28800 20160109071640 > 20151226151023 > 12714 pangaea.de. > l7sVnSXwN21lXvsANvjVxGyeh3c3rxlmg3ctfAShdvZpS/otk7L/HN8p > O3sSJ83HFfl7QAmfoF/P3cy2yilmykJv3von/ojzXVeS3tpTAUzfALql > maoKds12FcjyLVJDgEzi0xKG/DTmm2KG1bZHzXPzMVb4beZnzFN5twLK W+g= > ram3pr4d5q9klnm2dsopmt3hjmua0mf6.pangaea.de. 3599 IN NSEC3 1 0 5 > 89D0BF16A5176B72 U1NCQMCLBNAMOFE2B186713NF2I82HUC CNAME > RRSIG > ram3pr4d5q9klnm2dsopmt3hjmua0mf6.pangaea.de. 3599 IN RRSIG NSEC3 7 > 3 > 3600 2016055643 20151228181431 12714 pangaea.de. > JuqEskBXSOC+3d+a2VPrlLlvQgMsiIa+duYpe/egYi4M9UdixtzDfYs2 > qWJpDqlsO3lf5Eeeh2bbrZudnYmjQ9q4i8viPZO2j+nGdDCASFNUXzHb > B7ynmS1Ba3393TAiCoYbPKbf5HURNRDjR3T6m4dUriYPGJM7mc6Q7Cu+ > MRM= > > > The 0skar.cz test domains have very long dates on the signature > expiration fields, which found a bug in that code. Having fixed that, > I can validate everything that Google DNS validates. > > Cheers, > > Simon. > > > > On 04/01/16 14:48, Uwe Schindler wrote: > > Hi, > > > > I found out that resolving of DNSSEC signed wildcard domains does > > not work correctly with dnsmasq. I think the problem is that it > > looks for a signature of the requested domain name and not the > > wildcard. > > > > The following fails: > > > > $ dig issues.pangaea.de > > > > ; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> issues.pangaea.de ;; global > > options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: > > SERVFAIL, id: 59252 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, > > AUTHORITY: 0, ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; > > QUESTION SECTION: ;issues.pangaea.de. IN A > > > > ;; Query time: 18 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: > > Mon Jan 04 15:43:42 CET 2016 ;; MSG SIZE rcvd: 46 > > > > > > The reason is: "issues.pangaea.de" is covered by a star domain > > "*.pangaea.de" that is correctly signed (tested from another server > > - not using dnsmasq): > > > > $ dig +dnssec *.pangaea.de > > > > ; <<>> DiG 9.8.1-P1 <<>> +dnssec '*.pangaea.de' ;; global options: > > +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, > > id: 8436 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, > > ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; > > QUESTION SECTION: ;*.pangaea.de. IN A > > > > ;; ANSWER SECTION: *.pangaea.de. 28790 IN A > > 134.1.2.171 *.pangaea.de. 28790 IN RRSIG A 7 2 > > 28800 20160109144508 20151226151023 12714 pangaea.de. > > jwQUt4OJRlBEE3PUF6cEWJA6gOLWPpBWYbJHLIkR4tdGJh/kmtOk7T9Q > > MlSbChj51bhkV6oCQ++OhrsogYJ9qFpcVz8kVlEEfs08/Z1kNBe/dg3m > > HaAiyVVwONdyfe6dSfcYR3ZrH1PBWuxHDdbO8zGI8xGThSuZiIi1WEFC L64= > > > > ;; AUTHORITY SECTION: pangaea.de. 28790 IN NS > > ns2.domaindiscount24.net. pangaea.de. 28790 IN > > NS ns3.domaindiscount24.net. pangaea.de. 28790 > > IN NS ns1.domaindiscount24.net. pangaea.de. > > 28790 IN RRSIG NS 7 2 28800 20160109071640 20151226151023 > > 12714 pangaea.de. > > l7sVnSXwN21lXvsANvjVxGyeh3c3rxlmg3ctfAShdvZpS/otk7L/HN8p > > O3sSJ83HFfl7QAmfoF/P3cy2yilmykJv3von/ojzXVeS3tpTAUzfALql > > maoKds12FcjyLVJDgEzi0xKG/DTmm2KG1bZHzXPzMVb4beZnzFN5twLK > W+g= > > >
Re: [Dnsmasq-discuss] Wildcard Domain resolving does not work with DNSSEC
Hi, That is fixed already (used 2.75 from debian, no bleeding edge)! I tried test3 (now test4 because of spinning bug) and this one worked correctly. The test page also passed: http://0skar.cz/dns/en/ Do you have an idea, which commit may have fixed it? I found one (see other mail), but it talked about CNAME's which were not used here. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Dnsmasq-discuss [mailto:dnsmasq-discuss- > boun...@lists.thekelleys.org.uk] On Behalf Of Simon Kelley > Sent: Monday, January 04, 2016 4:55 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: Re: [Dnsmasq-discuss] Wildcard Domain resolving does not work > with DNSSEC > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > What release are you using, Uwe. > > I just tried the git-HEAD code, and pangaea.de is OK, both > issues.pangea.de, which is a genuine record, and simon.pangea.de which > is an expansion of the wildcard > > ;simon.pangaea.de.IN A > > ;; ANSWER SECTION: > simon.pangaea.de. 21599 IN A 134.1.2.171 > simon.pangaea.de. 21599 IN RRSIG A 7 2 28800 20160109144508 > 20151226151023 12714 pangaea.de. > jwQUt4OJRlBEE3PUF6cEWJA6gOLWPpBWYbJHLIkR4tdGJh/kmtOk7T9Q > MlSbChj51bhkV6oCQ++OhrsogYJ9qFpcVz8kVlEEfs08/Z1kNBe/dg3m > HaAiyVVwONdyfe6dSfcYR3ZrH1PBWuxHDdbO8zGI8xGThSuZiIi1WEFC L64= > > ;; AUTHORITY SECTION: > pangaea.de. 21599 IN NS ns2.domaindiscount24.net. > pangaea.de. 21599 IN NS ns3.domaindiscount24.net. > pangaea.de. 21599 IN NS ns1.domaindiscount24.net. > pangaea.de. 21599 IN RRSIG NS 7 2 28800 20160109071640 > 20151226151023 > 12714 pangaea.de. > l7sVnSXwN21lXvsANvjVxGyeh3c3rxlmg3ctfAShdvZpS/otk7L/HN8p > O3sSJ83HFfl7QAmfoF/P3cy2yilmykJv3von/ojzXVeS3tpTAUzfALql > maoKds12FcjyLVJDgEzi0xKG/DTmm2KG1bZHzXPzMVb4beZnzFN5twLK W+g= > ram3pr4d5q9klnm2dsopmt3hjmua0mf6.pangaea.de. 3599 IN NSEC3 1 0 5 > 89D0BF16A5176B72 U1NCQMCLBNAMOFE2B186713NF2I82HUC CNAME > RRSIG > ram3pr4d5q9klnm2dsopmt3hjmua0mf6.pangaea.de. 3599 IN RRSIG NSEC3 7 > 3 > 3600 2016055643 20151228181431 12714 pangaea.de. > JuqEskBXSOC+3d+a2VPrlLlvQgMsiIa+duYpe/egYi4M9UdixtzDfYs2 > qWJpDqlsO3lf5Eeeh2bbrZudnYmjQ9q4i8viPZO2j+nGdDCASFNUXzHb > B7ynmS1Ba3393TAiCoYbPKbf5HURNRDjR3T6m4dUriYPGJM7mc6Q7Cu+ > MRM= > > > The 0skar.cz test domains have very long dates on the signature > expiration fields, which found a bug in that code. Having fixed that, > I can validate everything that Google DNS validates. > > Cheers, > > Simon. > > > > On 04/01/16 14:48, Uwe Schindler wrote: > > Hi, > > > > I found out that resolving of DNSSEC signed wildcard domains does > > not work correctly with dnsmasq. I think the problem is that it > > looks for a signature of the requested domain name and not the > > wildcard. > > > > The following fails: > > > > $ dig issues.pangaea.de > > > > ; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> issues.pangaea.de ;; global > > options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: > > SERVFAIL, id: 59252 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, > > AUTHORITY: 0, ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; > > QUESTION SECTION: ;issues.pangaea.de. IN A > > > > ;; Query time: 18 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: > > Mon Jan 04 15:43:42 CET 2016 ;; MSG SIZE rcvd: 46 > > > > > > The reason is: "issues.pangaea.de" is covered by a star domain > > "*.pangaea.de" that is correctly signed (tested from another server > > - not using dnsmasq): > > > > $ dig +dnssec *.pangaea.de > > > > ; <<>> DiG 9.8.1-P1 <<>> +dnssec '*.pangaea.de' ;; global options: > > +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, > > id: 8436 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, > > ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; > > QUESTION SECTION: ;*.pangaea.de. IN A > > > > ;; ANSWER SECTION: *.pangaea.de. 28790 IN A > > 134.1.2.171 *.pangaea.de. 28790 IN RRSIG A 7 2 > > 28800 20160109144508 20151226151023 12714 pangaea.de. > > jwQUt4OJRlBEE3PUF6cEWJA6gOLWPpBWYbJHLIkR4tdGJh/kmtOk7T9Q > > MlSbChj51bhkV6oCQ++OhrsogYJ9qFpcVz8kVlEEfs08/Z1kNBe/dg3m > > HaAiyVVwONdyfe6dSfcYR3ZrH1PBWuxHDdbO8zG
Re: [Dnsmasq-discuss] CPU spin in master
Hi, Grabbed, compiled, and installed it. I'll report back. It is now in use on my router, so I'll see if anything like this happens again. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Simon Kelley [mailto:si...@thekelleys.org.uk] > Sent: Monday, January 04, 2016 6:19 PM > To: Uwe Schindler <u...@thetaphi.de> > Cc: dnsmasq-discuss@lists.thekelleys.org.uk; 'Kevin Darbyshire-Bryant' > <ke...@darbyshire-bryant.me.uk> > Subject: Re: [Dnsmasq-discuss] CPU spin in master > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Please use test4, which fixes the problem (again!) > > Cheers, > > Simon. > > > On 04/01/16 17:07, Uwe Schindler wrote: > > Hi, > > > > I'll try. Unfortunately I have to provoke the spinning somehow. I > > just installed the test version, was happy, and a few minutes back > > it was no longer responding. TOP showed 99% CPU. > > > > By the way, box is a VIA C7 standard x86 box (32 bits), not MIPS > > like Kevin's. > > > > Uwe > > > > - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de eMail: u...@thetaphi.de > > > > > >> -Original Message- From: Simon Kelley > >> [mailto:si...@thekelleys.org.uk] Sent: Monday, January 04, 2016 > >> 6:04 PM To: Uwe Schindler <u...@thetaphi.de> Cc: > >> dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: > >> [Dnsmasq-discuss] CPU spin in master > >> > > Yes, the fix is in test3. Can you build with debug symbols > > > > make CFLAGS=-g > > > > > > and run under gdb, to find where it's spinning? > > > > > > Cheers, > > > > Simon > > > > > > On 04/01/16 17:01, Uwe Schindler wrote: > >>>> Hi, > >>>> > >>>> ALARM: I compiled "2.76test3" and now it is spinning with > >>>> 100% CPU on my box, box responds slow or not at all on DNS > >>>> query. Was the fix included in "test3"? I updated from 2.75 > >>>> to 2.76test3 because of the previously mentioned wildcard > >>>> dnssec issue. > >>>> > >>>> Uwe > >>>> > >>>> - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen > >>>> http://www.thetaphi.de eMail: u...@thetaphi.de > >>>> > >>>> > >>>>> -Original Message- From: Dnsmasq-discuss > >>>>> [mailto:dnsmasq-discuss- boun...@lists.thekelleys.org.uk] > >>>>> On Behalf Of Simon Kelley Sent: Monday, January 04, 2016 > >>>>> 5:15 PM To: dnsmasq-discuss@lists.thekelleys.org.uk > >>>>> Subject: Re: [Dnsmasq-discuss] CPU spin in master > >>>>> > >>>> Think that one's fixed then :) Many thanks. > >>>> > >>>> > >>>> Simon. > >>>> > >>>> > >>>> On 03/01/16 10:42, Kevin Darbyshire-Bryant wrote: > >>>>>>> Router survived the night. No obvious problems noted > >>>>>>> :-) > >>>>>>> > >>>>>>> -- Cheers, > >>>>>>> > >>>>>>> Kevin Sent from my phone, apologies for brevity, > >>>>>>> spelling & top posting > >>>>>>> > >>>>>>>> On 2 Jan 2016, at 17:20, Kevin Darbyshire-Bryant > >>>>>>>> <ke...@darbyshire-bryant.me.uk> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> On 01/01/16 20:27, Simon Kelley wrote: > >>>>>>>>>> On 01/01/16 11:28, Kevin Darbyshire-Bryant wrote: > >>>>>>>>>> Hi Simon, > >>>>>>>>>> > >>>>>>>>>> So this is a pretty vague report of something > >>>>>>>>>> lurking in very recent code.# > >>>>>>>>> It's pretty good really. I stared at the > >>>>>>>>> ARP-caching code and found a fault in the linked > >>>>>>>>> list code that could introduce a cycle and create > >>>>>>>>> exactly the symptoms you're seeing. > >>>>>>>>> > >>>>>>>>> > >>>&g
Re: [Dnsmasq-discuss] prohibit ipv6 for some clients
The problem is that it "announces" (RA = Router Announcement): It sends broadcast packets with the routing information to the network and everybody interested can pick it up. You cannot filter those, because they have no unicast address. So everybody who is on the network can listen to IPv6 RA packets. The only way to disable IPv6 for some clients is to put them into a separate network / VLAN. I have in my wireless two separate SSIDs. E.g., Samsung (Android) phones that have broken WLAN chips that filter IPv6 in sleep mode causing push notifications by google not working, connect with that IPv4-only SSID. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Dnsmasq-discuss [mailto:dnsmasq-discuss- > boun...@lists.thekelleys.org.uk] On Behalf Of ? > Sent: Thursday, September 10, 2015 12:18 PM > To: dnsmasq-discuss@lists.thekelleys.org.uk > Subject: [Dnsmasq-discuss] prohibit ipv6 for some clients > > Hello, > > Can you help me with subj configuration... > > I have configuration like this > =Beginning of the citation== > expand-hosts > port=0 > server=127.0.0.1 > interface=br0 > interface=tap1 > interface=tap2 > interface=tap3 > log-dhcp > > rebind-localhost-ok > > dhcp-authoritative > enable-ra > > > dhcp-range=::1, ::FF, constructor:br*, ra-names, 64, 12h > dhcp-range=::1, ::FF, constructor:tap*, ra-names, 64, 12h > > > filterwin2k > =The end of the citation > > it is used to announce ipv6 > > I'd like not to annouce ipv6 for known clients... > How it can be done? > is it possible to configure smth inside dnsmasq config, or it can be done > using iptables? > > thanks in advance, > Alex. > > ___ > 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] can't take away IPv4 address
Hi Harald, Dnsmasq does the check which the standards require, which is to send an ICMP ping (echo request) to the address it's about to allocate. The fact that the client doesn't respond would seem to indicate that the clients are NOT using IP addresses after the lease has expired. I think the ping test would be pretty helpful. The IPv4 address range is set to 10.10.0.0/16. Lease time is 1h. There are less than 200 DHCP clients in my net. Even without ping test it should be easy to avoid a conflict. The problem with a ping test is: Most clients using a firewall (especially the Windows Firewall) block pings by default (which is horrible, just my personal opinion). So just throwing away the address may not work in all cases. But what can be done: If the lease expires and was not renewed by the client and client cannot be pinged anymore, then it could be removed from the leases. The problem with ARP tables getting out of date is more Linux-Kernel specific. Dnsmasq does not really deal with ARP tables. Uwe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Questions about Adding IPv6 External DNS Servers to dnsmasq
Hi, if the failing test is only the last one: Your DNS server (possibly run by your ISP) appears to have no access to the IPv6 internet, or it is not configured to use it, then you are perfectly fine! The message is a little bit misleading, but if you understand what's happening its quite clear: This test checks, if the *last* nameserver in the chain uses IPv6 to connect the nameserver responsible for the requested domain (the trick they use is to return a different IP address for requests coming in with IPv4 and IPv6). As dnsmasq does not do recursive lookups and just delegates to another nameserver at your ISP (or OpenDNS,as you configured it), your ISP's caching nameserver does this request to the final destination. If this connection (ISP nameserver - responsible nameserver) is done by IPv4, the test fails. It does not matter if your own nameserver uses IPv6 or if your own nameserver connects via IPv6 to the ISP's nameserver. Here is only tests if the connection to the responsible final nameserver is done via IPv6. As you have no access to your ISP's nameserver, there is nothing you can do. And it does not matter at all. If your ISP switches to IPv6 completely, they have to fix this, too - but it is out of your control. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Patrick Dickey Sent: Thursday, October 03, 2013 12:07 AM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Questions about Adding IPv6 External DNS Servers to dnsmasq Message: 4 Date: Tue, 01 Oct 2013 21:14:04 +0100 From: Simon Kelley si...@thekelleys.org.uk To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Questions about adding IPv6 external DNS servers to dnsmasq Message-ID: 524b2d0c.2030...@thekelleys.org.uk Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 01/10/13 19:26, Patrick Dickey wrote: Hello there, I'm running a dual-stack IPv4/IPv6 network, where my IPv6 address is handled through a tunnel service (TunnelBroker). My router handles the IPv6 DHCP, but doesn't hand out the DNS server information. I have an Amahi Server running dnsmasq that handles my IPv4 DHCP and all DNS information. Currently it's only using the IPv4 DNS Servers, as it has never been configured with IPv6 entries. What I need to do is set dnsmasq up so that it can handle both IPv4 and IPv6 resolution. In the /etc/dnsmasq.conf file, I see the following lines # Send DHCPv6 option. Note [] around IPv6 addresses. #dhcp-option=option6:dns-server,[1234::77],[1234::88] # Send DHCPv6 option for namservers as the machine running # dnsmasq and another. #dhcp-option=option6:dns-server,[::],[1234::88] My questions are these: 1. If I uncomment these lines, and include the IPv6 addresses that I want to use (OpenDNS addresses), will this get sent out to the networked computers? No, because dnsmasq is not doing DHCPv6 for your network. 2. If I uncomment these lines, and include the IPv6 addresses, will dnsmasq use those addresses to resolve IPv6? No, that's not what they do. You can put IPv6 addresses in /etc/resolv.conf or server= lines in /etc/dnsmasq.conf to do that. 3. Do I need to include my IPv6 address for the dnsmasq (Amahi) server somewhere in either dnsmasq.conf or resolv.conf, in order to tell all networked computers to ask it for IPv6 addresses? (I ask this, because currently my networked computers are told to ask only the Amahi server for IPv4 DNS resolution, so I need that to happen with IPv6 also). You can do. but see above and below. 4. What exactly do these two sets of configurations do, as the comment really doesn't explain it (only tells you what you're configuring)? 5. If editing these lines won't work, will adding the entries at the bottom of the dnsmasq.conf file do what I need? I'm mainly asking #4 because I can't find anything online that really explains what this option does, or how to actually *configure* your network for IPv6 DNS resolution. A final question is this: Will this work as I intend, or do I need to have dnsmasq handle my IPv6 DHCP also? I can either turn off the DHCP on my router (Cisco 2514 series), or if worse comes to worse, have the server handle updating my tunnel also. But, I'd prefer not to do this, in case the server is down (then at least I'll have IPv6 connectivity). Thank you for any information, and have a great day.:) Patrick. So, the rules are that you can only hand out IPv6 DNS server addresses via DHCPv6 and IPv4 nameserver addresses via DHCPv4. But, you probably don't need to worry about this because a nameserver
Re: [Dnsmasq-discuss] Non-standard port and resolv.conf file
Hi, I don’t think this should be fixed at all, because it violates the „official“ format of resolv.conf, see man page. A resolv.conf file modifies like this could not be read by libc’s resolver functions. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de/ http://www.thetaphi.de eMail: u...@thetaphi.de From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq-discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Rance Hall Sent: Wednesday, August 28, 2013 11:47 PM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Non-standard port and resolv.conf file The standard fix for this is to create multiple resolv.conf files. I use this: /etc/resolv.conf.dnsmasq /etc/resolv.conf.local I also use a script to manage these in the event that my external ip is DHCP. If /etc/resolv.conf changes copy it to /etc/resolv.conf.dnsmasq then copy /etc/resolv.conf.local to /etc/resolv.conf Configure dnsmasq to use the alternate /etc/resolv.conf.dnsmasq file instead of standard. This serves two purposes. 1) it makes the server use itself for dns. 2) it keeps nonstandard stuff like what you discuss on the outside of the network and the internal network functions in a standard way. Easier troubleshooting. If there is a limitation in dnsmasq proper about using alternate port Simon will fix it, he's good like that. On Wed, Aug 28, 2013 at 12:46 PM, Scott Bonar sbo...@cradlepoint.com wrote: Is there anyway to have dnsmasq use the same server address parsing when using the resolv.conf file as it does when using the 'server' command line/config option? My issue is that I want to use the resolv.conf file so I don't have to restart dnsmasq, but the nameserver I am using also uses a non-standard port, i.e. not 53. On the command line I can do something like '111.222.333.444#5353', but if I put this type of format in the resolv.conf file dnsmasq does not like it. Thx -- Scott Bonar | Lead Software Engineer | 208.870.7851 http://www.cradlepoint.com/about/blog http://www.cradlepoint.com/about/blog ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss http://www.cradlepoint.com/about/blog ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi Simon, I did a git pull yesterday evening and problem was already fixed. Many thanks! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Simon Kelley [mailto:si...@thekelleys.org.uk] Sent: Monday, July 29, 2013 4:55 PM To: Uwe Schindler Cc: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? On 27/07/13 19:21, Uwe Schindler wrote: Hi, I found the reason for this bug: One small thing with your new code - maybe a bug, because the comment says something else: Although the configured (in my config) valid_lifetime of the prefix is now lower (30 mins on my machine), after deprecation it raises the valid_lifetime again up to 2 hrs. It misses to apply this code also to context-saved_lifetime in radv.c, approx. line 484: /* configured time is ceiling */ if (!constructed || valid time) valid = time; So this 3 lines should be moved up, before the part where valid is copied to saved_valid. Or the same code should also be applied to saved_lifetime, if set. Got it. That's fixed in the git repo now. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi Simon, I want to try and avoid making every parameter changable, like Radv does. Who can tell what the parameters should be. A flag which says stay in fast retransmit mode to fix buggy android seems much more sensible. That is perfectly fine! So a boolean option to work around the android bug (and for other power-saving devices, which ignore ICMPv6 messages in sleep mode) would be enough! Ideally we could detect android devices and automatically switch to that mode once an android device is in the WLAN, but that’s not really possible without a large database of MAC address prefixes of broken WIFI chips/manufacturers. :-) Maybe Broadcom fixes the bug at some time and later Samsung devices does not have this problem (the HTC Desire here is completely responsible - with the backside that the ongoing ICMP requests drain battery faster, because kernel has to wake up to process the RA). git repo now has --force-fast-ra. I'm currently hacking on a tiny netbook without access to my normal test harness, so this is untested. It's simple enough that I probably haven't broken it :) I did a git pull and rebuilt debian package. Works like a charm! Finally I found one more small thing in addition to the deprecated prefixes: radvd sends shortly before exiting one or two last router advertisements to deprecate all prefixes it has given out before (this is also part of the DeprecatePrefix option of radvd). I found out that in the fact of a reboot of the router, when it comes back again there is no chance to deprecate the leases altogether. Another option would be to save the deprecated/used prefixes in the lease file, so it survives reboots of the router. In that case when somebody switches off the router by removing power coord or rebooting it through the web interface, it would announce the old prefixes as deprecated (for max 2 hours as we do currently). In my opinion, this would be nice to have, but its not urgent. At least it should send one or 2 RAs on shut down with preferred_lifetime=0 and maximum 2 hrs valid_ lifetime (but not greater than the current lifetime). Radvd does this if requested, so shutdown takes approx. 1 second. Hmm, deprecate prefixes when dnsmasq goes down but the router doesn't, but don't deprecate prefixes when the router goes down. That sounds exactly backwards. I know I probably restart dnsmasq more often than most (here at dnsmasq central, we eat our own dogfood) but the idea that stopping dnsmasq would kill all IPv6 connectivity on the network sounds like a bad one to me. I think this is the reason why it is optional in radvd. You have to explicitely enable DeprecatePrefix: DeprecatePrefix on|off Upon shutdown, this option will cause radvd to deprecate the prefix by announcing it in the radvd shutdown RA with a zero preferred lifetime and a valid lifetime slightly greater than 2 hours. This will encourage end-nodes using this prefix to deprecate any associated addresses immediately. Note that this option should only be used when only one router is announcing the prefix onto the link, otherwise end-nodes will deprecate associated addresses despite the prefix still being valid for preferred use. See RFC4862, section 5.5.3., Router Advertisement Processing, part (e). Default: off I agree this has pros and cons. The problem with Linux machines is: On shutdown, dnsmasq is killed first and after that the network links are going down. When you shutdown/reboot your router, the old prefix of your ppp connection stays alive for very long time, because nothing deprecates it. So the deprecate on shutdown was just a easy to implement idea. I think the most correct impl would be: - dnsmasq writes all prefixes it announces to a file (at a similar persistent place like the dnsmasq.leases file). Maybe use the lease file for this. - After a restart it reads this file and for every prefix from this file which is no longer available it would do the same announcement like implemented before. Just make the list of prefixes persistent, on restart reload them and after restart do the same cleanup and mark for deprecation on them like implemented before if they disappeared. This is just a nice idea for future development, as I assume it's more complicated to do. As a workaround I will reorder the router's init.d scripts, so my PPP connection is shut down before dnsmasq, so dnsmasq has a short time to announce the deprecation. Uwe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, I send in my config: dhcp-option=option6:information-refresh-time,1h Otherwise, Windows Clients never try to renew information from DHCPv6 (it looks like that to me, in reality its 86400 secs, which is the default if not specified). http://www.6net.org/publications/standards/rfc4242.txt confirms this: This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration. Further details: 3.1. Constants We define two constants for use by the protocol. How they are used is specified in the sections below. IRT_DEFAULT 86400 In some cases the client uses a default refresh time IRT_DEFAULT. The recommended value for IRT_DEFAULT is 86400 (24 hours). The client implementation SHOULD allow for this value to be configurable. IRT_MINIMUM 600 This defines a minimum value for the refresh time. 3.2. Client Behaviour A client MUST request this option in the Option Request Option (ORO) when sending Information-Request messages to the DHCPv6 server. A client MUST NOT request this option in the ORO in any other messages. If the Reply to an Information-Request message does not contain this option, the client MUST behave as if the option with value IRT_DEFAULT was provided. In my opinion, dnsmasq should by default (like for stateful IPv4 leases) use the lifetime specified in the dhcp-range to request the clients to refresh this information. If it is explicitely given, of course use the information from option6:information-refresh-time setting. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Simon Kelley [mailto:si...@thekelleys.org.uk] Sent: Saturday, July 27, 2013 3:04 PM To: Uwe Schindler Cc: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? On 26/07/13 17:50, Uwe Schindler wrote: One thing I found in my investigations: The lifetime given in the dhcp-range for IPv6 oly affects the RAs, but not the time for refreshing the DHCP information request. I had to set it explicitely as dhcp-option6. What option are you sending? Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, Regarding the Android-Bug: I found out that I still have to enable the fast mode (which is only done in the first minute after a config change). The reason is: Although the prefix has a lifetime of 86400 on my dhcp-range, in contrast, the router itself gets a lifetime of 1800 secs (3 times RA_INTERVAL), the RDNS got a lifetime of 1200 secs (2 times RA_INTERVAL). To me this looks a bit inconsequent. The router itself is in my opinion the most stable thing of all, because its link-local-adress is used by clients. The DNS server should in my opinion have the same lifetime as the prefix / dhcp-range - or best would be to use this value: dhcp-option=option6:information-refresh-time (maybe you should send the dhcp's range's lease time as information-refresh-time on every dhcp request). The 3 times RA_INTERVAL comes from the default given in RFC 4861, section 6.2.1 which also specifies an absolute maximum value of 9000 seconds. I don't know if it's sensible to violate this RFC. OK that's fine. If the RFC says that, we should not violate! In general this means that the lifetime of the prefix does not need to be longer than that time, too. Because when the android phone does not get the RAs, its default gateway (router) will go away and so the IPv6 address is dead altogether. In my opinion, if the DNS server information is not limited, it should be set to the time of the prefix, too. I was able to fix the android bug again by reducing the re-transmit time by patcing the code, this time a bit more easy: I changed, as suggested by you, the if-statement in the function new_timeout(struct dhcp_context *context, time_t now), to always use the short interval of 5 - 20 secs. This solved the problem. I think if you add a config option to enable the fast retransmit if you have buggy android phones, we are fine. In addition, maybe have a separate config option to change the fast retransmit time (but different from RA_INTERVAL) and RA_INTERVAL itself (as you can do with radvd). I want to try and avoid making every parameter changable, like Radv does. Who can tell what the parameters should be. A flag which says stay in fast retransmit mode to fix buggy android seems much more sensible. That is perfectly fine! So a boolean option to work around the android bug (and for other power-saving devices, which ignore ICMPv6 messages in sleep mode) would be enough! Ideally we could detect android devices and automatically switch to that mode once an android device is in the WLAN, but that’s not really possible without a large database of MAC address prefixes of broken WIFI chips/manufacturers. :-) Maybe Broadcom fixes the bug at some time and later Samsung devices does not have this problem (the HTC Desire here is completely responsible - with the backside that the ongoing ICMP requests drain battery faster, because kernel has to wake up to process the RA). Finally I found one more small thing in addition to the deprecated prefixes: radvd sends shortly before exiting one or two last router advertisements to deprecate all prefixes it has given out before (this is also part of the DeprecatePrefix option of radvd). I found out that in the fact of a reboot of the router, when it comes back again there is no chance to deprecate the leases altogether. Another option would be to save the deprecated/used prefixes in the lease file, so it survives reboots of the router. In that case when somebody switches off the router by removing power coord or rebooting it through the web interface, it would announce the old prefixes as deprecated (for max 2 hours as we do currently). In my opinion, this would be nice to have, but its not urgent. At least it should send one or 2 RAs on shut down with preferred_lifetime=0 and maximum 2 hrs valid_ lifetime (but not greater than the current lifetime). Radvd does this if requested, so shutdown takes approx. 1 second. Oone small thing with your new code - maybe a bug, because the comment says something else: Although the valid_lifetime of the prefix is now lower (30 mins on my machine), after deprecation it raises the valid_lifetime again up to 2 hrs. This is unneeded. It should use the lower of the current valid_lifetime or 2 hrs (this is what it explains in the RFC): then the IPv6 CE router MUST immediately advertise the old prefix with a Preferred Lifetime of zero and a Valid Lifetime of the lower of the current Valid Lifetime and 2 hours (which must be decremented in real time). BTW: The 2 hours are a special number: it is the minimum time a router can use to reannounce the valid lifetime if it is currently higher. Otherwise a client would ignore this message - this is to prevent malicious clients from spoofing a router. This is why it must use a minimum of the current lifetime but never more than 2 hours to deprecate the prefix. The code should look like: Once a prefix is
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, I found the reason for this bug: One small thing with your new code - maybe a bug, because the comment says something else: Although the configured (in my config) valid_lifetime of the prefix is now lower (30 mins on my machine), after deprecation it raises the valid_lifetime again up to 2 hrs. It misses to apply this code also to context-saved_lifetime in radv.c, approx. line 484: /* configured time is ceiling */ if (!constructed || valid time) valid = time; So this 3 lines should be moved up, before the part where valid is copied to saved_valid. Or the same code should also be applied to saved_lifetime, if set. Uwe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi Simon, Perfect! I will rebuild the debian package from the snapshot and try out. As far as I see, you have not yet made the RA_INTERVAL configurable (only for the unsolicited advertisements), so I will patch this, too. But in any case, I can raise the lifetimes now, so the problem will appear later. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Simon Kelley [mailto:si...@thekelleys.org.uk] Sent: Friday, July 26, 2013 3:03 PM To: Uwe Schindler Cc: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? On 25/07/13 22:32, Uwe Schindler wrote: Hi, reading https://datatracker.ietf.org/doc/rfc6204/?include_text=1, the requirements for home routers are listed here: L-13: If the delegated prefix changes, i.e., the current prefix is replaced with a new prefix without any overlapping time period, then the IPv6 CE router MUST immediately advertise the old prefix with a Preferred Lifetime of zero and a Valid Lifetime of the lower of the current Valid Lifetime and 2 hours (which must be decremented in real time) in a Router Advertisement message as described in Section 5.5.3, (e) of [RFC4862]. This was my original proposal. I agree that this should be done by the PPP/WAN interface and the DHCPv6 cleint on the WAN interface, so the old prefix gets deprecated, but with current software available (ISC dhcpd does not work on PPP interfaces but would support that using a shell script applying the prefix delegation - and wide-dhcpc supports PPP interfaces, but it allows not to configure prefix delegation, so in deprecates addresses after PPP reconnect or a change of the prefix). So I would be very happy, if dnsmasq (as router advertisement daemon would provide support for this). Radvd does it - see DeprecatePrefix options in radvd. Try 2.67test8 - on the server now. No extra configuration needed. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Have fun in Berlin! But the new code makes it possible to me to set the lifetime of the dhcp-lease to good old pre-IPv6 times (86400s) so it is very unlikely that the android problem reappears. I have tested it, all is fine now. The Android bug can be worked around by raising the lifetime/lease time in the DHCP/RA - I raised it now back to 86400 like my already existing IPv4 dhcp-range. It is very unlikely that the mobile phone is switched off to standby for longer than one day! So when it wakes up, the prefix is still valid. If the prefix changes from the provider, its correctly deprecated, so all is fine now. One thing I found in my investigations: The lifetime given in the dhcp-range for IPv6 oly affects the RAs, but not the time for refreshing the DHCP information request. I had to set it explicitely as dhcp-option6. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Simon Kelley [mailto:si...@thekelleys.org.uk] Sent: Friday, July 26, 2013 5:45 PM To: Uwe Schindler Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? On 26/07/13 16:24, Uwe Schindler wrote: Hi Simon, Perfect! I will rebuild the debian package from the snapshot and try out. As far as I see, you have not yet made the RA_INTERVAL configurable (only for the unsolicited advertisements), Not yet, but I did split the calculation out into its own function in preparation. Off to Berlin for IETF now. I should have some time to keep working on this during the conference. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, After some testing and reconnecting PPP connection several times: All works fine. It also recognizes multiple old prefixes and sends all of them as deprecated. Regarding the Android-Bug: I found out that I still have to enable the fast mode (which is only done in the first minute after a config change). The reason is: Although the prefix has a lifetime of 86400 on my dhcp-range, in contrast, the router itself gets a lifetime of 1800 secs (3 times RA_INTERVAL), the RDNS got a lifetime of 1200 secs (2 times RA_INTERVAL). To me this looks a bit inconsequent. The router itself is in my opinion the most stable thing of all, because its link-local-adress is used by clients. The DNS server should in my opinion have the same lifetime as the prefix / dhcp-range - or best would be to use this value: dhcp-option=option6:information-refresh-time (maybe you should send the dhcp's range's lease time as information-refresh-time on every dhcp request). I was able to fix the android bug again by reducing the re-transmit time by patcing the code, this time a bit more easy: I changed, as suggested by you, the if-statement in the function new_timeout(struct dhcp_context *context, time_t now), to always use the short interval of 5 - 20 secs. This solved the problem. I think if you add a config option to enable the fast retransmit if you have buggy android phones, we are fine. In addition, maybe have a separate config option to change the fast retransmit time (but different from RA_INTERVAL) and RA_INTERVAL itself (as you can do with radvd). Uwe P.S.: FYI, my DNS server address is a private IPv6 address which is assigned to the LAN interface in addition to the global prefix, see my other mail for explanation. So the DNS is stable here, stable as the link-local router address. I would recommend this setup also for router manufacturers. If the DNS server is not stable, the information-refresh-time in the DHCP packets should in any case be specified, otherwise the client never ever asks again for the DNS server. I checked this on windows computer. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Uwe Schindler Sent: Friday, July 26, 2013 6:50 PM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? Have fun in Berlin! But the new code makes it possible to me to set the lifetime of the dhcp-lease to good old pre-IPv6 times (86400s) so it is very unlikely that the android problem reappears. I have tested it, all is fine now. The Android bug can be worked around by raising the lifetime/lease time in the DHCP/RA - I raised it now back to 86400 like my already existing IPv4 dhcp-range. It is very unlikely that the mobile phone is switched off to standby for longer than one day! So when it wakes up, the prefix is still valid. If the prefix changes from the provider, its correctly deprecated, so all is fine now. One thing I found in my investigations: The lifetime given in the dhcp-range for IPv6 oly affects the RAs, but not the time for refreshing the DHCP information request. I had to set it explicitely as dhcp-option6. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Simon Kelley [mailto:si...@thekelleys.org.uk] Sent: Friday, July 26, 2013 5:45 PM To: Uwe Schindler Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? On 26/07/13 16:24, Uwe Schindler wrote: Hi Simon, Perfect! I will rebuild the debian package from the snapshot and try out. As far as I see, you have not yet made the RA_INTERVAL configurable (only for the unsolicited advertisements), Not yet, but I did split the calculation out into its own function in preparation. Off to Berlin for IETF now. I should have some time to keep working on this during the conference. Cheers, Simon. ___ 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] Make RA_INTERVAL configureable? Deprecate old prefixes?
On 24/07/13 19:16, Uwe Schindler wrote: Hi, RA's are not the same as DHCP, there's no such thing as a lease time. What there is, is preferred and valid lifetimes. What should happen is that when old address is about to go away, the address for that prefix on the network adaptor should have its preferred lifetime set to zero, and dnsmasq will then notice that and send RA's with the preferred lifetime also set to zero. I meant the life time, it was just a typo somehow :-) The idea here was to send preferred_lifetime=0 in RAs for prefixes that disappeared from the interface to inform the clients that they are no longer useable (my provider does not route old prefixes after a reconnect with PPP). Currently you have to set the lifetime very low (which produces more traffic on the wire) or manually delete or switch on/off the network adaptors once the router reconnects or the prefix changes for some reason. My proposal is to keep a list of previous prefixes from the constructor:ethX code and also send those prefixes, but with lifetime=0 to inform all client to no longer use that address. Those 0-lifetime RAs should be sent at least for the length of the original lifetime. Radvd has code to handle this (although it’s a bit buggy). My understanding of this is that it's something that should happen in the DHCP client and/or ISP DHCP server. Ie, when the prefix has to change, the ISP's DHCP server renews the existing prefix delegation, but with the preferred lifetime==0. It also offers a new prefix delegation. The old and new prefixes get installed in the network adaptor with the preferred lifetime values. Dnsmasq starts to advertise the new prefix and continues to advertise the old prefix, but with the pref- lifetime at zero taken from the value in the adaptor. The problem is different in most cases: When you have a dhcp client waiting on an PPPoE connection (e.g. wide-dhcpc, like most consumer routers use - ISC dhcp cannot listen on ppp interfaces unfortunately) and the PPPoE connection gets reconnected/disconnected, the ppp interface is disappears and is later recreated. When its disappearing, the whole set of IP addresses gets lost and they are not deprecated, so dnsmasq will not recognize any deprecation. I have seen your code that propagates the deprecation of existing interfaces in the RAs, but this only works if the prefix/IP address is still existing on the interface, just with preferred lifetime==0. With PPP interfaces disappearing and being recreated, this does not help, because the address is gone (it’s a new instance of the network interface, just with same name). As dnsmasq is mainly for consumer routers which are mostly working with PPP connections, it would be nice to have. Again, this is new territory, I'm not saying has to be done like that, but that's the process I was thinking of when I wrote the existing code. That's fine! See also: http://manpages.ubuntu.com/manpages/precise/man5/radvd.conf.5.html DeprecatePrefix on|off Upon shutdown, this option will cause radvd to deprecate the prefix by announcing it in the radvd shutdown RA with a zero preferred lifetime and a valid lifetime slightly greater than 2 hours. This will encourage end-nodes using this prefix to deprecate any associated addresses immediately. Note that this option should only be used when only one router is announcing the prefix onto the link, otherwise end-nodes will deprecate associated addresses despite the prefix still being valid for preferred use. See RFC4862, section 5.5.3., Router Advertisement Processing, part (e). Default: off Shutdown means in that case shutdown of interface, too. At least this is how it works for radvd. Uwe Cheers, Simon. ___ 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] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi again, In addition, I found a relic from the time when the RA_INTERVAL value was hardcoded into radv.c. There is still one: Line 294: put_opt6_long(1800); /* lifetime - twice RA retransmit */ Should be: put_opt6_long(RA_INTERVAL * 2); /* lifetime - twice RA retransmit */ I am currently looking into the code to find an easy way how to make the RA_INTERVAL configureable, maybe I can provide a patch. But if it's easy for you, it would be really nice to have this in future versions. So the deprecation of addresses no longer used on the network interface is not my primary concern, more I would prefer to work around the bugs in certain android phones not receiving ICMPv6 messages in standby mode, so the RA_INTERVAL should be configureable (I want to set it to much lower values than 600s, I have a patched version with 6s retransmit running on my debian testing box). Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Uwe Schindler Sent: Wednesday, July 24, 2013 8:17 PM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? Hi, RA's are not the same as DHCP, there's no such thing as a lease time. What there is, is preferred and valid lifetimes. What should happen is that when old address is about to go away, the address for that prefix on the network adaptor should have its preferred lifetime set to zero, and dnsmasq will then notice that and send RA's with the preferred lifetime also set to zero. I meant the life time, it was just a typo somehow :-) The idea here was to send preferred_lifetime=0 in RAs for prefixes that disappeared from the interface to inform the clients that they are no longer useable (my provider does not route old prefixes after a reconnect with PPP). Currently you have to set the lifetime very low (which produces more traffic on the wire) or manually delete or switch on/off the network adaptors once the router reconnects or the prefix changes for some reason. My proposal is to keep a list of previous prefixes from the constructor:ethX code and also send those prefixes, but with lifetime=0 to inform all client to no longer use that address. Those 0-lifetime RAs should be sent at least for the length of the original lifetime. Radvd has code to handle this (although it’s a bit buggy). Uwe ___ 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] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, On 24/07/13 19:16, Uwe Schindler wrote: Hi, RA's are not the same as DHCP, there's no such thing as a lease time. What there is, is preferred and valid lifetimes. What should happen is that when old address is about to go away, the address for that prefix on the network adaptor should have its preferred lifetime set to zero, and dnsmasq will then notice that and send RA's with the preferred lifetime also set to zero. I meant the life time, it was just a typo somehow :-) The idea here was to send preferred_lifetime=0 in RAs for prefixes that disappeared from the interface to inform the clients that they are no longer useable (my provider does not route old prefixes after a reconnect with PPP). Currently you have to set the lifetime very low (which produces more traffic on the wire) or manually delete or switch on/off the network adaptors once the router reconnects or the prefix changes for some reason. My proposal is to keep a list of previous prefixes from the constructor:ethX code and also send those prefixes, but with lifetime=0 to inform all client to no longer use that address. Those 0-lifetime RAs should be sent at least for the length of the original lifetime. Radvd has code to handle this (although it’s a bit buggy). My understanding of this is that it's something that should happen in the DHCP client and/or ISP DHCP server. Ie, when the prefix has to change, the ISP's DHCP server renews the existing prefix delegation, but with the preferred lifetime==0. It also offers a new prefix delegation. The old and new prefixes get installed in the network adaptor with the preferred lifetime values. Dnsmasq starts to advertise the new prefix and continues to advertise the old prefix, but with the pref- lifetime at zero taken from the value in the adaptor. The problem is different in most cases: When you have a dhcp client waiting on an PPPoE connection (e.g. wide-dhcpc, like most consumer routers use - ISC dhcp cannot listen on ppp interfaces unfortunately) and the PPPoE connection gets reconnected/disconnected, the ppp interface is disappears and is later recreated. When its disappearing, the whole set of IP addresses gets lost and they are not deprecated, so dnsmasq will not recognize any deprecation. I have seen your code that propagates the deprecation of existing interfaces in the RAs, but this only works if the prefix/IP address is still existing on the interface, just with preferred lifetime==0. With PPP interfaces disappearing and being recreated, this does not help, because the address is gone (it’s a new instance of the network interface, just with same name). As dnsmasq is mainly for consumer routers which are mostly working with PPP connections, it would be nice to have. Indeed ist more complicated but effect ist he same: For DSL lines you ahev in most cases the following setup: - PPP connection (PPPoE), creating network adaptor ppp0 - this adaptor is coming on going when connections are created/released - LAN interface (on which dnsmasq is listening), eth0, with a static IPv4 address and a dynamic IPv6 address prefix - wide-dhcpc client listening on the ppp0 interface and requesting prefix delegation. The delegated prefix is assigned as new address with given suffix (::1 or from mac address) to the eth0 interface. In fact, as you say: When ppp0 disconnects or reconnects, the wide-dhcp client should not actually remove the delegated prefix from the eth0 interface, but unfortunately it does. The reason for this is the following: the dhcp client stops when the ppp0 interface disappears, so it is restarted in the ifup scripts after the ppp connection was reconnected. When the wide-dhcpc client exits, it will clean up so it removes all addresses assigned - that's the problem. I think this is even more broken than that. Surely, what should happen if the PPPoE link goes down and then comes up again is that the DHCP client should attempt to renew existing DHCP leases, including prefix delegations. Any sensible DHCP server at the ISP should give back the same prefix delegations, so not only should the prefixes not be removed from eth0 just because ppp0 goes down, they will probably not even be deprecated once the PPP link is back. Using dnsmasq to deprecate them once the PPP link goes is the last thing you should do. Indeed! From my feeling the use of DHCP on a PPP interface is a horrible idea. Not even ISC's client supports it, but the providers seem to use it all, see https://datatracker.ietf.org/doc/rfc6204/ - So a fix in ISC's dhcp is long overdue to work with PPP - but e.g., https://bugzilla.redhat.com/show_bug.cgi?id=626514 is open since years! In contrast, wide-DHCP is dead, so no updates since 2008! To me this looks wrong altogether. The prefix should be assigned through the PPP protocol, like nameservers and addresses on IPv4
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, On 25/07/13 11:59, Uwe Schindler wrote: Hi again, In addition, I found a relic from the time when the RA_INTERVAL value was hardcoded into radv.c. There is still one: Line 294: put_opt6_long(1800); /* lifetime - twice RA retransmit */ Should be: put_opt6_long(RA_INTERVAL * 2); /* lifetime - twice RA retransmit */ Yes, that's a bug. I am currently looking into the code to find an easy way how to make the RA_INTERVAL configureable, maybe I can provide a patch. But if it's easy for you, it would be really nice to have this in future versions. So the deprecation of addresses no longer used on the network interface is not my primary concern, more I would prefer to work around the bugs in certain android phones not receiving ICMPv6 messages in standby mode, so the RA_INTERVAL should be configureable (I want to set it to much lower values than 600s, I have a patched version with 6s retransmit running on my debian testing box). Note that RA_INTERVAL is used in the code for two related things. 1) It sets the lifetime values for parameters being sent. At the moment, the router advertisement is set to three times RA_INTERVAL, the DNS server and domain-search params are twice RA_INTERVAL, and prefixes are set to (at least RA_INTERVAL) 2) It sets how often unsolicited RA's are sent. Clearly these are related, the lifetime of parameters must be at least until they can be renewed by another RA, and preferably longer, to allow for packet loss. You probably don't want to reduce the lifetimes, that would be counter- productive for the Android bug. you do want to send RAs more often. The relevant code for that is here: if (difftime(param-now, context-ra_short_period_start) 60.0) /* range 5 - 20 */ context-ra_time = param-now + 5 + (rand16()/4400); else /* range 3/4 - 1 times RA_INTERVAL */ context-ra_time = param-now + (3 * RA_INTERVAL)/4 + ((RA_INTERVAL * (unsigned int)rand16()) 18); Which says that for the first minute after an configuration change, we send RAs every 5- 20 seconds, the actual delay is random. Once the first minute is up, we wait 3/4 of RA_INTERVAL to RA_INTERVAL. It seems to me that the simplest solution might be lock the fast RA mode, and never drop back to the full RA_INTERVAL delay. on a config flag as Android workaround mode This is a good idea, it is also easy to implement as a config flag? Another solution might be to derive the RA retransmit rate from the RA lifetimes, At the moment if you declare a RA prefix with a short lifetime, the lifetime gets extended to be as long as RA_INTERVAL, instead, we could reduce RA_INTERVAL to be the shortest configure lifetime (or actually half of that to allow for lost packets). In general I like the fast RA mode to be enabled with a config flag, but nevertheless, the constant RA_INTERVAL should be configureable, so you can customize it. I agree that lowering RA_INTERVAL currently also makes the lifetimes shorter, which is bad for the android bug. So I would decouple the RDNS, router and prefix lifetimes from RA_INTERVAL and make RA_INTERVAL configureable. In my opinion, the RDNS should have the dhcp--range's lease time as lifetime (minimum RA_INTERVAL). The prefix already has the lease time of the corresponding dhcp-range. The router itself could be in the same lifetime or even longer, especially as the router's link-local address is fixed and never changes. Uwe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, reading https://datatracker.ietf.org/doc/rfc6204/?include_text=1, the requirements for home routers are listed here: L-13: If the delegated prefix changes, i.e., the current prefix is replaced with a new prefix without any overlapping time period, then the IPv6 CE router MUST immediately advertise the old prefix with a Preferred Lifetime of zero and a Valid Lifetime of the lower of the current Valid Lifetime and 2 hours (which must be decremented in real time) in a Router Advertisement message as described in Section 5.5.3, (e) of [RFC4862]. This was my original proposal. I agree that this should be done by the PPP/WAN interface and the DHCPv6 cleint on the WAN interface, so the old prefix gets deprecated, but with current software available (ISC dhcpd does not work on PPP interfaces but would support that using a shell script applying the prefix delegation - and wide-dhcpc supports PPP interfaces, but it allows not to configure prefix delegation, so in deprecates addresses after PPP reconnect or a change of the prefix). So I would be very happy, if dnsmasq (as router advertisement daemon would provide support for this). Radvd does it - see DeprecatePrefix options in radvd. Uwe On 24/07/13 19:16, Uwe Schindler wrote: Hi, RA's are not the same as DHCP, there's no such thing as a lease time. What there is, is preferred and valid lifetimes. What should happen is that when old address is about to go away, the address for that prefix on the network adaptor should have its preferred lifetime set to zero, and dnsmasq will then notice that and send RA's with the preferred lifetime also set to zero. I meant the life time, it was just a typo somehow :-) The idea here was to send preferred_lifetime=0 in RAs for prefixes that disappeared from the interface to inform the clients that they are no longer useable (my provider does not route old prefixes after a reconnect with PPP). Currently you have to set the lifetime very low (which produces more traffic on the wire) or manually delete or switch on/off the network adaptors once the router reconnects or the prefix changes for some reason. My proposal is to keep a list of previous prefixes from the constructor:ethX code and also send those prefixes, but with lifetime=0 to inform all client to no longer use that address. Those 0-lifetime RAs should be sent at least for the length of the original lifetime. Radvd has code to handle this (although it’s a bit buggy). My understanding of this is that it's something that should happen in the DHCP client and/or ISP DHCP server. Ie, when the prefix has to change, the ISP's DHCP server renews the existing prefix delegation, but with the preferred lifetime==0. It also offers a new prefix delegation. The old and new prefixes get installed in the network adaptor with the preferred lifetime values. Dnsmasq starts to advertise the new prefix and continues to advertise the old prefix, but with the pref- lifetime at zero taken from the value in the adaptor. The problem is different in most cases: When you have a dhcp client waiting on an PPPoE connection (e.g. wide-dhcpc, like most consumer routers use - ISC dhcp cannot listen on ppp interfaces unfortunately) and the PPPoE connection gets reconnected/disconnected, the ppp interface is disappears and is later recreated. When its disappearing, the whole set of IP addresses gets lost and they are not deprecated, so dnsmasq will not recognize any deprecation. I have seen your code that propagates the deprecation of existing interfaces in the RAs, but this only works if the prefix/IP address is still existing on the interface, just with preferred lifetime==0. With PPP interfaces disappearing and being recreated, this does not help, because the address is gone (it’s a new instance of the network interface, just with same name). As dnsmasq is mainly for consumer routers which are mostly working with PPP connections, it would be nice to have. Indeed ist more complicated but effect ist he same: For DSL lines you ahev in most cases the following setup: - PPP connection (PPPoE), creating network adaptor ppp0 - this adaptor is coming on going when connections are created/released - LAN interface (on which dnsmasq is listening), eth0, with a static IPv4 address and a dynamic IPv6 address prefix - wide-dhcpc client listening on the ppp0 interface and requesting prefix delegation. The delegated prefix is assigned as new address with given suffix (::1 or from mac address) to the eth0 interface. In fact, as you say: When ppp0 disconnects or reconnects, the wide-dhcp client should not actually remove the delegated prefix from the eth0 interface, but unfortunately it does. The reason
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, RA's are not the same as DHCP, there's no such thing as a lease time. What there is, is preferred and valid lifetimes. What should happen is that when old address is about to go away, the address for that prefix on the network adaptor should have its preferred lifetime set to zero, and dnsmasq will then notice that and send RA's with the preferred lifetime also set to zero. I meant the life time, it was just a typo somehow :-) The idea here was to send preferred_lifetime=0 in RAs for prefixes that disappeared from the interface to inform the clients that they are no longer useable (my provider does not route old prefixes after a reconnect with PPP). Currently you have to set the lifetime very low (which produces more traffic on the wire) or manually delete or switch on/off the network adaptors once the router reconnects or the prefix changes for some reason. My proposal is to keep a list of previous prefixes from the constructor:ethX code and also send those prefixes, but with lifetime=0 to inform all client to no longer use that address. Those 0-lifetime RAs should be sent at least for the length of the original lifetime. Radvd has code to handle this (although it’s a bit buggy). Uwe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] replace radvd with dnsmasq
The host running dsnmasq must have a (more or less static IPv6 address, e.g.
prefix could be assigned by PPP together with dhcpv6-PD), also it must have a
defined suffix (e.g., ::1), otherwise dnsmasq does not know the network.
The config could then be:
dhcp-range=::1,constructor:eth0,ra-stateless,ra-names
The ::1 is the suffix of the static address, constructor defines from which
network adaptor the prefix comes from. This option also enables DHCPv6 - if you
don't want that replace ra-stateless and ra-names by a different option. If you
have a completely static IPv6 (including suffix that never changes), you can
remove the constructor and only list the prefix including suffix. For
maintainability, you should put your options into /etc/dnsmasq.conf and don't
pass then through command line.
In any case, the DHCP start address (which is also used for RAs) must be
assigned to the network adaptor, otherwise dnsmasq prints out a warning that it
cannot find a valid prefix/range..
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq-
discuss-boun...@lists.thekelleys.org.uk] On Behalf Of iw3...@tiscali.it
Sent: Monday, July 15, 2013 11:39 AM
To: dnsmasq-discuss@lists.thekelleys.org.uk
Subject: [Dnsmasq-discuss] replace radvd with dnsmasq
Hi,
I must say first I'm rather new to 'dnsmasq'.
I'm using 'dnsmasq' v2.66 ounder linux:
#
dnsmasq -k --log-facility=- --pid-file=/var/run/dnsmasq.pid --no-poll --
enable-ra --leasefile-ro
dnsmasq[496]: started, version 2.66 cachesize 150
dnsmasq[496]: compile time options: IPv6 GNU- getopt no-DBus no-i18n no-
IDN DHCP DHCPv6 no-scripts no-TFTP no-conntrack ipset auth dnsmasq-dhcp
[496]: IPv6 router advertisement enabled
dnsmasq[496]: failed to load names from /etc/hosts: No such file or directory
I'm trying to configure dnsmasq as a replacement for 'radvd' but It does not
work as expected.
Starting 'radvd' with the following simple config file:
# cat /etc/radvd.
conf
interface eth0 {
AdvSendAdvert on;
prefix 2001:db8:0:1::/64 {
AdvOnLink on;
AdvAutonomous on;
};
};
has the immediate effect of assigning an ipv6 address to the eth0 network
device on the host running 'radvd':
# ip a show dev eth0
2: eth0: BROADCAST,MULTICAST,UP,
LOWER_UP mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 00:03:c5:0c:7c:71 brd ff:
ff:ff:ff:ff:ff
inet 10.0.0.53/8 brd 10.255.255.255 scope global eth0
valid_lft forever
preferred_lft forever
inet6 2001:db8:0:1:203:c5ff:fe0c:7c71/64 scope global dynamic
valid_lft 86393sec preferred_lft 14393sec
inet6 fe80::203:c5ff:fe0c:7c71/64 scope link
valid_lft forever preferred_lft forever
*and* on every other host on the network segment connected to eth0.
I cannot reproduce the same behavior with 'dnsmasq'.
I've tried different configuration
variants without results.
Here are some questions:
How do I tell 'dnsmasq' which ipv6 network
(prefix) it should use ?
Am I supposed to manually assign an ipv6 address to the host before starting
'dnsmasq' ?
Could you please suggest a simple config file for 'dnsmasq' that reproduces
the behavior of 'radvd' ?
thanks you for your attention.
giorgio
Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di
uno spot
in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un amico al
mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/
___
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
[Dnsmasq-discuss] interface-name=name, interface should also create AAAA record, if available
Hi, The config option: interface-name=name,interface should in my opinion also create an record for the given interface, if a global ipv6 address is assigned, so the name returns both A and records. Would this be hard to do? Thanks for the great software, Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
I think this is related to this Android problem: https://code.google.com/p/android/issues/detail?id=32662 As you see, android devices sometimes ignore some packaets of the router advertisements, so if one is sent only once per 10 minutes, it hard for the phone to get them. This is why my previous radvd installation uses: MinRtrAdvInterval 3; MaxRtrAdvInterval 10; I just wanted to have a similar setup on dnsmasq, which was only possible by patching the header file and recompiling dnsmasq. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Uwe Schindler Sent: Tuesday, July 16, 2013 11:15 AM To: 'Albert ARIBAUD'; dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? Hi, But I found a problem, especially happening with mobile phones (Android, Galaxy S3 in my case). When those go into sleep mode, they no longer listen to router advertisements, so after waking up, their address was already deprecated by the network stack and they have to wait for a new RA coming in. Unfortunately this happens too seldom (RA_INTERVAL is 600, means 10 minutes). They don't send any DHCP requests anymore, because the IPv4 DHCP lease is still fine (I have a lease time of 24 hrs for IPv4 leases, but 20 minutes for IPv6 lifetime - because those are not really static - see below). Would it be possible to make the RA_INTERVAL configureable so I can send RAs in a periodic manner like with radvd? I would like to send RAs every 3 or 10 seconds like I had with radvd configured. This is not possible without patching dnsmasq. Regardless of the interest of making the RA period configurable, why doesn't the mobile phone send out a Router Solicitation when it wakes up from sleep mode? That is a good question but for actually 2 android phones this is not done: A Galaxy S3 (Android 4.1) and an older HTC Desire (Android 2.3) don't send Router Solicitations - those do not appear in logs. I think the reason why this happens has to do with the power management. I am not sure if this is 100% correct: When you switch off the screen of an Android phone, the WIFI goes to some kind of power saving mode so it only wakes up sometimes to listen for something going in. Most of the time it is sleeping. Maybe it does not get the Router Adverts in this state, because its just not awake when the router send adverts. When you wake it up, the timeout of the lease (which needs to be short on my networks, for the reasons of updated prefix delegations by the provider) is already reached, so the IPv6 address ist lost. The phone have to wait until a new advert comes in - I have no idea why it does not send router solicitations in this case, but I don't expect this to be fixed, so reconfiguring dnsmasq to send adverts every 6 seconds works perfectly fine here - it only floods the logs, but maybe this can be prevented by syslog to filter duplicate message. I patched the header file to have have RA_INTERVAL = 6 (was previously 600) and rebuilt the debian package. Now it works as expected. So my request here is just to make this configureable (maybe as param to enable-ra). Maybe also don't log *every* RA sent :-) If the following would be fixed, too, I could raise the DHCPv6 lease times to much larger values, because the automatic deprecation of prefix change would help here): A second thing related to RAs: I am living in Germany, where the assigned prefix to local networks is not really static (for privacy reasons), so it changes quite often (every 24hrs, enforced by DHCP prefix delegation on the PPPoE interface). When the prefix changes, dnsmasq should send (like radvd is doing) a zero lease time RA for the old prefix. I found out that dnsmasq.conf can set deprecated as life-time in the dhcp-range, but that would make all RAs going out have a time of 0s. It would be good if dnsmasq would send active prefixes with the given non-zero lifetime, but once a prefix disappears from the network adaptor, send extra RAs do deprecate the old prefix (using the old prefix with time=0) for a number of times. Uwe Amicalement, -- Albert. Thanks, Uwe ___ 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
