Re: [Dnsmasq-discuss] [PATCH] Add new extensible D-Bus signal
On 13/02/2020 13:58, Victorien Molle wrote:
> Hello Simon,
>
> this is not the final patch. I rewrote the way to build extensible dictionary
> to be able to
> add a vendorclass n times when in IPv6 mode.
>
> Moreover, as I don't really work with IPv6, I don't know if the IPv6 part of
> the code is correct.
> I faced multiple issues:
> 1) I don't really know how to configure dhclient to send n vendorclass
> identifiers
Neither do I, but it seems to be possible using dhcpcd, search for
"vendclass" in the dhcpcd.conf manpage.
> 2) when requesting an IPv6 against DNSMasq, it does not always emit a D-Bus
> signal,
>even if I erase the content of /var/lib/misc/dnsmasq.leases
Wiping the lease database is not obvious, you need to stop dnsmasq,
erase /var/lib/misc/dnsmasq.leases then restart dnsmasq.
> 3) if there is an IPv6 entry in the leases file, DNSMasq will emit a D-Bus
> signal
>when starting/restarting/reloading DNSMasq
I think that's true for IPv4 leases too. Dnsmasq calls the dhcp-script
with an "old" event for all existing leases when it restarts, and the
D-Bus signal is called under the same circumstances. It would be
possible to change this is it was not considered sensible.
>
> About entries in the dictionary, I currently added the 'IP mode' (IPv6 or
> not) to
> be able to correctly parse the dictionary outside of DNSMasq (by a program
> which would
> receive the D-Bus signal). I also want to know if the method I used to
> create/populate
> the dictionary is OK for you.
> To be honest, I don't really know what I can add to this dictionary, so tell
> me what you
> want to include in it.
Look at the --dhcp-script entry in the man page. That has a
comprehensive list of all the data that's made available to the script
that gets run when a lease changes. The same data should go to the D-Bus
signal that happens for the same reason.
the queue_script() function in src/helper.c and the calls to
grab_extradata should give you information about how to access the
various fields.
Cheers,
Simon.
>
> Regards,
> Victorien
>
> On Thu, Feb 13, 2020 at 02:33:15PM +0100, Victorien Molle wrote:
>> For our usage, we need to have more informations sent over D-Bus such as the
>> interface
>> name, the vendor class identifier and the lease expiration time.
>>
>> To achieve this, we add a new D-Bus signal "DhcpLeaseNotification" which
>> exports the
>> requested informations as a dictionnary.
>> It also has the advantage to be flexible if someone wants to add a new entry
>> in the
>> future.
>>
>> Note: in order to get leases extradata be populated, we enabled this feature
>> if D-Bus
>> is enabled in configuration file (this was enabled in the past only if a
>> script was
>> ran on leases updates).
>>
>> Here is an example of the obtained result with a Python3 program:
>>
>> ''' Define our D-Bus callback '''
>> def cb(action, ipaddr, hwaddr, hostname, info):
>> print(f'Action: {action}')
>> print(f'IP: {ipaddr}')
>> print(f'Hostname: {hostname}')
>> for k in info:
>> print(f'{k}: {info.get(k)}')
>>
>> ''' Connect to signal DhcpLeaseNotification on interface
>> uk.org.thekelleys.dnsmasq '''
>> DNSMasq.listen('DhcpLeaseNotification', callback=cb)
>>
>> ''' Run GLib loop '''
>> GLib.MainLoop().run()
>>
>> ''' When DNSMasq receives a DHCP request, here is the result: '''
>>
>> Action: DhcpLeaseAdded
>> IP: 192.168.1.100
>> Hostname: Nucleus.nucle.us
>> interface: br-mgmt
>> expiration: 43200
>> ipv6: 0
>> vendor_class: LaGrosseBiche
>>
>> Signed-off-by: Victorien Molle
>> ---
>> dbus/DBus-interface | 9 ++
>> src/dbus.c | 215 +++-
>> src/dnsmasq.h | 4 +-
>> src/lease.c | 6 +-
>> src/rfc2131.c | 12 +--
>> 5 files changed, 233 insertions(+), 13 deletions(-)
>>
>> diff --git a/dbus/DBus-interface b/dbus/DBus-interface
>> index 954c5b9..ed42551 100644
>> --- a/dbus/DBus-interface
>> +++ b/dbus/DBus-interface
>> @@ -273,14 +273,23 @@ DhcpLeaseAdded
>> ---
>>
>> This signal is emitted when a DHCP lease for a given IP address is created.
>> +This will also trigger the DhcpLeaseNotification signal.
>>
>> DhcpLeaseDeleted
>>
>>
>> This signal is emitted when a DHCP lease for a given IP address is deleted.
>> +This will also trigger the DhcpLeaseNotification signal.
>>
>> DhcpLeaseUpdated
>>
>>
>> This signal is emitted when a DHCP lease for a given IP address is updated.
>> +This will also trigger the DhcpLeaseNotification signal.
>> +
>> +DhcpLeaseNotification
>> +-
>> +
>> +This signal is emitted when a DHCP lease action is triggered. It exports,
>> +as a dictionnary, more informations than the other signals.
>>
>> diff --git a/src/dbus.c b/src/dbus.c
>> index c0ce903..468f393 100644
>> --- a/src/dbus.c
>> +++ b/src/dbus.c
>> @@ -55,6 +55,7 @@ const char* introspection_xml_template =
>> "\n"
>> "
Re: [Dnsmasq-discuss] dnsmasq using 100% of cpu
On 17/02/2020 14:37, Geert Stappers wrote:
> On 17-02-2020 14:31, Donald Sharp wrote:
>
>> Running:
>>
>> sharpd@eva:~/dnsmasq$ /sbin/dnsmasq --version
>> Dnsmasq version 2.80 Copyright (c) 2000-2018 Simon Kelley
>
> 2018, no short-git-hashes nor simular indicators on source version.
>
>
>> Compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua
>> TFTP conntrack ipset auth DNSSEC loop-detect inotify dumpfile
>>
>>
>> When I install several hundred thousand routes into the kernel and
>> remove them( or some variation thereof ), dnsmasq eventually ends up
>> running 100% cpu:
>>
>> top - 18:45:18 up 1 day, 7:44, 1 user, load average: 2.70, 2.65, 2.34
>> Tasks: 424 total, 3 running, 421 sleeping, 0 stopped, 0 zombie
>> %Cpu(s): 12.1 us, 6.9 sy, 0.0 ni, 80.2 id, 0.0 wa, 0.0 hi, 0.7
>> si, 0.0 st
>> MiB Mem : 32131.3 total, 19483.6 free, 6620.3 used, 6027.4
>> buff/cache
>> MiB Swap: 32718.0 total, 31693.0 free, 1025.0 used. 24698.2 avail Mem
>>
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
>> COMMAND
>> 293183 nobody 20 0 11040 2040 1688 R 99.7 0.0 148:48.40
>> dnsmasq
>
>
> The "CPU 100%" made me do `git log` and a "find" on 'CPU'. I found
>
>
> commit df6636bff61aa53ed7ad4b34d940805193c0bc74
> Author: Florent Fourcot
> Date: Mon Feb 11 17:04:44 2019 +0100
>
> lease: prune lease as soon as expired
>
> We detected a performance issue on a dnsmasq running many dhcp sessions
> (more than 10 000). At the end of the day, the server was only releasing
> old DHCP leases but was consuming a lot of CPU.
>
> It looks like curent dhcp pruning:
> 1) it's pruning old sessions (iterate on all current leases). It's
> important to note that it's only pruning session expired since more
> than one second
> 2) it's looking for next lease to expire (iterate on all current leases
> again)
> 3) it launchs an alarm to catch next expiration found in step 2). This
> value can be zero for leases just expired (but not pruned).
>
> So, for a second, dnsmasq could fall in a "prune loop" by doing:
> * Not pruning anything, since difftime() is not > 0
> * Run alarm again with zero as argument
>
> On a server with very large number of leases and releasing often
> sessions, that can waste a very big CPU time.
>
> Signed-off-by: Florent Fourcot
>
>
>
>
>>
>> strace output:
>>
>> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
>> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
>> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
>>
>> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
>> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
>> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
>> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
>> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
>> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=PO^Cstrace: Process
>> 293183 detached
>>
>> I can pretty much make this happen at will. What can I provide to
>> help debug this?
>
> Start with stating how recent the source is that you are using.
>
>
>>
>> As a side note, I was not placing these routes into the default linux
>> routing table. Does dnsmasq need to be paying attention to these routes?
>
> Side notes in a separate thread please.
>
>
>>
>> donald
>>
>
> Regards
>
> Geert Stappers
>
Geert, you're confusing things. It's perfectly clear that the process is
running 100% CPU beacuse the poll() calls are returning an error which
the code is not expecting and doesn't handle. It just calls poll()
again, and because the error wasn't cleared, poll returns immediately
again, rinse and repeat.
The solution is to handle the error (it's not obvious to me how to do
that) or to avoid creating the error condition in the first place.
To get further, we need to know which socket is erroring. It's file
descriptor four in the strace, but is that the netlink socket, or a DHCP
socket or a socket used to talk DNS upstream, or DNS downstream. We
don't know without further information.
Simon.
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNSSEC + No Cache not possible
On 17/02/2020 04:14, Marc Dirsus wrote: > Reffering to this github issue it seems that dnsmasq cant disable > caching when dnssec is enabled. I and other would love to see this > changed. I have a unbound server installed and get statistics from there > that ar way to low because pi-hole or better dnsmasq is caching before. > > i could disable dnssec but i dont want to do that and no one should > disable this. > > https://github.com/pi-hole/FTL/issues/692 > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > The cache is integral to DNSSEC validation because the validation requires the use of a whole set of RRsets. The only way to have all those RRsets is to put them in the cache. It would be possible to have dnsmasq use the cache for DNSSEC validation, but not to answer queries, but that doesn't seem like a particularly useful thing to do. A quick look at the dnsmasq man page shows that we're not afraid to add options, but options really have to make sense and be useful to a significant number of people, not just a way to remove an annoyance in one installation. Your task, therefore, is to show that an option which leaves the cache intact but disables it's use for answering queries, is a generally useful feature. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Say it is homemade when we can't tell
On 17/02/2020 21:10, Geert Stappers wrote: > From: Geert Stappers > > bld/get-version yields UNKNOWN in case no tarball version > or no git commit information is found. > > That UNKNOWN does scare those who are not familiar > with compling / building source code themself. > > Replaced the scary string with HOMEMADE > > Reported-by: Abhishek Patti > --- > bld/get-version | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/bld/get-version b/bld/get-version > index e472aab..71d92d5 100755 > --- a/bld/get-version > +++ b/bld/get-version > @@ -23,7 +23,7 @@ if which git >/dev/null 2>&1 && \ > git describe | sed 's/^v//' > elif grep '\$Format:%d\$' $1/VERSION >/dev/null 2>&1; then > # unsubstituted VERSION, but no git available. > -echo UNKNOWN > +echo HOMEMADE > else > vers=`cat $1/VERSION | sed 's/[(), ]/,/ g' | tr ',' '\n' | grep ^v[0-9]` > > I appreciate the thought, but is HOMEMADE more, or less likely to cause confusion. At least UNKNOWN is always true, whilst a binary reporting HOMEMADE may not be homemade at all. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNS/host lookup delay, how to diagnose?
> > Here is the result of a query that took 5 seconds in 'host':- > > > > Feb 20 09:24:05 newdns dnsmasq[465]: 15 192.168.1.92/52420 query[A] > > esprimo.zbmc.eu from 192.168.1.92 > > Feb 20 09:24:05 newdns dnsmasq[465]: 15 192.168.1.92/52420 /etc/hosts > > esprimo.zbmc.eu is 192.168.1.3 > > Feb 20 09:24:06 newdns dnsmasq[465]: 16 192.168.1.92/52342 query[] > > esprimo.zbmc.eu from 192.168.1.92 > > Feb 20 09:24:06 newdns dnsmasq[465]: 16 192.168.1.92/52342 config > > esprimo.zbmc.eu is NODATA-IPv6 ... > > Chart all compoments, shared the new map with us, tell again the situation. Make a "drawing" like * ISP provides DNS at * router is transparent to DNS-traffic * LAN is 192.168.1.0/24 * on that LAN is server "newdns" running Dnsmasq * Dnsmasq is on LAN authoritive for "domain" zbmc.eu * Local dns data comes from * Client that expriences the problem is ... ... * Command to reproduce the problem is ___ * Observations of the problem __ Geert Stappers In an odd way expressing Seen the posting, good luck with describing the problem -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNS/host lookup delay, how to diagnose?
On Thu, Feb 20, 2020 at 09:54:44AM +, Chris Green wrote: > Here is the result of a query that took 5 seconds in 'host':- > > Feb 20 09:24:05 newdns dnsmasq[465]: 15 192.168.1.92/52420 query[A] > esprimo.zbmc.eu from 192.168.1.92 > Feb 20 09:24:05 newdns dnsmasq[465]: 15 192.168.1.92/52420 /etc/hosts > esprimo.zbmc.eu is 192.168.1.3 > Feb 20 09:24:06 newdns dnsmasq[465]: 16 192.168.1.92/52342 query[] > esprimo.zbmc.eu from 192.168.1.92 > Feb 20 09:24:06 newdns dnsmasq[465]: 16 192.168.1.92/52342 config > esprimo.zbmc.eu is NODATA-IPv6 > Feb 20 09:24:06 newdns dnsmasq[465]: 39 192.168.1.92/52342 query[] > esprimo.zbmc.eu from 192.168.1.92 > Feb 20 09:24:06 newdns dnsmasq[465]: 39 192.168.1.92/52342 config > esprimo.zbmc.eu is NODATA-IPv6 > Feb 20 09:24:11 newdns dnsmasq[465]: 40 192.168.1.92/43165 query[] > esprimo.zbmc.eu from 192.168.1.92 > Feb 20 09:24:11 newdns dnsmasq[465]: 40 192.168.1.92/43165 config > esprimo.zbmc.eu is NODATA-IPv6 > Feb 20 09:24:11 newdns dnsmasq[465]: 41 192.168.1.92/36962 query[MX] > esprimo.zbmc.eu from 192.168.1.92 > Feb 20 09:24:11 newdns dnsmasq[465]: 41 192.168.1.92/36962 config > esprimo.zbmc.eu is NODATA > > So:- > > Why does the query get repeated so many times? Is it because the IPV6 is > failing and > it's retrying? > > Why is there that 5 second delay between 40 and 41? That's presumably > the delay I'm > seeing in the response to the 'host' command. > > Thanks for any explanations and help. Chart all compoments, shared the new map with us, tell again the situation. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Wrong dhcp-renewal-time
Thanks Simon, "infinite" seems to be working fine - I guess something with the year 2038 (?) as it seems that 36250days x 86400sec = 3.132.000.000 which is less than 2^32 (4.294.967.296). I'll see into incorporating the "infinite" stuff in the code. Best, Andrija On Thu, 20 Feb 2020 at 15:35, Simon Kelley wrote: > > > On 20/02/2020 10:49, Andrija Panic wrote: > > Hi all, > > > > first time posting to this ML. > > > > We are using dnsmasq with CloudStack to provide DNS/DHCP services. > > > > Recently we've changed the lease duration to 36250 days (98y, i.e. > > closer to infinity) to make sure that the clients will not renew its > > lease for a lng time (for reasons known to us). > > > > Now, the lease time is sent fine to the client, but the > > dhcp-renewal-time and dhcp-rebinding-time are NOT set to 50% (87.5%) of > > the lease time, but instead to "only" ~650 days, which beats the purpose > > of us increasing it to 36250 days. > > > > Can anyone advise what is happening and if this might be a known issue? > > > > Here's an example from the log (dnsmasq version 2.76 on Debian 9) > > > > root@r-3199-VM:~# cat /var/log/dnsmasq.log > > > > |:| > > |Feb 20 02:21:17 dnsmasq-dhcp[26752]: 3440196161 sent size: 4 option: 51 > > lease-time 36250d| > > |Feb 20 02:21:17 dnsmasq-dhcp[26752]: 3440196161 sent size: 4 option: 58 > > T1 649d19h57m19s| > > > > Feb 20 02:21:17 dnsmasq-dhcp[26752]: 3440196161 sent size: 4 option: 59 > > T2 649d19h57m20s > > > > > > Thanks, > > > > -- > > > > Andrija Panić > > > > These times are 32-bit values, expressed in seconds, so I suspect that > your 98 years has overflowed the variable. Either that or the > end-of-lease time is after 2038, and you're running on a platform with > 32bt time_t, and have overflowed that. > > Instead of messing with very long lease times, why not just set the > lease time to "infinite", which should solve these problems. > > Simon. > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -- Andrija Panić ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Wrong dhcp-renewal-time
On 20/02/2020 10:49, Andrija Panic wrote: > Hi all, > > first time posting to this ML. > > We are using dnsmasq with CloudStack to provide DNS/DHCP services. > > Recently we've changed the lease duration to 36250 days (98y, i.e. > closer to infinity) to make sure that the clients will not renew its > lease for a lng time (for reasons known to us). > > Now, the lease time is sent fine to the client, but the > dhcp-renewal-time and dhcp-rebinding-time are NOT set to 50% (87.5%) of > the lease time, but instead to "only" ~650 days, which beats the purpose > of us increasing it to 36250 days. > > Can anyone advise what is happening and if this might be a known issue? > > Here's an example from the log (dnsmasq version 2.76 on Debian 9) > > root@r-3199-VM:~# cat /var/log/dnsmasq.log > > |:| > |Feb 20 02:21:17 dnsmasq-dhcp[26752]: 3440196161 sent size: 4 option: 51 > lease-time 36250d| > |Feb 20 02:21:17 dnsmasq-dhcp[26752]: 3440196161 sent size: 4 option: 58 > T1 649d19h57m19s| > > Feb 20 02:21:17 dnsmasq-dhcp[26752]: 3440196161 sent size: 4 option: 59 > T2 649d19h57m20s > > > Thanks, > > -- > > Andrija Panić > These times are 32-bit values, expressed in seconds, so I suspect that your 98 years has overflowed the variable. Either that or the end-of-lease time is after 2038, and you're running on a platform with 32bt time_t, and have overflowed that. Instead of messing with very long lease times, why not just set the lease time to "infinite", which should solve these problems. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Wrong dhcp-renewal-time
Hi all, first time posting to this ML. We are using dnsmasq with CloudStack to provide DNS/DHCP services. Recently we've changed the lease duration to 36250 days (98y, i.e. closer to infinity) to make sure that the clients will not renew its lease for a lng time (for reasons known to us). Now, the lease time is sent fine to the client, but the dhcp-renewal-time and dhcp-rebinding-time are NOT set to 50% (87.5%) of the lease time, but instead to "only" ~650 days, which beats the purpose of us increasing it to 36250 days. Can anyone advise what is happening and if this might be a known issue? Here's an example from the log (dnsmasq version 2.76 on Debian 9) root@r-3199-VM:~# cat /var/log/dnsmasq.log : Feb 20 02:21:17 dnsmasq-dhcp[26752]: 3440196161 sent size: 4 option: 51 lease-time 36250d Feb 20 02:21:17 dnsmasq-dhcp[26752]: 3440196161 sent size: 4 option: 58 T1 649d19h57m19s Feb 20 02:21:17 dnsmasq-dhcp[26752]: 3440196161 sent size: 4 option: 59 T2 649d19h57m20s Thanks, -- Andrija Panić ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNS/host lookup delay, how to diagnose?
On Thu, Feb 20, 2020 at 09:22:05AM +, Chris Green wrote: > > P.S. > > Here is assumed that original poster found in manual page: > > > > --log-queries > > Log the results of DNS queries handled by dnsmasq. > > Yes, thanks, I'll be trying that but I wasn't sure how much timing > information it would provide. > Here is the result of a query that took 5 seconds in 'host':- Feb 20 09:24:05 newdns dnsmasq[465]: 15 192.168.1.92/52420 query[A] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:05 newdns dnsmasq[465]: 15 192.168.1.92/52420 /etc/hosts esprimo.zbmc.eu is 192.168.1.3 Feb 20 09:24:06 newdns dnsmasq[465]: 16 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 16 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 17 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 17 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 18 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 18 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 19 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 19 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 20 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 20 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 21 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 21 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 22 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 22 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 23 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 23 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 24 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 24 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 25 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 25 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 26 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 26 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 27 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 27 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 28 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 28 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 27 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 28 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 28 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 29 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 29 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 30 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 30 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 31 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 31 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 32 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 32 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 33 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 33 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 34 192.168.1.92/52342 query[] esprimo.zbmc.eu from 192.168.1.92 Feb 20 09:24:06 newdns dnsmasq[465]: 34 192.168.1.92/52342 config esprimo.zbmc.eu is NODATA-IPv6 Feb 20 09:24:06 newdns dnsmasq[465]: 35 192.168
Re: [Dnsmasq-discuss] DNS/host lookup delay, how to diagnose?
On Thu, Feb 20, 2020 at 07:36:02AM +0100, Geert Stappers wrote: > On Wed, Feb 19, 2020 at 10:16:17PM +, Chris Green wrote: > > I have a small home LAN with a number of machines running (mostly) > > xubuntu versions 19,10 and 18.04. > > > > I have a local DNS/DHCP server machine (a Raspberry Pi) running dnsmasq. > > ambiguous, Because I can read > > } I have a local DNS/DHCP server machine implemented by running dnsmasq. > } I have a local DNS/DHCP server machine that is also running dnsmasq. > Yes, sorry. 192.168.1.1 - Draytek router with DHCP/DNS turned off. 192.168.1.3 - Desktop running xubuntu 19.10 192.168.1.4 - Raspberry Pi running DHCP and DNS for LAN, Raspbian GNU/Linux, dnsmasq version 2.76 192.168.1.x - Other machines running xubuntu etc. DHCP assigned addresses > > > If I reboot one of my machines and then do a DNS query using 'host' > > for a local machine the first (and only the first) response takes a > > long time. The correct IP address is returned instantly but then > > there is a long (5 seconds) delay before getting back to the command > > prompt. Subsequent searches are much faster. > > Thus the DNS on the Raspberry Pi is providing the initial response to the query but the client's local dnsmasq cache is providing the response to subsequent queries (xubuntu installs dnsmasq for local DNS caching). > > Presumably the faster subsequent responses are down to the local DNS > > cache in the client machine but why am I getting that five second > > delay for the first request? > > > > How can I diagnose this? > > Chart all compoments, shared the new map with us, tell again the situation. > > > Regards > Geert Stappers > > P.S. > Here is assumed that original poster found in manual page: > > --log-queries > Log the results of DNS queries handled by dnsmasq. Yes, thanks, I'll be trying that but I wasn't sure how much timing information it would provide. -- Chris Green ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
