Re: [Dnsmasq-discuss] Syntax for multiple listen addresses

2023-07-17 Thread Chris Green
On Mon, Jul 17, 2023 at 03:44:31PM +, Donald Muller wrote:
>There is a tag set with the name of the interface automatically for
>each request. You can use this tag to set the options for each
>interface. It is documented in the man page.

Isn't that all to do with DHCP though?  My problem is entirely DNS.

-- 
Chris Green

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


Re: [Dnsmasq-discuss] Syntax for multiple listen addresses

2023-07-17 Thread Petr Menšík
I tend to use lsof -np $(pidof dnsmasq) to know where is my instance 
listening.


Manual page does not mention delimiter by comma. I think the second 
variant is expected to work and documented way.


Cheers,
Petr

On 17. 07. 23 16:56, Chris Green wrote:

I'm sure this must be in the man page somewhere but I can't find it.
If dnsmasq is to listen on more than one address how do you put this
in the configuration file?

I.e. is it:-
 listen-address=192.168.1.2,127.0.0.1

or is it:-
 listen-address=192.168.1.2
 listen-address=127.0.0.1

Or will either work?


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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


Re: [Dnsmasq-discuss] Syntax for multiple listen addresses

2023-07-17 Thread Chris Green
On Mon, Jul 17, 2023 at 05:34:54PM +0200, Geert Stappers wrote:
> On Mon, Jul 17, 2023 at 03:56:42PM +0100, Chris Green wrote:
> > I'm sure this must be in the man page somewhere but I can't find it.
> > If dnsmasq is to listen on more than one address how do you put this
> > in the configuration file?
> > 
> > I.e. is it:-
> > listen-address=192.168.1.2,127.0.0.1
> > 
> > or is it:-
> > listen-address=192.168.1.2
> > listen-address=127.0.0.1
> > 
> > Or will either work?
> > 
> 
> sudo ss -plut | grep domain
> 
You had me confused for a minute Gert but of course you're telling me
that the above command will show what addresses dnsmasq is listening
on and thus whether my "listen-address=192.168.1.2,127.0.0.1" is doing
what I want.

It is doing what I want! :-)

Thank you.

-- 
Chris Green

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


Re: [Dnsmasq-discuss] Syntax for multiple listen addresses

2023-07-17 Thread Geert Stappers
On Mon, Jul 17, 2023 at 03:56:42PM +0100, Chris Green wrote:
> I'm sure this must be in the man page somewhere but I can't find it.
> If dnsmasq is to listen on more than one address how do you put this
> in the configuration file?
> 
> I.e. is it:-
> listen-address=192.168.1.2,127.0.0.1
> 
> or is it:-
> listen-address=192.168.1.2
> listen-address=127.0.0.1
> 
> Or will either work?
> 

sudo ss -plut | grep domain


Groeten
Geert Stappers
-- 
Silence is hard to parse

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


Re: [Dnsmasq-discuss] Syntax for multiple listen addresses

2023-07-17 Thread Donald Muller
There is a tag set with the name of the interface automatically for each 
request. You can use this tag to set the options for each interface. It is 
documented in the man page.

Sent from my iPhone. Please excuse typos and autocorrection errors.

“One of the saddest lessons of history is this: If we’ve been bamboozled long 
enough, we tend to reject any evidence of the bamboozle. We’re no longer 
interested in finding out the truth. The bamboozle has captured us. It’s simply 
too painful to acknowledge, even to ourselves, that we’ve been taken. Once you 
give a charlatan power over you, you almost never get it back.” - Carl Sagan

From: Dnsmasq-discuss  on 
behalf of Chris Green 
Sent: Monday, July 17, 2023 10:56:42 AM
To: dnsmasq-discuss@lists.thekelleys.org.uk 

Subject: [Dnsmasq-discuss] Syntax for multiple listen addresses

I'm sure this must be in the man page somewhere but I can't find it.
If dnsmasq is to listen on more than one address how do you put this
in the configuration file?

I.e. is it:-
listen-address=192.168.1.2,127.0.0.1

or is it:-
listen-address=192.168.1.2
listen-address=127.0.0.1

Or will either work?

--
Chris Green

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


[Dnsmasq-discuss] Very odd sequence of replies to 'host'

