Re: [Dnsmasq-discuss] Authoritative zone and no recursion replies
On 15/02/2019 12:54, Petr Mensik wrote: > Hi everyone. > > I think it is handy to be able to delegate some suffix from internal > domain, lets say example.com provided by BIND or any bigger server. But > recursive servers do not set recursive queries on normal delegation. > Delegation is when I just add line into zone file: > > $ORIGIN example.com. > dnsmasq-private IN A 10.0.0.53 > private IN NS dnsmasq-private > > Then query to xy.private.example.com would be forwarded to dnsmasq. It > is great this can be configured by dynamic update of a zone. No change > of configuration is necessary. It requires dnsmasq to be accessible by > recursive resolvers. Great for trusted network configuration. > > Unfortunately, dnsmasq does not cooperate very well with them. Recursive > servers use queries without recursion desired flag set. Dnsmasq tends to > refuse it or servfail if any forwarder is configured. For each host it > reads from /etc/hosts or configured from DHCP, I think it would be nice > to respond also without recursion to every host from hosts. The same way > for DHCP assigned names. AFAIK it is denied to disallow cache probing. > What is point to deny provided names without recursion set, when it > gracefully offers it when recursion is desired? > > compare when at least one server is set: > dig +rec mydnsmasqhost > dig +norec mydnsmasqhost > > where mydnsmasqhost is hostname which obtained address from dnsmasq. > > It just makes delegation from big resolvers difficult. Without auth-zone > with common prefix, it would not work. Is there a good reason for it? If > domain is set, it would be easy to create delegation without need to > auth-zone set. > > My example would work if --auth-zone=private.example.com would be used. > While it is better, why should not --domain private.example.com be > sufficient? It would be quite useful for VM configuration, because > current libvirt does not support adding auth-zone to dnsmasq > configuration file. > > Any comments welcome. > > Have a nice day, > Petr > The behaviour in receiving a query without RD set changed in http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=4139298d287eb5c57f4aa53c459cb02fc5be2495 which doesn't directly help you, but does need to be taken into account. If I understand you correctly, you want the behaviour to change if the query can be answered from configured (/etc/hosts and so on) data, whilst keeping the same behaviour for answers which came from upstream, but are merely cached. To answer the question "What is point to deny provided names without recursion set, when it gracefully offers it when recursion is desired?" The aim is to avoid a client being able to tell the difference between an answer coming from the dnsmasq cache, and one coming from upstream. If RD is set, it will get an answer, either from upstream, or from the cache. It can't tell the difference. The original behaviour with RD _unset_ was to either answer from the cache, or fail (not sending upstream), allowing the client to deduce the contents of the cache. That was changed to always SERVFAIL, and then the latest change is to always forward upstream. The reason given for this is to allow dig +trace to operate through dnsmasq. It seems that actually just ignoring the RD bit i) disallows cache snooping, ii) allows dig +trace to operate. Maybe that should be the behaviour? Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Regarding dnslookup with dnsmasq 2.80 using dig command
There's not really enough information here to be sure, but I think this may be fixed by http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=162e5e0062ce923c494cc64282f293f0ed64fc10 Cheers, Simon. On 05/02/2019 08:18, Debananda Pal wrote: > Hi, > > I have updated dnsmasq from 2.79 to 2.80 in our application and using > dig (DiG 9.12.3-P1) to retrieve record and am using below command : > > Observation on Box 1: > - > # dig localhost +noquestion +noauthority +noadditional +search +noedns > There is no Answer I get > > # dig A localhost +noquestion +noauthority +noadditional +search +noedns > Getting proper answer. > > Observation on Box 2 (Same image of Box 1): > - > # dig localhost +noquestion +noauthority +noadditional +search +noedns > Getting proper answer. > > # dig A localhost +noquestion +noauthority +noadditional +search +noedns > There is no Answer I get > > I am getting proper response with dnsmasq 2.79 version with above command. > > If I remove +search option (with dnsmasq 2.80 installed) I am getting > proper response on both "A" and "". > > Please let me know, if you have any suggestion. > > Regards, > D Pal > > ___ > 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] [PATCH] auth-server without interface
On 15/02/2019 12:09, Petr Mensik wrote: > Hi! > > I was playing a bit with auth-vm and auth-server together with virtual > machine manager. I think it might be useful to omit interface in > auth-server at all, just change name reported by auth-vm zones on normal > dns port. > > Libvirt uses dnsmasq as DHCP and DNS server on each virtual network > configured. It listens just on one interface excluding loopback (virbr0 > for example). If I specify its interface, it stops responding normal > recursive queries on it. I think there is no good reason to demand it. > Anyway, current manual page indicates it is optional... > > Regards, > Petr > It was made optional in this commit. http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=08933475abd0580cff747e3d1e0db3865207a200 Does that adddress the use-case you describe? Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Query forwarding behaviour with multiple name servers.
On 08/02/2019 09:49, John Robson wrote: > Hi all, > > I'm trying to understand the mechanism by which dnsmasq uses the > resolvers specified (in this case they are all specified in > /etc/resolv.conf). > Specifically I am trying to work out why dnsmasq is (erratically) > sending the same query to multiple servers, and not listening beyond the > first response. > > > As I understand it the default (i.e. non dnsmasq) resolver behaviour is > to try the first name server entry first, then the second etc. This can > be changed by use of the 'rotate' option in that file. > > However, dnsmasq reads it's name servers from /etc/resolv.conf, but the > defaults are different - relevant options from the man page say: > *-o, --strict-order* > By default, dnsmasq will send queries to any of the upstream servers > it knows about and tries to favour servers that are known to be up. > Setting this flag forces dnsmasq to try each query with each server > strictly in the order they appear in /etc/resolv.conf > *--all-servers* > By default, when dnsmasq has more than one upstream server > available, it will send queries to just one server. Setting this > flag forces dnsmasq to send all queries to all available servers. > The reply from the server which answers first will be returned to > the original requester. > > To me that means that, by default, dnsmasq will send to any one of the > upstream servers, favouring servers it thinks are up - that seems > reasonable. > > > What I am seeing is that sometimes (and I can't figure a packet count, a > query count, or a time based correlation) dnsmasq forwards a query to > both of the listed name servers (I presume this is part of the > 'aliveness' testing?). > When this happens dnsmasq then only listens to the first reply, meaning > that the server which is slightly slower/further away then gets their > response bounced in an ICMP port unreachable message from the dnsmasq box. > > I then see dnsmasq stick to the 'first responding' server until it > forwards a query to both again (always in the same order, that listed in > /etc/resolv.conf) and, depending on the first response, it either sticks > or flips it's preferred server until ??? > > > Two questions: > - What triggers dnsmasq to forward a query to multiple upstream > resolvers (aside from the first query after startup, which seems reasonable) Kevin answered this. > - Why does dnsmasq not bother to listen for the second (or more) > response - which would surely be useful in terms of timing/aliveness > information, as well as less odd for the upstream server*. Because to do so involves keeping resources around: at least some state and an open network socket. Since a server may never respond, those resources have to be reclaimed at some point (this functions exists already, since no answer may be forthcoming from any server) If dnsmasq is sending queries to a server which never answers, that implies far more resources hanging around during a long timeout, which increases the resource footprint for the daemon, and maybe even provides an DoS attack opportunity. TBH, it never occurred to me that the subsequent replies had any real utility, but I can see that they might. I'm not aware of any DNS server which would react in any way to an ICMP port unreachable. Don't forget that this is UDP. The server sends the reply "fire an forget". I think it would be next to impossible to get the OS to even tell the server that the port unreachable message had been seen. Cheers, Simon. > > Cheers, > > John > > > * I can imagine an upstream server eventually deciding that it is being > used in an amplification attack and just not responding any more. > > > -- > > > ___ > 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] "No IPv6 address available" for bulk request from IXIA DHCPv6 clients
What a strange configuration! I can sort-of explain what's happening here. DHCP is a two-phase process: The server first suggests an address, then the client accepts it and tells the server that it will be using the address. In dnsmasq, the first phase does not reserve an address. It's completely idempotent. The client is given a suggested address, but there's nothing to stop the same address being suggested to another client until the first one comes along and reserves it. The address suggested to a client is determined in part by a hash of the client's MAC address or some other unique feature, so that clashes are very rare. However in this case, you have dhcp ranges holding only two addresses. Whilst the first range has at least one free address, it will be used to suggest the address to use. The hash doesn't work: if there's only one free address, then that will be suggested and the hash can't change it. So when lots of clients come along at once and ask for an address, they all get one of the two addresses from the first dhcp-range. When they come back to comfirm the address, all but two are refused because the address in already in use. If the clients come along one at a time, the addresses that are already committed to the earlier clients don't get suggested, and the clients get an address which they can sucessfuly commit. The fix is to use a more conventional dhcp-range configuration. Another possible fix might be to use the --dhcp-sequential-ip setting. That _might_ behave more sanely under these conditions, but I've not tested it, so no guarantees. Cheers, Simon. On 07/02/2019 10:12, P, Sreelakshmi wrote: > Hi All, > > > > I’m trying to simulate DHCPv6 clients from IXIA and observe that only 1 > or 2 clients gets honored with IPv6 address when simultaneous requests > are sent from 64 clients, but the same thing works if the request is > made one after the other sequentially. > > > > *_Configuration below:_* > > > > log-facility=/var/log/dnsmasq_swns/dnsmasq6.log > > port=0 > > dhcp-script=/usr/bin/dhcp_server_leases > > leasefile-ro > > dhcp-lease-max=64000 > > bind-dynamic > > dhcp-range=set:default+test,2000::e:2,2000::e:3 > > dhcp-range=set:default+test,2000::27:1,2000::27:2 > > dhcp-range=set:default+test,2000::16:1,2000::16:2 > > dhcp-range=set:default+test,2000::7:1,2000::7:2 > > dhcp-range=set:default+test,2000::26:1,2000::26:2 > > dhcp-range=set:default+test,2000::3b:1,2000::3b:2 > > dhcp-range=set:default+test,2000::32:1,2000::32:2 > > dhcp-range=set:default+test,2000::40:1,2000::40:2 > > dhcp-range=set:default+test,2000::28:1,2000::28:2 > > dhcp-range=set:default+test,2000::1b:1,2000::1b:2 > > dhcp-range=set:default+test,2000::3f:1,2000::3f:2 > > dhcp-range=set:default+test,2000::12:1,2000::12:2 > > dhcp-range=set:default+test,2000::9:1,2000::9:2 > > dhcp-range=set:default+test,2000::d:1,2000::d:2 > > dhcp-range=set:default+test,2000::36:1,2000::36:2 > > dhcp-range=set:default+test,2000::24:1,2000::24:2 > > dhcp-range=set:default+test,2000::1f:1,2000::1f:2 > > dhcp-range=set:default+test,2000::34:1,2000::34:2 > > dhcp-range=set:default+test,2000::21:1,2000::21:2 > > dhcp-range=set:default+test,2000::3a:1,2000::3a:2 > > dhcp-range=set:default+test,2000::17:1,2000::17:2 > > dhcp-range=set:default+test,2000::3d:1,2000::3d:2 > > dhcp-range=set:default+test,2000::1:1,2000::1:2 > > dhcp-range=set:default+test,2000::f:1,2000::f:2 > > dhcp-range=set:default+test,2000::22:1,2000::22:2 > > dhcp-range=set:default+test,2000::14:1,2000::14:2 > > dhcp-range=set:default+test,2000::2c:1,2000::2c:2 > > dhcp-range=set:default+test,2000::19:1,2000::19:2 > > dhcp-range=set:default+test,2000::1d:1,2000::1d:2 > > dhcp-range=set:default+test,2000::2:1,2000::2:2 > > dhcp-range=set:default+test,2000::37:1,2000::37:2 > > dhcp-range=set:default+test,2000::a:1,2000::a:2 > > dhcp-range=set:default+test,2000::38:1,2000::38:2 > > dhcp-range=set:default+test,2000::2a:1,2000::2a:2 > > dhcp-range=set:default+test,2000::23:1,2000::23:2 > > dhcp-range=set:default+test,2000::2b:1,2000::2b:2 > > dhcp-range=set:default+test,2000::4:1,2000::4:2 > > dhcp-range=set:default+test,2000::15:1,2000::15:2 > > dhcp-range=set:default+test,2000::8:1,2000::8:2 > > dhcp-range=set:default+test,2000::35:1,2000::35:2 > > dhcp-range=set:default+test,2000::1e:1,2000::1e:2 > > dhcp-range=set:default+test,2000::b:1,2000::b:2 > > dhcp-range=set:default+test,2000::3c:1,2000::3c:2 > > dhcp-range=set:default+test,2000::25:1,2000::25:2 > > dhcp-range=set:default+test,2000::3:1,2000::3:2 > > dhcp-range=set:default+test,2000::33:1,2000::33:2 > > dhcp-range=set:default+test,2000::31:1,2000::31:2 > > dhcp-range=set:default+test,2000::6:1,2000::6:2 > > dhcp-range=set:default+test,2000::18:1,2000::18:2 > > dhcp-range=set:default+test,2000::11:1,2000::11:2 > > dhcp-range=set:default+test,2000::1a:1,2000::1a:2 > > dhcp-range=set:default+test,2000::3e:1,2000::
Re: [Dnsmasq-discuss] Query forwarding behaviour with multiple name servers.
In the case I was seeing ... one of the three servers was returning nxdomain for internal queries (user had defined google as a ‘backup’ resolver). So the subsequent replies had massive value (they contained information, rather than no information). I’ve removed the ‘backup resolver’ from their config, cloud systems get very fast response times from google! On Thu, 7 Mar 2019 at 18:24, Simon Kelley wrote: > On 08/02/2019 09:49, John Robson wrote: > > Hi all, > > > > I'm trying to understand the mechanism by which dnsmasq uses the > > resolvers specified (in this case they are all specified in > > /etc/resolv.conf). > > Specifically I am trying to work out why dnsmasq is (erratically) > > sending the same query to multiple servers, and not listening beyond the > > first response. > > > > > > As I understand it the default (i.e. non dnsmasq) resolver behaviour is > > to try the first name server entry first, then the second etc. This can > > be changed by use of the 'rotate' option in that file. > > > > However, dnsmasq reads it's name servers from /etc/resolv.conf, but the > > defaults are different - relevant options from the man page say: > > *-o, --strict-order* > > By default, dnsmasq will send queries to any of the upstream servers > > it knows about and tries to favour servers that are known to be up. > > Setting this flag forces dnsmasq to try each query with each server > > strictly in the order they appear in /etc/resolv.conf > > *--all-servers* > > By default, when dnsmasq has more than one upstream server > > available, it will send queries to just one server. Setting this > > flag forces dnsmasq to send all queries to all available servers. > > The reply from the server which answers first will be returned to > > the original requester. > > > > To me that means that, by default, dnsmasq will send to any one of the > > upstream servers, favouring servers it thinks are up - that seems > > reasonable. > > > > > > What I am seeing is that sometimes (and I can't figure a packet count, a > > query count, or a time based correlation) dnsmasq forwards a query to > > both of the listed name servers (I presume this is part of the > > 'aliveness' testing?). > > When this happens dnsmasq then only listens to the first reply, meaning > > that the server which is slightly slower/further away then gets their > > response bounced in an ICMP port unreachable message from the dnsmasq > box. > > > > I then see dnsmasq stick to the 'first responding' server until it > > forwards a query to both again (always in the same order, that listed in > > /etc/resolv.conf) and, depending on the first response, it either sticks > > or flips it's preferred server until ??? > > > > > > Two questions: > > - What triggers dnsmasq to forward a query to multiple upstream > > resolvers (aside from the first query after startup, which seems > reasonable) > > Kevin answered this. > > > - Why does dnsmasq not bother to listen for the second (or more) > > response - which would surely be useful in terms of timing/aliveness > > information, as well as less odd for the upstream server*. > > Because to do so involves keeping resources around: at least some state > and an open network socket. Since a server may never respond, those > resources have to be reclaimed at some point (this functions exists > already, since no answer may be forthcoming from any server) If dnsmasq > is sending queries to a server which never answers, that implies far > more resources hanging around during a long timeout, which increases the > resource footprint for the daemon, and maybe even provides an DoS attack > opportunity. TBH, it never occurred to me that the subsequent replies > had any real utility, but I can see that they might. I'm not aware of > any DNS server which would react in any way to an ICMP port unreachable. > Don't forget that this is UDP. The server sends the reply "fire an > forget". I think it would be next to impossible to get the OS to even > tell the server that the port unreachable message had been seen. > > > Cheers, > > Simon. > > > > > > Cheers, > > > > John > > > > > > * I can imagine an upstream server eventually deciding that it is being > > used in an amplification attack and just not responding any more. > > > > > > -- > > > > > > ___ > > 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
