[Dnsmasq-discuss] howto see running configuration?

2018-06-12 Thread Oliver Rath
Hi list,

is there a possibility to see the running configuration in dnsmasq? i.e.
if I use multiple nested configuration files, this would be helpful.

Regards,
Oliver



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


Re: [Dnsmasq-discuss] Slow resolving

2018-06-12 Thread Lars Noodén
On 06/12/2018 11:06 PM, Simon Kelley wrote:
> On 17/05/18 04:33, Lars Noodén wrote:
[snip]
>> Thanks.  By the way does dnsmasq have a Stripe, Patreon, or similar
>> account?  Nearly any non-Paypal thing would be nice.
> 
> There's only a Paypal donation thing, sorry. What's the advantage of the
> others?

tldr; not paypal

The others are easier to use, have better service, and are (probably)
lower risk.

Paypal has worked hard since its early days to earn and maintain a
reputation for being a poor and unreliable service where one is likely
to lose money, not just through their high fees but also through account
holds or even just plain removal of funds.  People I know around here
have had problems with their accounts, and that help put me off, but
similar anecdotes abound at any forum where there have been many who
have used Paypal[1].  There's been enough for so long that it's just too
high a risk.

/Lars

[1] Here are two highly visible samples of many.  They have a knack for
dragging things out:

https://www.snopes.com/fact-check/paypal-class-action-lawsuit/

https://www.consumeraffairs.com/news/class-action-settlement-over-paypal-account-closures-finally-finds-resolution-032817.html

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


Re: [Dnsmasq-discuss] Slow resolving

2018-06-12 Thread Simon Kelley
On 17/05/18 04:33, Lars Noodén wrote:
> On 05/12/2018 01:47 AM, Simon Kelley wrote:
>> On 10/05/18 18:47, Lars Noodén wrote:
> [snip]>> As a work around until I get that sorted, what should I set in
> the mean
>>> time so that dnsmasq does not to forward any DNS queries?  I would like
>>> dnsmasq to just respond when the address=// host names or local=// names
>>> are relevant.
>>
>>
>> Just don't set up any upstream servers and tell dnsmasq not to get any
>> from /etc/resolv.conf with
>>
>> no-resolv
> 
> 
> Thanks.  By the way does dnsmasq have a Stripe, Patreon, or similar
> account?  Nearly any non-Paypal thing would be nice.

There's only a Paypal donation thing, sorry. What's the advantage of the
others?


Cheers,

Simon.


> 
> /Lars
> 
> 
> ___
> 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] Different nameservers for two interfaces

2018-06-12 Thread Angelo Ranieri
Hello.

I have this problem. I have two interfaces (eth0 and wlan0) and I want to
use different nameservers for each interface. My dnsmasq versions is 2.71.

In my configuration the first interface has in dhcp-option (6) the default
gateway (192.168.193.1): all queries are internally resolved using DNS01
and DNS02 taken from resolv.conf file.  The second interface has in
dhcp-option (6) the nameservers DNS11 and DNS12 (different from the
previous ones). I prefer to avoid writing DNS11 and DNS12 namerservers IPs
statically in dnsmasq.conf file: Do you have any suggestion?

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


Re: [Dnsmasq-discuss] [PATCH] dnsmasq.8: uniform formatting style for options

2018-06-12 Thread Simon Kelley
Great work. Patch applied. Many thanks.


Simon.