2023-07-17 Thread Chris Green
There's something very odd going on with my dnsmqsq.  The following
sequence of 'host' commands was run on one of my client machines on my
home LAN.  This machine has a very minimal /etc/dnsmasq.conf as
follows:- 
resolv-file=/run/NetworkManager/no-stub-resolv.conf

The file /run/NetworkManager/no-stub-resolv.conf is:-

# Generated by NetworkManager
search zbmc.eu
nameserver 192.168.1.2

/etc/resolv.conf is:-
nameserver 127.0.0.1


... and here is the sequence of host commands, they were done at
manual typing speed, i.e. in a few tens of seconds overall, no long
waits between them.

chris$ host -a jacquibennett.com 127.0.1.1
Trying "jacquibennett.com"
Using domain server:
Name: 127.0.1.1
Address: 127.0.1.1#53
Aliases: 

Host jacquibennett.com not found: 4(NOTIMP)
Received 35 bytes from 127.0.1.1#53 in 16 ms
chris$ host jacquibennett.com 127.0.1.1
Using domain server:
Name: 127.0.1.1
Address: 127.0.1.1#53
Aliases: 

jacquibennett.com has address 153.92.6.161
jacquibennett.com has IPv6 address 2a02:4780:a:1080:0:174b:7855:7
Host jacquibennett.com not found: 2(SERVFAIL)
chris$ 
chris$ 
chris$ 
chris$ host jacquibennett.com 127.0.1.1
Using domain server:
Name: 127.0.1.1
Address: 127.0.1.1#53
Aliases: 

jacquibennett.com has address 153.92.6.161
jacquibennett.com has IPv6 address 2a02:4780:a:1080:0:174b:7855:7
jacquibennett.com mail is handled by 5 mx1.hostinger.com.
jacquibennett.com mail is handled by 10 mx2.hostinger.com.
chris$ 

Why am I getting different answers each time, it's crazy!

It's almost as if there's more than one process listening for DNS
requests and they answer at random.  I obviously have something very
wrong somewhere but I don't really know how to diagnose this.


-- 
Chris Green

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


[Dnsmasq-discuss] Syntax for multiple listen addresses

2023-07-17 Thread Chris Green
I'm sure this must be in the man page somewhere but I can't find it.
If dnsmasq is to listen on more than one address how do you put this
in the configuration file?

I.e. is it:-
listen-address=192.168.1.2,127.0.0.1

or is it:-
listen-address=192.168.1.2
listen-address=127.0.0.1

Or will either work?

-- 
Chris Green

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


Re: [Dnsmasq-discuss] [PATCH] TCP client timeout setting

2023-07-17 Thread Geert Stappers
On Fri, May 19, 2023 at 01:40:30PM +0200, Petr Menšík wrote:
> When analysing report [1] for non-responding queries over TCP, I have found
> forwarded TCP connections have quite high timeout. If for whatever reason
> the forwarder currently set as a last used forwarder is dropping packets
> without reject, the TCP will timeout for about 120 seconds on my system.
> That is way too much, I think any TCP clients will give up far before that.
> This is just quick workaround to improve the situation, not final fix.
> 
> The problem is if the client chooses to use TCP for whatever reason, dnsmasq
> will never switch to actually working server until some UDP request arrives
> to trigger re-evaluation of last_server responsiveness. It might do so, but
> just inside single TCP process. It just stubbornly forwards even 5th retry
> to the same server now, when another one might be able to answer right away.
> 
> I think the proper solution would be implementation of event driven reading
> of TCP sockets in the main process. I don't think using threads is possible,
> because quite a lot of globals used. It should not fork another processes
> without --no-daemon parameter, but just use poll() to watch socket
> readiness, then read whatever is prepared already. Since TCP DNS message
> says its length at the start, it can just allocate buffer big enough for
> that connection and iteratively read without blocking. Once it is read, it
> can parse it, process it. A bit of socket magic would be required, but
> similar approach could solve also sending with multiple calls without
> blocking. That would be big change however.
> 
> I think some feedback should be delivered to main dnsmasq process from tcp
> processing children, just like cache is updated from cache_end_insert(). I
> think it should be able to switch last_server used due to feedback from tcp
> client process. I even think there should be different last_server for UDP
> and different for TCP, but not untill TCP can report issues too. But not
> sure what approach to choose. At first I though about special F_flag, but
> all bits for cache record (struct crec) are already used.
> 
> Alternative quick-fix might be in case the TCP request sending fails to some
> server to generate UDP request with EDNS header added from tcp child process
> to main process UDP socket. It would ensure UDP check is done at the main
> process, which might change current used resolver for following TCP
> connections too.
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2160466
> 
> -- 
> Petr Menšík
> Software Engineer, RHEL
> Red Hat, http://www.redhat.com/
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

