[Dnsmasq-discuss] Max num of concurrent dns reached troubleshootting

[john doe]

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

[Simon Kelley]

Use log-queries to see what's happening. You should be looking for
outgoing queries which don't see an answer.


Cheers,

Simon.

Post by john doe
Hi,
First of all a big thank you for dnsmasq.
It's an easy dhcp, dns, read only tftp server to configure.
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.
dnsmasq, systemd-resolved and resolvconf(8).
-John

[john doe]

Hi Simon, bottom posting.

Post by Simon Kelley
Use log-queries to see what's happening. You should be looking for
outgoing queries which don't see an answer.
Cheers,
Simon.

Post by john doe
Hi,
First of all a big thank you for dnsmasq.
It's an easy dhcp, dns, read only tftp server to configure.
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.
dnsmasq, systemd-resolved and resolvconf(8).
-John

_______________________________________________
Dnsmasq-discuss mailing list
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! :)

[Simon Kelley]

Sounds like you're just tickling the limit. Maybe just increase it with

--dns-forward-max


Cheers,

Simon.

Post by john doe
Hi Simon, bottom posting.

Post by Simon Kelley
Use log-queries to see what's happening. You should be looking for
outgoing queries which don't see an answer.
Cheers,
Simon.

Post by john doe
Hi,
First of all a big thank you for dnsmasq.
It's an easy dhcp, dns, read only tftp server to configure.
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.
dnsmasq, systemd-resolved and resolvconf(8).
-John

_______________________________________________
Dnsmasq-discuss mailing list
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! :)

[john doe]

Hi Simon, bottom posting

Post by Simon Kelley
Sounds like you're just tickling the limit. Maybe just increase it with
--dns-forward-max
Cheers,
Simon.

Post by john doe
Hi Simon, bottom posting.

Post by Simon Kelley
Use log-queries to see what's happening. You should be looking for
outgoing queries which don't see an answer.
Cheers,
Simon.

Post by john doe
Hi,
First of all a big thank you for dnsmasq.
It's an easy dhcp, dns, read only tftp server to configure.
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.
dnsmasq, systemd-resolved and resolvconf(8).
-John

_______________________________________________
Dnsmasq-discuss mailing list
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! :)

[Eric Luehrsen]

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

[Ziggy SpaceRat]

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

[Eric Luehrsen]

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