On 07/06/18 22:13, Peter Pöschl wrote:
> Hi,
> 
> The following patch on top of current master commit 090856c7e6 causes 
> consistent formatting for all options:
> 
> * Always use the long option form, except when options are introduced.
> 
> * Render options in bold, with '--' prefix. 
> 
> Cheers,
> 
>Peter Pöschl
> --
> diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
> index c7e6c88..bf83a74 100644
> --- a/man/dnsmasq.8
> +++ b/man/dnsmasq.8
> @@ -53,13 +53,13 @@ will display DHCPv6 options.
>  Don't read the hostnames in /etc/hosts.
>  .TP
>  .B \-H, --addn-hosts=
> -Additional hosts file. Read the specified file as well as /etc/hosts. If -h 
> is given, read
> +Additional hosts file. Read the specified file as well as /etc/hosts. If 
> \fB--no-hosts\fP is given, read
>  only the specified file. This option may be repeated for more than one
>  additional hosts file. If a directory is given, then read all the files 
> contained in that directory. 
>  .TP
>  .B --hostsdir=
>  Read all the hosts files contained in the directory. New or changed files
> -are read automatically. See --dhcp-hostsdir for details.
> +are read automatically. See \fB--dhcp-hostsdir\fP for details.
>  .TP
>  .B \-E, --expand-hosts
>  Add the domain to simple names (without a period) in /etc/hosts
> @@ -76,7 +76,7 @@ reduce the load on the server at the expense of clients 
> using stale
>  data under some circumstances.
>  .TP
>  .B --dhcp-ttl=
> -As for --local-ttl, but affects only replies with information from DHCP 
> leases. If both are given, --dhcp-ttl applies for DHCP information, and 
> --local-ttl for others. Setting this to zero eliminates the effect of 
> --local-ttl for DHCP.
> +As for \fB--local-ttl\fP, but affects only replies with information from 
> DHCP leases. If both are given, \fB--dhcp-ttl\fP applies for DHCP 
> information, and \fB--local-ttl\fP for others. Setting this to zero 
> eliminates the effect of \fB--local-ttl\fP for DHCP.
>  .TP
>  .B --neg-ttl=
>  Negative replies from upstream servers normally contain time-to-live
> @@ -115,7 +115,7 @@ don't change user id, generate a complete cache dump on 
> receipt on
>  SIGUSR1, log to stderr as well as syslog, don't fork new processes
>  to handle TCP queries. Note that this option is for use in debugging
>  only, to stop dnsmasq daemonising in production, use 
> -.B -k.
> +.B --keep-in-foreground.
>  .TP
>  .B \-q, --log-queries
>  Log the results of DNS queries handled by dnsmasq. Enable a full cache dump 
> on receipt of SIGUSR1. If the argument "extra" is supplied, ie
> @@ -191,7 +191,6 @@ Dnsmasq picks random ports as source for outbound queries:
>  when this option is given, the ports used will always be lower
>  than that specified. Useful for systems behind firewalls.
>  .TP
> -
>  .B \-i, --interface=
>  Listen only on the specified interface(s). Dnsmasq automatically adds
>  the loopback (local) interface to the list of interfaces to use when
> @@ -250,8 +249,8 @@ addresses associated with the interface.
>  .B --local-service
>  Accept DNS queries only from hosts whose address is on a local subnet,
>  ie a subnet for which an interface exists on the server. This option
> -only has effect if there are no --interface --except-interface,
> ---listen-address or --auth-server options. It is intended to be set as
> +only has effect if there are no \fB--interface\fP, \fB--except-interface\fP,
> +\fB--listen-address\fP or \fB--auth-server\fP options. It is intended to be 
> set as
>  a default on installation, to allow unconfigured installations to be
>  useful but also safe from being used for DNS amplification attacks.
>  .TP 
> @@ -294,10 +293,10 @@ addresses appear, it automatically listens on those 
> (subject to any
>  access-control configuration). This makes dynamically created
>  interfaces work in the same way as the default. Implementing this
>  option requires non-standard networking APIs and it is only available
> -under Linux. On other platforms it falls-back to --bind-interfaces mode.
> +under Linux. On other platforms it falls-back to \fB--bind-interfaces\fP 
> mode.
>  .TP
>  .B \-y, --localise-queries
> -Return answers to DNS queries from /etc/hosts and --interface-name which 
> depend on the interface over which the query was
> +Return answers to DNS queries from /etc/hosts and \fB--interface-name\fP 
> which depend on the interface over which the query was
>  received. If a name has more than one address associated with
>  it, and at least one of those addresses is on the same subnet as the
>  interface to which the query was sent, then return only the
> @@ -402,7 +401,7 @@ these services.
>  .B  --rebind-domain-ok=[]|[[//[/]
>  Do not detect and block dns-rebind on queries to these domains. The
>  argument may be either a single domain, or multiple domains surrounded
> -by '/', like the --server syntax, eg. 
> +by '/', like the \fB--server\fP syntax, eg.
>  .B  --rebind-domain-ok=/domain1

Re: [Dnsmasq-discuss] Fwd: [PATCH] Add GetServers call to DBus API

2018-06-12 Thread Simon Kelley
Happy to apply the patch in principle. However the patch as supplied has
unrelated changes to do with using the session, rather than system, bus
when in debug mode. If that's useful, could it become a separate patch,
which also updates the man page for the -d option. If not could it be
removed.


(Just to prove that we do try to read patches before applying them,
here at Dnsmasq Towers.)

Cheers,

Simon.


On 11/06/18 11:43, Gabe 🍰 Krabbe wrote:
> Hi -
> 
> It's currently impossible to tell which upstream DNS servers are in use
> by dnsmasq; this is particularly irksome when they're controlled by
> NetworkManager or similar (grepping for syslog messages doesn't count as
> instrumentation...)
> 
> Here's a trivial implementation of a GetServes DBus call that returns
> the servers/domains (formatted for re-use in --servers flags). Ideally,
> there'd be a call like GetConfig or similar that dumps the entire active
> configuration in config-file format...
> 
> 
> Gabe
> -- 
> Do not think by infection, catching an opinion like a cold.
> 
> 
> ___
> 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] Dnsmasq stops caching for a while on receive of failed or retried lookup?

2018-06-12 Thread Simon Kelley
On 12/06/18 12:21, Mark Fermor, HolidayExtras.com wrote:
> Hello,
> 
> Running dnsmasq with these options:
> /usr/sbin/dnsmasq -k --cache-size=50 --log-facility=- --user=nobody
> --group=nobody --no-hosts --neg-ttl=60 --max-ttl=240 --max-cache-ttl=300
> 
> No local dnsmasq config file so that's literally all the config other
> than defaults applied by dnsmasq
> 
> dnsmasq -v
> Dnsmasq version 2.78  Copyright (c) 2000-2017 Simon Kelley
> Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6
> no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify
> 
> This is something running running in Kubernetes, they run as sidekick
> containers to the main application container. I have multiple of the
> same deployment running in the cluster, so they're all at the same
> versions and receiving equal amounts of traffic via load balancing. They
> all talk to the same endpoints outbound and do the same work load etc.
> I've sent sigusr1 signal to all of the pods individually (all pods have
> been running for approx 48 hours bar pod4 which has been running less
> hours):
> 
> pod1
> I0608 15:11:34.998127       1 nanny.go:116] dnsmasq[19]: time 1528470694
> I0608 15:11:34.998169       1 nanny.go:116] dnsmasq[19]: cache size 50,
> 0/2267416 cache insertions re-used unexpired cache entries.
> I0608 15:11:34.998175       1 nanny.go:116] dnsmasq[19]: queries
> forwarded 3218560, queries answered locally 3182486
> I0608 15:11:34.998180       1 nanny.go:116] dnsmasq[19]: queries for
> authoritative zones 0
> I0608 15:11:34.998184       1 nanny.go:116] dnsmasq[19]: server
> 10.227.240.10#53: queries sent 3218560, retried or failed 16
> 
> pod2
> I0608 15:11:35.909168       1 nanny.go:116] dnsmasq[18]: time 1528470695
> I0608 15:11:35.909206       1 nanny.go:116] dnsmasq[18]: cache size 50,
> 0/197465 cache insertions re-used unexpired cache entries.
> I0608 15:11:35.909211       1 nanny.go:116] dnsmasq[18]: queries
> forwarded 240843, queries answered locally 6159789
> I0608 15:11:35.909216       1 nanny.go:116] dnsmasq[18]: queries for
> authoritative zones 0
> I0608 15:11:35.909219       1 nanny.go:116] dnsmasq[18]: server
> 10.227.240.10#53: queries sent 240843, retried or failed 4
> 
> pod3
> I0608 15:11:36.948015       1 nanny.go:116] dnsmasq[20]: time 1528470696
> I0608 15:11:36.948083       1 nanny.go:116] dnsmasq[20]: cache size 50,
> 0/63648 cache insertions re-used unexpired cache entries.
> I0608 15:11:36.948138       1 nanny.go:116] dnsmasq[20]: queries
> forwarded 46004, queries answered locally 6347223
> I0608 15:11:36.948188       1 nanny.go:116] dnsmasq[20]: queries for
> authoritative zones 0
> I0608 15:11:36.948219       1 nanny.go:116] dnsmasq[20]: server
> 10.227.240.10#53: queries sent 46004, retried or failed 1
> 
> pod4
> I0608 15:11:38.032330       1 nanny.go:116] dnsmasq[24]: time 1528470698
> I0608 15:11:38.032374       1 nanny.go:116] dnsmasq[24]: cache size 50,
> 0/1359727 cache insertions re-used unexpired cache entries.
> I0608 15:11:38.032382       1 nanny.go:116] dnsmasq[24]: queries
> forwarded 1939395, queries answered locally 742411
> I0608 15:11:38.032388       1 nanny.go:116] dnsmasq[24]: queries for
> authoritative zones 0
> I0608 15:11:38.032394       1 nanny.go:116] dnsmasq[24]: server
> 10.227.240.10#53: queries sent 1939395, retried or failed 7
> 
> 
> The problem I notice, is some pods (pod1, pod2, pod4) are forwarding far
> more requests than the other pods (an indication of what other is, would
> be pod3). I'm not sure what's caused this seeing as the application is
> doing the same across all pods. The only thing I notice here, is that
> pods 1/2/4 all have a number of "retried or failed", which the other
> pods don't. Therefore I wonder if the reason that those pods have sent
> so many more requests upstream instead of hitting the cache, is because
> of something to do with a "retried or failed", which then stops the
> cache from working for a decent period of time? I've not been able to
> find anything (google) relating to this scenario but it's the only thing
> that makes sense to me right now. I can accept a couple of failures for
> lookup here and there, but one failure (if i'm onto something that is),
> seems to then cause no cache hits for a large period of time?
> 


There's no reason why a retry would affect the cache, so I think you're
jumping to conclusions there. The "retried or failed" counts are in the
noise: don't forget that DNS uses UDP transport by default, so those
numbers arise from very rare dropped UDP packets - nothing to worry about.


As for the differences in cache hit rates - it could be subtle
synchronisation effects, especialy as all the dnsmasq instances point to
the same upstream. If one pod hits a particular DNS name first, then
that name will end up with a longer TTL in that pod than the others,
which get the record later from the upstream after some of the TTL has
run down. If something makes that happen a lot, that would 

Re: [Dnsmasq-discuss] Reverse IPv6 domain issue

2018-06-12 Thread Simon Kelley
Tracing back through git, that seems to have been broken from birth.

Patch applied. Many thanks.

Simon.



On 09/06/18 00:47, Paul Maddock wrote:
> Hi,
> 
> I think I've come across a bug with how the domain is determined for reverse 
> lookups for IPv6 addresses. Having set a domain config with my domain name 
> and 
> IPv6 prefix I was correctly seeing the domain passed to the clients via 
> DHCPv6, 
> but DNS lookups on the IPv6 returned my fallback domain.
> 
> Having checked the source code I think the problem is in the read_leases 
> function. For IPv6 is appears to be trying to find the domain based on the 
> hwaddr instead of the IPv6 address. I've recompiled with the below patch and 
> I'm now getting the expected domain.
> 
> Please review and apply the fix as necessary.
> 
> 
> --- dnsmasq/src/lease.c 2018-06-08 22:32:29.486011028 +
> +++ dnsmasq/src/lease.c 2018-06-08 22:33:31.118012520 +
> @@ -87,7 +87,7 @@
> if ((lease = lease6_allocate(&addr.addr.addr6, lease_type)))
>   {
> lease_set_iaid(lease, strtoul(s, NULL, 10));
> -   domain = get_domain6((struct in6_addr *)lease->hwaddr);
> +   domain = get_domain6(&lease->addr6);
>   }
>   }
>  #endif
> 
> 
> Regards,
> 
> Paul
> 
> 
> ___
> 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] [ip/address association]