> From c02cfcb0a358e04636ffd2bcc595860b25b3a440 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
> Date: Wed, 17 May 2023 21:40:19 +0200
> Subject: [PATCH] Add --dns-tcp-timeout option
> 
> Changes send timeout of outgoing TCP connections. Allows waiting just
> short time for successful connection before trying another server.
> Makes possible faster switch to working server if previous is not
> responding. Default socket timeout seems too high for DNS connections.
> ---
>  man/dnsmasq.8 |  4 
>  src/config.h  |  1 +
>  src/dnsmasq.h |  1 +
>  src/forward.c | 10 --
>  src/option.c  | 10 +-
>  5 files changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
> index 30429df..94fd5b1 100644
> --- a/man/dnsmasq.8
> +++ b/man/dnsmasq.8
> @@ -860,6 +860,10 @@ where this needs to be increased is when using 
> web-server log file
>  resolvers, which can generate large numbers of concurrent queries. This
>  parameter actually controls the number of concurrent queries per server 
> group, where a server group is the set of server(s) associated with a single 
> domain. So if a domain has it's own server via --server=/example.com/1.2.3.4 
> and 1.2.3.4 is not responding, but queries for *.example.com cannot go 
> elsewhere, then other queries will not be affected. On configurations with 
> many such server groups and tight resources, this value may need to be 
> reduced.
>  .TP
> +.B --dns-tcp-timeout=
> +Sets send timeout for forwarded TCP connections. Can be used to reduce time 
> of waiting
> +for successful TCP connection. Default value 0 skips the change of it.
> +.TP

Missing information about sane values.


>  .B --dnssec
>  Validate DNS replies and cache DNSSEC data. When forwarding DNS queries, 
> dnsmasq requests the 
>  DNSSEC records needed to validate the replies. The replies are validated and 
> the result returned as 
> diff --git a/src/config.h b/src/config.h
> index 88cf72e..5fd5cdf 100644
> --- a/src/config.h
> +++ b/src/config.h
> @@ -61,6 +61,7 @@
>  #define LOOP_TEST_TYPE T_TXT
>  #define DEFAULT_FAST_RETRY 1000 /* ms, default delay before fast retry */
>  #define STALE_CACHE_EXPIRY 86400 /* 1 day in secs, default maximum expiry 
> time for stale cache data */
> +#define TCP_TIMEOUT 0 /* timeout of 

Re: [Dnsmasq-discuss] [PATCH] TCP client timeout setting

