Re: [Dnsmasq-discuss] Update rebind attack protection to include IP6 delegation
> Some circumstances may be vulnerable to DNS rebinding attacks > against global IPv6 address. Through DHPCv6-PD the local network is > a uniquely identifying global subnet. This makes DNS rebinding to a > local machine on its global IPv6 as easy as traditional RFC1918. It > would be a good idea to eliminate any local network IP (RFC1918 or > otherwise) from global DNS responses. I would consider that a BUG (Actually it does exist as bug ... in AVM Fritz!Boxes). Public IPs are public IPs are public IPs. One of the benefits of IPv6 is, that everybody incl. normal private users, can finally get *public* IPs for all devices. This effectively removes the need to use different IPs (and sometimes even ports) for access to the very same ressources, depending on if you are at home/at your office or outside. That means I can put up a web server on 2001:db8:dead::beef, create an record for it and use that new host name from inside as well as from the outside of my LAN. No need to use 192.168.blah.blubb:80 from inside and bla.dyn.com:88 from the outside So actually I want my hostnames to resolve anywhere, also at home. -- Kind regards Ziggy SpaceRat ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Update rebind attack protection to include IP6 delegation
This is a request for feature feasibility or acceptability. Some circumstances may be vulnerable to DNS rebinding attacks against global IPv6 address. Through DHPCv6-PD the local network is a uniquely identifying global subnet. This makes DNS rebinding to a local machine on its global IPv6 as easy as traditional RFC1918. It would be a good idea to eliminate any local network IP (RFC1918 or otherwise) from global DNS responses. For dnsmasq, this could be implemented with a few options or option variations. One option is to rebind protect range on all DHCP served address, if outside of the normal local IPv4/6 ranges. Another option would add the IPv4/6 discovered on an interface to the rebind protection range. Granted few small installations (dnsmasq user base) have the cash for a global IPv4, but maybe implement this generically for completeness. This could either reuse the current option or create a new option. The following is just a rough concept. --stop-dns-rebind without sub options, it takes its original actions --stop-dns-rebind=dhcp,[tag],[tag],... add DHCPv4/v6 address into the rebind protection range. Tag is optional to include only include limited subnets, else all DHCP server ranges are added. --stop-dns-rebind=interface:name uses the same method as the DHCPv6 construction to obtain the subnet IPv6 prefix. May not work or be implemented for IPv4. --stop-dns-rebind=address:ipv4/v6 just insert any address into the rebind protection range. Notable use case: if you actually have outward facing servers such as http or vpn, then they should probably be on a unique subnet DMZ. If excluding those interfaces in the rebind protection (maybe =dhcp,[tag]), or running a separate dnsmasq instance for the subnet, then such subnet would resolve globally and locally without filtering. Eric ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Update rebind attack protection to include IP6 delegation
This is a request for feature feasibility or acceptability. Some circumstances may be vulnerable to DNS rebinding attacks against global IPv6 address. Through DHPCv6-PD the local network is a uniquely identifying global subnet. This makes DNS rebinding to a local machine on its global IPv6 as easy as traditional RFC1918. It would be a good idea to eliminate any local network IP (RFC1918 or otherwise) from global DNS responses. For dnsmasq, this could be implemented with a few options or option variations. One option is to rebind protect range on all DHCP served address, if outside of the normal local IPv4/6 ranges. Another option would add the IPv4/6 discovered on an interface to the rebind protection range. Granted few small installations (dnsmasq user base) have the cash for a global IPv4, but maybe implement this generically for completeness. This could either reuse the current option or create a new option. The following is just a rough concept. --stop-dns-rebind without sub options, it takes its original actions --stop-dns-rebind=dhcp,[tag],[tag],... add DHCPv4/v6 address into the rebind protection range. Tag is optional to include only include limited subnets, else all DHCP server ranges are added. --stop-dns-rebind=interface:name uses the same method as the DHCPv6 construction to obtain the subnet IPv6 prefix. May not work or be implemented for IPv4. --stop-dns-rebind=address:ipv4/v6 just insert any address into the rebind protection range. Notable use case: if you actually have outward facing servers such as http or vpn, then they should probably be on a unique subnet DMZ. If excluding those interfaces in the rebind protection (maybe =dhcp,[tag]), or running a separate dnsmasq instance for the subnet, then such subnet would resolve globally and locally without filtering. Eric ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Feature enhancement to rebind protection
Sorry, I must have been typing and dumb thumbed the touch bad at the same time for odd results. Please see misplaced thread here: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q1/011922.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Max num of concurrent dns reached troubleshootting
Hi Simon, bottom posting On 1/21/2018 12:55 AM, Simon Kelley wrote: Sounds like you're just tickling the limit. Maybe just increase it with --dns-forward-max Cheers, Simon. On 19/01/18 07:30, john doe wrote: Hi Simon, bottom posting. On 1/18/2018 11:16 PM, Simon Kelley wrote: Use log-queries to see what's happening. You should be looking for outgoing queries which don't see an answer. Cheers, Simon. On 16/01/18 15:34, john doe wrote: Hi, First of all a big thank you for dnsmasq. It's an easy dhcp, dns, read only tftp server to configure. On a perimeterfirewall the logs gets flutted with the following: Jan 15 22:32:23 dnsmasq[546]: Maximum number of concurrent DNS queries reached (max: 150) Jan 16 00:06:34 dnsmasq[546]: Maximum number of concurrent DNS queries reached (max: 150) Note that only one server (gateway) is connected to the perimeterfirewall. How can I determine wherein lies the problem (perimeterfirewall or gateway)? In other words: what should I do to understand what's triggering those messages. Both the gateway and the perimeterfirewall are on Debian 9 using: dnsmasq, systemd-resolved and resolvconf(8). -John ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss Thanks for your answer. The issue I'm facing is not occuring all the time and I'm wandering if 'log-queries' could be only passed to dnsmasq when those messages are logged. In other words: How can I pass options to an already running instance of dnsmasq. I really appriciate any help! :) Indeed increasing that option does the tric! :) It's been a fiew days now that I'm not seeing those messages in the log. I will need to understand why increasing that option works and what are the consequences if any. Thanks for your time and for your help! :) -- John Doe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