2018-06-12 Thread Simon Kelley
Can you explain exactly what you're trying to do?

Simon.

On 12/06/18 07:05, Michael Mill wrote:
> Hi Simon,
> 
> I am not entirely clear on this. Is there a specific variable which
> contains the relevant IP/information? (In cache.c)
> 
> Thanks,
> Michael.
> 
> On 11/06/2018 18:51, Simon Kelley wrote:
>> daemon-namebuff is justa working variable. Look at the cache.c module
>> for name->IP lookups.
>>
>>
>> Simon.
>>
>>
>> On 11/06/18 11:20, Michael Mill wrote:
>>> Good day,
>>>
>>> I see that the daemon/namebuff value stores the relevant domain
>>> information for the query.
>>> I need the IP address associated with this query.
>>>
>>> Where would i find this?
>>>
>>> Thanks,
>>> Michael.
>>>
>>>
>>> ___
>>> 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
> 

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


[Dnsmasq-discuss] Dnsmasq stops caching for a while on receive of failed or retried lookup?

2018-06-12 Thread Mark Fermor, HolidayExtras.com
Hello,

Running dnsmasq with these options:
/usr/sbin/dnsmasq -k --cache-size=50 --log-facility=- --user=nobody
--group=nobody --no-hosts --neg-ttl=60 --max-ttl=240 --max-cache-ttl=300