2023-07-17 Thread Geert Stappers
On Fri, May 26, 2023 at 05:19:49PM +0100, Simon Kelley wrote:
> On 25/05/2023 20:32, Petr Menšík wrote:
> > This problem is best tested by an example, taken from [2] but a bit
> > modified.
> > 
> > Let's create hepothetical network issue with one forwarder, which worked
> > fine a while ago.
> > 
> > $ sudo iptables -I INPUT -i lo -d 127.0.0.255 -j DROP
> > 
> > Now start dnsmasq and send tcp query to it
> > 
> > $ dnsmasq -d --log-queries --port 2053 --no-resolv --conf-file=/dev/null 
> > --server=127.0.0.255 --server=127.0.0.1
> > $ dig +tcp @localhost -p 2053 test
> > 
> > ;; communications error to ::1#2053: timed out
> > ;; communications error to ::1#2053: timed out
> > ;; communications error to ::1#2053: timed out
> > ;; communications error to 127.0.0.1#2053: timed out
> > 
> > ; <<>> DiG 9.18.15 <<>> +tcp @localhost -p 2053 test
> > ; (2 servers found)
> > ;; global options: +cmd
> > ;; no servers could be reached
> > 
> > Because dig waits much shorter time than dnsmasq does, it never receives
> > any reply. Even when the other server is responding just fine. That is
> > main advantage of having local cache running, isn't it? It should
> > improve things!
> > 
> > Now lets be persistent and keep trying:
> > 
> > $ time for TRY in {1..6}; do dig +tcp @localhost -p 2053 test; done
> > 
> > After few timeouts, it will finally notice something is wrong and tries
> > also the second server, which will answer fast. However this works only
> > with dnsmasq -d, which is not used in production. If I replace it with
> > dnsmasq -k, it will not answer at all!
> > 
> > $ dnsmasq -k --log-queries --port 2053 --no-resolv --conf-file=/dev/null 
> > --server=127.0.0.255 --server=127.0.0.1
> > $ time for TRY in {1..8}; do dig +tcp @localhost -p 2053 test; done
> > 
> > ...
> > ;; communications error to ::1#2053: timed out
> > ;; communications error to ::1#2053: timed out
> > ;; communications error to ::1#2053: timed out
> > ;; communications error to 127.0.0.1#2053: timed out
> > 
> > ; <<>> DiG 9.18.15 <<>> +tcp @localhost -p 2053 test
> > ; (2 servers found)
> > ;; global options: +cmd
> > ;; no servers could be reached
> > 
> > 
> > real    5m20,602s
> > user    0m0,094s
> > sys    0m0,115s
> > 
> > This is because with -k it spawns tcp workers, which start always with
> > whatever last_server prepared by last UDP. And until any UDP query
> > arrives to save the day, it will stubbornly try non-responding server
> > first. Even when the other one answers in miliseconds. Notice it have
> > been trying 5 minutes without success.
> > 
> > I think this has to be fixed somehow. This is corner case, because TCP
> > queries are usually caused by UDP queries with TC bit set. But there
> > exist real-world examples, where TCP only query makes sense. But dnsmasq
> > does not handle them well. Summarized this at [3].
> > 
> > My proposal would be sending UDP query + EDNS0 header in case sending
> > query failed to the main process, which can then trigger forwarders
> > responsiveness and change the last_server to a working one. So
> > subsequent attempts do not fall into the blackhole again and again.
> > EDNS0 header would be there to increase chance for a positive reply from
> > upstream, which can be cached.
> > 
> > Would you have other ideas, how to solve this problem?
> > 
> > Cheers,
> > Petr
> > 
> 
> 
> The long delay awaiting a connection from a non-responsive server may be
> improved by reducing the value of the TCP_SYNCNT socket option, at least on
> Linux.
> 
> 
> I think it's pretty easy to pass back the identity of a server which is
> responding to TCP connections to the main process using the same mechanism
> that passes back cache entries. The only wrinkle is if the list of servers
> changes between forking the child process and is sending back data about
> which server worked, for instance is the srever list gets reconfigured.
> Detecting that just needs an "epoch" counter to be included. It's rare, so
> just rejecting a "use this server" update from a child that was spawned in a
> different epoch from the current one should avoid problems. Provided the
> epoch is the same, indices into the server[] array are valid to send across
> the pipe.
> 
> I like the idea of using a different valid server for TCP and UDP.
> 
> Note that the TCP code does try to pick a good server. It's not currently
> much good with long connection delays, but it does cope with ignoring a
> server which accepts connections and then immediately closes them.
> I guess that must have been a real-world problem sometime.

No one claimt yet it is a real-world problem.
 
> Cheers,
> 
> Simon.
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=2160466#c6
> > [3] https://bugzilla.redhat.com/show_bug.cgi?id=2160466#c13
> > 
> > On 19. 05. 23 13:40, Petr Menšík wrote:
> > > When analysing report [1] for non-responding queries over TCP, I
> > > have found forwarded TCP connections have quite high timeout. If for
> > > whatever reason 

Re: [Dnsmasq-discuss] Problem with 127.0.1.1 versus 127.0.0.1

2023-07-17 Thread Chris Green
On Mon, Jul 17, 2023 at 11:30:18AM +0200, Petr Menšík wrote:
> What is specified in dnsmasq does not matter. host by default does not 
> talk to dnsmasq directly. It reads /etc/resolv.conf and uses nameserver 
> specified there. If that is IP of dnsmasq, okay. If it is not, well, the 
> problem might be elsewhere. Because I don't know what is there, I cannot 
> help.
> 
Ah, yes, sorry I understand now,  /etc/resolv.conf is:-

nameserver 127.0.0.1

> If you do "dig @localhost jacquibennett.com", then you are asking 
> dnsmasq explicitly. Just "dig jacquibennett.com" uses server in 
> /etc/resolv.conf, which may not even contain localhost address at all. 
> That is why I have asked what is there.
> 
> On 17. 07. 23 9:00, Chris Green wrote:
> > On Sun, Jul 16, 2023 at 11:58:38PM +0200, Petr Menšík wrote:
> >> I think you have failed to show us what is in /etc/resolv.conf on the
> >> machine, which is running host command.
> >>
> > It's specified in /etc/dnsmasq.conf:-
> >
> >  resolv-file=/run/NetworkManager/no-stub-resolv.conf
> >
> > ... and the contents are:-
> >
> >  # Generated by NetworkManager
> >  search zbmc.eu
> >  nameserver 192.168.1.2
> >
> >> unless listen-address or interface is specified, it should listen on all
> >> interfaces.
> >>
> > Yes, that's what I thought.
> >
> >
> >> Try using host -v jacquibennett.com, it might provide more details what
> >> exactly has timed out.
> >>
> >> If unsure what is host contacting, try separate queries to server
> >> specified explicitly:
> >>
> >> - host -v jacquibennett.com 127.0.0.1
> >> - host -v jacquibennett.com 127.0.1.1
> >>
> >> That might provide hints what is failing and what is working.
> >>
> > Ah, thank you, I hadn't thought to check options for the host command,
> > I had been using dig to look deeper.
> >
> > Typically when I tried just now both the above host commands worked
> > instantly with no errors!  I'll have to keep trying to work out what's
> > wrong.
> dig is better tool anyway, stay using that. host returns more compact 
> result, but is worse tool when hunting strange errors. Mostly because 
> without -t parameters it does 3 queries and possibleerror does not have 
> clear indication, to which it belongs.
> >
> >> Cheers,
> >> Petr
> >>
> >> On 7/16/23 22:10, Chris Green wrote:
> >>> I use dnsmasq on a number of, mostly Ubuntu, home systems. One system
> >>> at 192.168.1.2 acts as the DNS server for my LAN, then there are
> >>> several 'client' systems that just use dnsmasq as a caching DNS server
> >>> for their own lookups.
> >>>
> >>> I *suspect* I have a problem with looking up names via the local
> >>> dnsmasq because it is listening only on 127.0.1.1 and the request is
> >>> on 127.0.0.1#53.
> >>>
> >>> for example a 'host'command on my laptop returns:-
> >>>
> >>>   chris$ host jacquibennett.com
> >>>   ;; communications error to 127.0.0.1#53: timed out
> >>>   jacquibennett.com has address 153.92.6.161
> >>>   jacquibennett.com has IPv6 address 2a02:4780:a:1080:0:174b:7855:7
> >>>   jacquibennett.com mail is handled by 5 mx1.hostinger.com.
> >>>   jacquibennett.com mail is handled by 10 mx2.hostinger.com.
> >>>
> >>> But dnsmasq is running on the laptop:-
> >>>
> >>> dnsmasq 7443 1 0 09:27 ? 00:00:01 /usr/sbin/dnsmasq -x 
> >>> /run/dnsmasq/dnsmasq.pid
> >> -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service
> >> --trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
> >>
> >>>
> >>> The dnsmasq configuration file on the laptop (and other client
> >>> systems) is almost non-existent, it's just:-
> >>>
> >>>   resolv-file=/run/NetworkManager/no-stub-resolv.conf
> >>>
> >>> ... /run/NetworkManager/no-stub-resolv.conf is:-
> >>>
> >>>   # Generated by NetworkManager
> >>>   search zbmc.eu
> >>>   nameserver 192.168.1.2
> >>>
> >>>
> >>> ... and in /etc/dnsmasq.d I just have a blacklist file with lots of
> >>> address= entries, but that's all.  The /etc/default/dnsmasq
> >>> file just has:-
> >>>
> >>>   ENABLED=1
> >>>   CONFIG_DIR=/etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new
> >>>
> >>>
> >>> So why do I get that timeout error from the 'host' coommand? It's as
> >>> if dnsmasq on the local machine isn't listening on 127.0.0.1.  Does it
> >>> only listen on 127.0.1.1 by default?
> >>>
> >> -- 
> >> Petr Menšík
> >> Software Engineer, RHEL
> >> Red Hat, https://www.redhat.com/
> >> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> 
> -- 
> Petr Menšík
> Software Engineer, RHEL
> Red Hat, http://www.redhat.com/
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