No local dnsmasq config file so that's literally all the config other than
defaults applied by dnsmasq

dnsmasq -v
Dnsmasq version 2.78  Copyright (c) 2000-2017 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6
no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify

This is something running running in Kubernetes, they run as sidekick
containers to the main application container. I have multiple of the same
deployment running in the cluster, so they're all at the same versions and
receiving equal amounts of traffic via load balancing. They all talk to the
same endpoints outbound and do the same work load etc. I've sent sigusr1
signal to all of the pods individually (all pods have been running for
approx 48 hours bar pod4 which has been running less hours):

pod1
I0608 15:11:34.998127   1 nanny.go:116] dnsmasq[19]: time 1528470694
I0608 15:11:34.998169   1 nanny.go:116] dnsmasq[19]: cache size 50,
0/2267416 cache insertions re-used unexpired cache entries.
I0608 15:11:34.998175   1 nanny.go:116] dnsmasq[19]: queries forwarded
3218560, queries answered locally 3182486
I0608 15:11:34.998180   1 nanny.go:116] dnsmasq[19]: queries for
authoritative zones 0
I0608 15:11:34.998184   1 nanny.go:116] dnsmasq[19]: server
10.227.240.10#53: queries sent 3218560, retried or failed 16

pod2
I0608 15:11:35.909168   1 nanny.go:116] dnsmasq[18]: time 1528470695
I0608 15:11:35.909206   1 nanny.go:116] dnsmasq[18]: cache size 50,
0/197465 cache insertions re-used unexpired cache entries.
I0608 15:11:35.909211   1 nanny.go:116] dnsmasq[18]: queries forwarded
240843, queries answered locally 6159789
I0608 15:11:35.909216   1 nanny.go:116] dnsmasq[18]: queries for
authoritative zones 0
I0608 15:11:35.909219   1 nanny.go:116] dnsmasq[18]: server
10.227.240.10#53: queries sent 240843, retried or failed 4