-- 
Chris Green

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk

Re: [Dnsmasq-discuss] Problem with 127.0.1.1 versus 127.0.0.1

2023-07-17 Thread Petr Menšík
What is specified in dnsmasq does not matter. host by default does not 
talk to dnsmasq directly. It reads /etc/resolv.conf and uses nameserver 
specified there. If that is IP of dnsmasq, okay. If it is not, well, the 
problem might be elsewhere. Because I don't know what is there, I cannot 
help.


If you do "dig @localhost jacquibennett.com", then you are asking 
dnsmasq explicitly. Just "dig jacquibennett.com" uses server in 
/etc/resolv.conf, which may not even contain localhost address at all. 
That is why I have asked what is there.


On 17. 07. 23 9:00, Chris Green wrote:

On Sun, Jul 16, 2023 at 11:58:38PM +0200, Petr Menšík wrote:

I think you have failed to show us what is in /etc/resolv.conf on the
machine, which is running host command.


It's specified in /etc/dnsmasq.conf:-

 resolv-file=/run/NetworkManager/no-stub-resolv.conf

... and the contents are:-

 # Generated by NetworkManager
 search zbmc.eu
 nameserver 192.168.1.2


unless listen-address or interface is specified, it should listen on all
interfaces.


Yes, that's what I thought.



Try using host -v jacquibennett.com, it might provide more details what
exactly has timed out.

If unsure what is host contacting, try separate queries to server
specified explicitly:

- host -v jacquibennett.com 127.0.0.1
- host -v jacquibennett.com 127.0.1.1

That might provide hints what is failing and what is working.


Ah, thank you, I hadn't thought to check options for the host command,
I had been using dig to look deeper.

Typically when I tried just now both the above host commands worked
instantly with no errors!  I'll have to keep trying to work out what's
wrong.
dig is better tool anyway, stay using that. host returns more compact 
result, but is worse tool when hunting strange errors. Mostly because 
without -t parameters it does 3 queries and possibleerror does not have 
clear indication, to which it belongs.



Cheers,
Petr

On 7/16/23 22:10, Chris Green wrote:

I use dnsmasq on a number of, mostly Ubuntu, home systems. One system
at 192.168.1.2 acts as the DNS server for my LAN, then there are
several 'client' systems that just use dnsmasq as a caching DNS server
for their own lookups.

I *suspect* I have a problem with looking up names via the local
dnsmasq because it is listening only on 127.0.1.1 and the request is
on 127.0.0.1#53.

for example a 'host'command on my laptop returns:-

  chris$ host jacquibennett.com
  ;; communications error to 127.0.0.1#53: timed out
  jacquibennett.com has address 153.92.6.161
  jacquibennett.com has IPv6 address 2a02:4780:a:1080:0:174b:7855:7
  jacquibennett.com mail is handled by 5 mx1.hostinger.com.
  jacquibennett.com mail is handled by 10 mx2.hostinger.com.

But dnsmasq is running on the laptop:-

dnsmasq 7443 1 0 09:27 ? 00:00:01 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid

-u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service
--trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d



The dnsmasq configuration file on the laptop (and other client
systems) is almost non-existent, it's just:-

  resolv-file=/run/NetworkManager/no-stub-resolv.conf

... /run/NetworkManager/no-stub-resolv.conf is:-

  # Generated by NetworkManager
  search zbmc.eu
  nameserver 192.168.1.2


... and in /etc/dnsmasq.d I just have a blacklist file with lots of
address= entries, but that's all.  The /etc/default/dnsmasq
file just has:-

  ENABLED=1
  CONFIG_DIR=/etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new


So why do I get that timeout error from the 'host' coommand? It's as
if dnsmasq on the local machine isn't listening on 127.0.0.1.  Does it
only listen on 127.0.1.1 by default?


--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


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