pod3
I0608 15:11:36.948015   1 nanny.go:116] dnsmasq[20]: time 1528470696
I0608 15:11:36.948083   1 nanny.go:116] dnsmasq[20]: cache size 50,
0/63648 cache insertions re-used unexpired cache entries.
I0608 15:11:36.948138   1 nanny.go:116] dnsmasq[20]: queries forwarded
46004, queries answered locally 6347223
I0608 15:11:36.948188   1 nanny.go:116] dnsmasq[20]: queries for
authoritative zones 0
I0608 15:11:36.948219   1 nanny.go:116] dnsmasq[20]: server
10.227.240.10#53: queries sent 46004, retried or failed 1

pod4
I0608 15:11:38.032330   1 nanny.go:116] dnsmasq[24]: time 1528470698
I0608 15:11:38.032374   1 nanny.go:116] dnsmasq[24]: cache size 50,
0/1359727 cache insertions re-used unexpired cache entries.
I0608 15:11:38.032382   1 nanny.go:116] dnsmasq[24]: queries forwarded
1939395, queries answered locally 742411
I0608 15:11:38.032388   1 nanny.go:116] dnsmasq[24]: queries for
authoritative zones 0
I0608 15:11:38.032394   1 nanny.go:116] dnsmasq[24]: server
10.227.240.10#53: queries sent 1939395, retried or failed 7


The problem I notice, is some pods (pod1, pod2, pod4) are forwarding far
more requests than the other pods (an indication of what other is, would be
pod3). I'm not sure what's caused this seeing as the application is doing
the same across all pods. The only thing I notice here, is that pods 1/2/4
all have a number of "retried or failed", which the other pods don't.
Therefore I wonder if the reason that those pods have sent so many more
requests upstream instead of hitting the cache, is because of something to
do with a "retried or failed", which then stops the cache from working for
a decent period of time? I've not been able to find anything (google)
relating to this scenario but it's the only thing that makes sense to me
right now. I can accept a couple of failures for lookup here and there, but
one failure (if i'm onto something that is), seems to then cause no cache
hits for a large period of time?

Thanks and Best,
Mark
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss