Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #270912 > unrolled thread

NetworkManager with dnsmasq caching NXDOMAIN response of router

Started byDavid Ayers <ayers@fsfe.org>
First post2024-07-08 01:20 +0200
Last post2024-07-08 09:50 +0200
Articles 8 — 6 participants

Back to article view | Back to linux.debian.user

Contents

  NetworkManager with dnsmasq caching NXDOMAIN response of router David Ayers <ayers@fsfe.org> - 2024-07-08 01:20 +0200
    Re: NetworkManager with dnsmasq caching NXDOMAIN response of router jeremy ardley <jeremy.ardley@gmail.com> - 2024-07-08 06:10 +0200
      Re: NetworkManager with dnsmasq caching NXDOMAIN response of router David Ayers <ayers@fsfe.org> - 2024-07-08 12:00 +0200
        Re: NetworkManager with dnsmasq caching NXDOMAIN response of router Detlef Vollmann <dv@vollmann.ch> - 2024-07-10 15:20 +0200
          Re: NetworkManager with dnsmasq caching NXDOMAIN response of router Greg Wooledge <greg@wooledge.org> - 2024-07-10 15:20 +0200
            Re: NetworkManager with dnsmasq caching NXDOMAIN response of router songbird <songbird@anthive.com> - 2024-07-11 01:00 +0200
    Re: NetworkManager with dnsmasq caching NXDOMAIN response of router jeremy ardley <jeremy.ardley@gmail.com> - 2024-07-08 05:50 +0200
    Re: NetworkManager with dnsmasq caching NXDOMAIN response of router Michael Kjörling <c9bc136c6063@ewoof.net> - 2024-07-08 09:50 +0200

#270912 — NetworkManager with dnsmasq caching NXDOMAIN response of router

FromDavid Ayers <ayers@fsfe.org>
Date2024-07-08 01:20 +0200
SubjectNetworkManager with dnsmasq caching NXDOMAIN response of router
Message-ID<IXJkJ-yNn-1@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Hello everyone!

My Debian 12/bookworm laptop uses DHCP with NetworkManager which
produce an /etc/resolv.conf containing:
# Generated by NetworkManager
```
search home
nameserver 192.168.1.254
```

I've setup NetworkManager to use its local dnsmasq instance to add
additional name resolution for libvirt and a VPN, according to [1].
My /etc/NetworkManager/conf.d/localdns.conf contains:
```
[main]
dns=dnsmasq
```
and my /etc/NetworkManager/dnsmasq.d/local_dnsmasq.conf contains
```
server=/virt/192.168.122.1
server=/122.168.192.in-addr.arpa/192.168.122.1
server=/vpn/10.70.71.1
server=/71.70.10.in-addr.arpa/10.70.71.1
log-queries
```

The name resolutions (and reverse resolutions) for the the *.vpn and
*.virt work just fine.  But I'm having issues with the *.home domain as
soon as set the dns=dnsmasq in /etc/NetworkManager/conf.d/localdns.conf
independent of any entries in
/etc/NetworkManager/dnsmasq.d/local_dnsmasq.conf

After starting (or restarting) NetworkManager either with 
```
sudo systemctl reload NetworkManager.service
```
or with
```
sudo nmcli general reload dns-full
```
the name resolution works twice for anyhost.home in the local domain
but subsequently fails with NXDOMAIN.

Here ist the output of the log-queries output for a successful 
```
ping -c 1 nas-server.home
PING nas-server.home (192.168.1.103) 56(84) bytes of data.
64 bytes from nas-server.home (192.168.1.103): icmp_seq=1 ttl=64 time=7.47 ms
```
with the corresponding
```
sudo tail -f /var/log/syslog
TS HOST systemd[1]: Reloaded NetworkManager.service - Network Manager.
TS HOST dnsmasq[169260]: query[A] nas-server.home from 127.0.0.1
TS HOST dnsmasq[169260]: forwarded nas-server.home to 192.168.1.254
TS HOST dnsmasq[169260]: query[AAAA] nas-server.home from 127.0.0.1
TS HOST dnsmasq[169260]: forwarded nas-server.home to 192.168.1.254
TS HOST dnsmasq[169260]: reply nas-server.home is 192.168.1.103
TS HOST dnsmasq[169260]: reply nas-server.home is NXDOMAIN
TS HOST dnsmasq[169260]: query[PTR] 103.1.168.192.in-addr.arpa from 127.0.0.1
TS HOST dnsmasq[169260]: forwarded 103.1.168.192.in-addr.arpa to 192.168.1.254
TS HOST dnsmasq[169260]: reply 192.168.1.103 is nas-server.home
```
Notice the IPv6 AAAA query and the two replies with the FQDN.

The first subsequent query succeeds again with:
```
ping -c 1 nas-server.home
ping: nas-server.home: Name or service not known
```
with the corresponding
```
sudo tail -f /var/log/syslog
TS HOST dnsmasq[171213]: query[A] nas-server.home from 127.0.0.1
TS HOST dnsmasq[171213]: cached nas-server.home is NXDOMAIN
TS HOST dnsmasq[171213]: query[AAAA] nas-server.home from 127.0.0.1
TS HOST dnsmasq[171213]: cached nas-server.home is NXDOMAIN
TS HOST dnsmasq[171213]: query[A] nas-server from 127.0.0.1
TS HOST dnsmasq[171213]: forwarded nas-server to 192.168.1.254
TS HOST dnsmasq[171213]: query[AAAA] nas-server from 127.0.0.1
TS HOST dnsmasq[171213]: forwarded nas-server to 192.168.1.254
TS HOST dnsmasq[171213]: reply nas-server is 192.168.1.103
TS HOST dnsmasq[171213]: reply nas-server is NXDOMAIN
TS HOST dnsmasq[171213]: query[PTR] 103.1.168.192.in-addr.arpa from 127.0.0.1
TS HOST dnsmasq[171213]: forwarded 103.1.168.192.in-addr.arpa to 192.168.1.254
TS HOST dnsmasq[171213]: reply 192.168.1.103 is nas-server.home
```
Notice that the FQDN caches with NXDOMAIN are followed up with just the
host name and the same two replies, one with the IP and the other with
NXDOMAIN.

But all subsequent queries will fail with:
```
ping -c 1 nas-server.home
ping: nas-server.home: Name or service not known
```
with the corresponding
```
TS HOST dnsmasq[171213]: query[A] nas-server.home from 127.0.0.1
TS HOST dnsmasq[171213]: cached nas-server.home is NXDOMAIN
TS HOST dnsmasq[171213]: query[AAAA] nas-server.home from 127.0.0.1
TS HOST dnsmasq[171213]: cached nas-server.home is NXDOMAIN
TS HOST dnsmasq[171213]: query[A] nas-server from 127.0.0.1
TS HOST dnsmasq[171213]: cached nas-server is NXDOMAIN
TS HOST dnsmasq[171213]: query[AAAA] nas-server from 127.0.0.1
TS HOST dnsmasq[171213]: cached nas-server is NXDOMAIN
```

Once I restart/reload NetworkManager (i.e. clear the cache) I get two
successful name resolutions with subsequent requests failing again.

I do notice that when querying external domains, they seem to return
NODATA-IPv6 instead of NXDOMAIN for what I assume are the AAAA queries.
But I have no control of that my ZTE based ISP suppired router will
reply for the AAAA queries.  I suppose, that the router is returning
the wrong reply for its own local domain for AAAA queries.

So I guess my question is, can I tell dnsmasq somehow not to cache
NXDOMAIN or interpret it as NODATA-IPv6 for queries to the *.home
domain?

Any other suggestions are also welcome!

And in case this isn't it, where is the correct mailing list, to pose
suche a question?

Thanks, anyone!
David

[1] https://networkmanager.dev/docs/api/latest/NetworkManager.conf.html
-- 
David Ayers

Supporting:
Free Software Foundation Europe        []   (http://www.fsfe.org)
Become a supporter of the FSFE!      [][][] 
Your donation powers important work!   ||   (http://fsfe.org/donate)

[toc] | [next] | [standalone]

#270915

Fromjeremy ardley <jeremy.ardley@gmail.com>
Date2024-07-08 06:10 +0200
Message-ID<IXNRn-BAF-3@gated-at.bofh.it>
In reply to#270912

On 8/7/24 11:42, jeremy ardley wrote:
> 
> 
> On 8/7/24 07:03, David Ayers wrote:
>> Hello everyone!
>>
>> My Debian 12/bookworm laptop uses DHCP with NetworkManager which
>> produce an /etc/resolv.conf containing:
>> # Generated by NetworkManager
>> ```
>> search home
>> nameserver 192.168.1.254
>> ```
>>
>> I've setup NetworkManager to use its local dnsmasq instance to add
>> additional name resolution for libvirt and a VPN, according to [1].
>> My /etc/NetworkManager/conf.d/localdns.conf contains:
>> ```
>> [main]
>> dns=dnsmasq
>> ```
>> and my /etc/NetworkManager/dnsmasq.d/local_dnsmasq.conf contains
>> ```
>> server=/virt/192.168.122.1
>> server=/122.168.192.in-addr.arpa/192.168.122.1
>> server=/vpn/10.70.71.1
>> server=/71.70.10.in-addr.arpa/10.70.71.1
>> log-queries
>> ```
>>
>> The name resolutions (and reverse resolutions) for the the *.vpn and
>> *.virt work just fine.  But I'm having issues with the *.home domain as
>> soon as set the dns=dnsmasq in /etc/NetworkManager/conf.d/localdns.conf
>> independent of any entries in
>> /etc/NetworkManager/dnsmasq.d/local_dnsmasq.conf
>>
>> After starting (or restarting) NetworkManager either with
>> ```
>> sudo systemctl reload NetworkManager.service
>> ```
>> or with
>> ```
>> sudo nmcli general reload dns-full
>> ```
>> the name resolution works twice for anyhost.home in the local domain
>> but subsequently fails with NXDOMAIN.
>>
>> Here ist the output of the log-queries output for a successful
>> ```
>> ping -c 1 nas-server.home
>> PING nas-server.home (192.168.1.103) 56(84) bytes of data.
>> 64 bytes from nas-server.home (192.168.1.103): icmp_seq=1 ttl=64 
>> time=7.47 ms
>> ```
>> with the corresponding
>> ```
>> sudo tail -f /var/log/syslog
>> TS HOST systemd[1]: Reloaded NetworkManager.service - Network Manager.
>> TS HOST dnsmasq[169260]: query[A] nas-server.home from 127.0.0.1
>> TS HOST dnsmasq[169260]: forwarded nas-server.home to 192.168.1.254
>> TS HOST dnsmasq[169260]: query[AAAA] nas-server.home from 127.0.0.1
>> TS HOST dnsmasq[169260]: forwarded nas-server.home to 192.168.1.254
>> TS HOST dnsmasq[169260]: reply nas-server.home is 192.168.1.103
>> TS HOST dnsmasq[169260]: reply nas-server.home is NXDOMAIN
>> TS HOST dnsmasq[169260]: query[PTR] 103.1.168.192.in-addr.arpa from 
>> 127.0.0.1
>> TS HOST dnsmasq[169260]: forwarded 103.1.168.192.in-addr.arpa to 
>> 192.168.1.254
>> TS HOST dnsmasq[169260]: reply 192.168.1.103 is nas-server.home
>> ```
>> Notice the IPv6 AAAA query and the two replies with the FQDN.
>>
>> The first subsequent query succeeds again with:
>> ```
>> ping -c 1 nas-server.home
>> ping: nas-server.home: Name or service not known
>> ```
>> with the corresponding
>> ```
>> sudo tail -f /var/log/syslog
>> TS HOST dnsmasq[171213]: query[A] nas-server.home from 127.0.0.1
>> TS HOST dnsmasq[171213]: cached nas-server.home is NXDOMAIN
>> TS HOST dnsmasq[171213]: query[AAAA] nas-server.home from 127.0.0.1
>> TS HOST dnsmasq[171213]: cached nas-server.home is NXDOMAIN
>> TS HOST dnsmasq[171213]: query[A] nas-server from 127.0.0.1
>> TS HOST dnsmasq[171213]: forwarded nas-server to 192.168.1.254
>> TS HOST dnsmasq[171213]: query[AAAA] nas-server from 127.0.0.1
>> TS HOST dnsmasq[171213]: forwarded nas-server to 192.168.1.254
>> TS HOST dnsmasq[171213]: reply nas-server is 192.168.1.103
>> TS HOST dnsmasq[171213]: reply nas-server is NXDOMAIN
>> TS HOST dnsmasq[171213]: query[PTR] 103.1.168.192.in-addr.arpa from 
>> 127.0.0.1
>> TS HOST dnsmasq[171213]: forwarded 103.1.168.192.in-addr.arpa to 
>> 192.168.1.254
>> TS HOST dnsmasq[171213]: reply 192.168.1.103 is nas-server.home
>> ```
>> Notice that the FQDN caches with NXDOMAIN are followed up with just the
>> host name and the same two replies, one with the IP and the other with
>> NXDOMAIN.
>>
>> But all subsequent queries will fail with:
>> ```
>> ping -c 1 nas-server.home
>> ping: nas-server.home: Name or service not known
>> ```
>> with the corresponding
>> ```
>> TS HOST dnsmasq[171213]: query[A] nas-server.home from 127.0.0.1
>> TS HOST dnsmasq[171213]: cached nas-server.home is NXDOMAIN
>> TS HOST dnsmasq[171213]: query[AAAA] nas-server.home from 127.0.0.1
>> TS HOST dnsmasq[171213]: cached nas-server.home is NXDOMAIN
>> TS HOST dnsmasq[171213]: query[A] nas-server from 127.0.0.1
>> TS HOST dnsmasq[171213]: cached nas-server is NXDOMAIN
>> TS HOST dnsmasq[171213]: query[AAAA] nas-server from 127.0.0.1
>> TS HOST dnsmasq[171213]: cached nas-server is NXDOMAIN
>> ```
>>
>> Once I restart/reload NetworkManager (i.e. clear the cache) I get two
>> successful name resolutions with subsequent requests failing again.
>>
>> I do notice that when querying external domains, they seem to return
>> NODATA-IPv6 instead of NXDOMAIN for what I assume are the AAAA queries.
>> But I have no control of that my ZTE based ISP suppired router will
>> reply for the AAAA queries.  I suppose, that the router is returning
>> the wrong reply for its own local domain for AAAA queries.
>>
>> So I guess my question is, can I tell dnsmasq somehow not to cache
>> NXDOMAIN or interpret it as NODATA-IPv6 for queries to the *.home
>> domain?
>>
>> Any other suggestions are also welcome!
>>
>> And in case this isn't it, where is the correct mailing list, to pose
>> suche a question?
>>
>> Thanks, anyone!
>> David
>>
>> [1] https://networkmanager.dev/docs/api/latest/NetworkManager.conf.html
> 
> There is also the file /etc/nsswitch.conf. That gives you fine grained 
> control over name services and the order they are consulted
> 
> If you have a very small .home network you can create static entries in 
> /etc/hosts and if configured in nsswitch.conf will be used before any 
> call to an external dns provider.

I also forgot to mention my usual warning:

NetworkManager is *not* stable and if you do anything complex with it 
you can expect trouble.

Personally I use systemd-networkd as that seems much more stable and 
predictable and is easier to congigure

[toc] | [prev] | [next] | [standalone]

#270928

FromDavid Ayers <ayers@fsfe.org>
Date2024-07-08 12:00 +0200
Message-ID<IXTk5-EJ2-7@gated-at.bofh.it>
In reply to#270915

[Multipart message — attachments visible in raw view] — view raw

> On 8/7/24 11:42, jeremy ardley wrote:
> 
> There is also the file /etc/nsswitch.conf. That gives you fine
> grained control over name services and the order they are consulted 
> If you have a very small .home network you can create static entries
> in /etc/hosts and if configured in nsswitch.conf will be used before
> any call to an external dns provider. 
> 
> I also forgot to mention my usual warning:
> 
> NetworkManager is *not* stable and if you do anything complex with it
> you can expect trouble.
> 
> 
> Personally I use systemd-networkd as that seems much more stable and
> predictable and is easier to congigure

Thanks, and yes, /etc/hosts is what I have been juggling until now but
even though the network is "überschaubar" (small) it is volatile. 
After reboots of the router the printer/scanner, nas all get new
IPs/DHCP leases and editing /etc/hosts is becoming cumbersome.

NetworkManager is the default... I assume that the defaults is what is
the most stable.  If it is not, there should be a process to exchange
the default.  I'd really like to avoid straying from what most people
use.  But I don't really believe that this is a NetworkManager issue. 
Do me it seems to be a ZTE router, which I don't control, or hopefully
a dnsmasq configuration issue, which I do control.

Thanks!
David

PS: it seems I'm not receiving mails via the list subscription so
please keep my CC:ed if you will.  Thank you!

-- 
David Ayers

Supporting:
Free Software Foundation Europe        []   (http://www.fsfe.org)
Become a supporter of the FSFE!      [][][] 
Your donation powers important work!   ||   (http://fsfe.org/donate)

[toc] | [prev] | [next] | [standalone]

#271019

FromDetlef Vollmann <dv@vollmann.ch>
Date2024-07-10 15:20 +0200
Message-ID<IYFoJ-18Iq-15@gated-at.bofh.it>
In reply to#270928
On 7/8/24 11:50, David Ayers wrote:
> 
>> On 8/7/24 11:42, jeremy ardley wrote:
>> I also forgot to mention my usual warning:
>>
>> NetworkManager is *not* stable and if you do anything complex with it
>> you can expect trouble.
>>
>>
>> Personally I use systemd-networkd as that seems much more stable and
>> predictable and is easier to congigure
> 
> 
> NetworkManager is the default... I assume that the defaults is what is
> the most stable.  If it is not, there should be a process to exchange
> the default.  I'd really like to avoid straying from what most people
> use.

Only responding to this part.

NetworkManager is the "default" (whatever "default" means) as it serves
well the need of many users to connect a client machine to the Internet.

I doubt that many users use NetworkManager for what you're trying to do.
So you probably are "straying from what most people use".

   Detlef

[toc] | [prev] | [next] | [standalone]

#271020

FromGreg Wooledge <greg@wooledge.org>
Date2024-07-10 15:20 +0200
Message-ID<IYFoJ-18Iq-17@gated-at.bofh.it>
In reply to#271019
On Wed, Jul 10, 2024 at 15:11:20 +0200, Detlef Vollmann wrote:
> NetworkManager is the "default" (whatever "default" means) as it serves
> well the need of many users to connect a client machine to the Internet.

It's only the "default" if a Desktop Environment is installed.  On a
Standard Debian installation (e.g. one you'd use for servers), NM is
not installed at all.

Worry less about what the "default" is, because the entire concept of
defaults is extremely vague in Debian.  Debian offers a multitude
of choices.  Worry more about how to solve *your* own problems, using
whichever solution is most suitable.

[toc] | [prev] | [next] | [standalone]

#271052

Fromsongbird <songbird@anthive.com>
Date2024-07-11 01:00 +0200
Message-ID<IYOs1-1e8H-5@gated-at.bofh.it>
In reply to#271020
Greg Wooledge wrote:
> On Wed, Jul 10, 2024 at 15:11:20 +0200, Detlef Vollmann wrote:
>> NetworkManager is the "default" (whatever "default" means) as it serves
>> well the need of many users to connect a client machine to the Internet.
>
> It's only the "default" if a Desktop Environment is installed.  On a
> Standard Debian installation (e.g. one you'd use for servers), NM is
> not installed at all.

  when it got installed i masked it out and continued my
manual ways as i don't want an automatic network connection
coming up.  i don't always do things on-line so i don't want
a connection just sitting there doing nothing but getting
probes and messages from the bozo's doing whatever on the
local ISP network.


> Worry less about what the "default" is, because the entire concept of
> defaults is extremely vague in Debian.  Debian offers a multitude
> of choices.  Worry more about how to solve *your* own problems, using
> whichever solution is most suitable.

  yes.  :)  and then try to remember what you've done that
isn't quite normal...  some years later you may forget and
i don't write all my stuff down.  next time i do a clean
install i'll have to keep a better log of my local changes.
i have a lot of things masked out from systemd that i don't
use.


  songbird

[toc] | [prev] | [next] | [standalone]

#270924

Fromjeremy ardley <jeremy.ardley@gmail.com>
Date2024-07-08 05:50 +0200
Message-ID<IXNy2-Bez-3@gated-at.bofh.it>
In reply to#270912

On 8/7/24 07:03, David Ayers wrote:
> Hello everyone!
> 
> My Debian 12/bookworm laptop uses DHCP with NetworkManager which
> produce an /etc/resolv.conf containing:
> # Generated by NetworkManager
> ```
> search home
> nameserver 192.168.1.254
> ```
> 
> I've setup NetworkManager to use its local dnsmasq instance to add
> additional name resolution for libvirt and a VPN, according to [1].
> My /etc/NetworkManager/conf.d/localdns.conf contains:
> ```
> [main]
> dns=dnsmasq
> ```
> and my /etc/NetworkManager/dnsmasq.d/local_dnsmasq.conf contains
> ```
> server=/virt/192.168.122.1
> server=/122.168.192.in-addr.arpa/192.168.122.1
> server=/vpn/10.70.71.1
> server=/71.70.10.in-addr.arpa/10.70.71.1
> log-queries
> ```
> 
> The name resolutions (and reverse resolutions) for the the *.vpn and
> *.virt work just fine.  But I'm having issues with the *.home domain as
> soon as set the dns=dnsmasq in /etc/NetworkManager/conf.d/localdns.conf
> independent of any entries in
> /etc/NetworkManager/dnsmasq.d/local_dnsmasq.conf
> 
> After starting (or restarting) NetworkManager either with
> ```
> sudo systemctl reload NetworkManager.service
> ```
> or with
> ```
> sudo nmcli general reload dns-full
> ```
> the name resolution works twice for anyhost.home in the local domain
> but subsequently fails with NXDOMAIN.
> 
> Here ist the output of the log-queries output for a successful
> ```
> ping -c 1 nas-server.home
> PING nas-server.home (192.168.1.103) 56(84) bytes of data.
> 64 bytes from nas-server.home (192.168.1.103): icmp_seq=1 ttl=64 time=7.47 ms
> ```
> with the corresponding
> ```
> sudo tail -f /var/log/syslog
> TS HOST systemd[1]: Reloaded NetworkManager.service - Network Manager.
> TS HOST dnsmasq[169260]: query[A] nas-server.home from 127.0.0.1
> TS HOST dnsmasq[169260]: forwarded nas-server.home to 192.168.1.254
> TS HOST dnsmasq[169260]: query[AAAA] nas-server.home from 127.0.0.1
> TS HOST dnsmasq[169260]: forwarded nas-server.home to 192.168.1.254
> TS HOST dnsmasq[169260]: reply nas-server.home is 192.168.1.103
> TS HOST dnsmasq[169260]: reply nas-server.home is NXDOMAIN
> TS HOST dnsmasq[169260]: query[PTR] 103.1.168.192.in-addr.arpa from 127.0.0.1
> TS HOST dnsmasq[169260]: forwarded 103.1.168.192.in-addr.arpa to 192.168.1.254
> TS HOST dnsmasq[169260]: reply 192.168.1.103 is nas-server.home
> ```
> Notice the IPv6 AAAA query and the two replies with the FQDN.
> 
> The first subsequent query succeeds again with:
> ```
> ping -c 1 nas-server.home
> ping: nas-server.home: Name or service not known
> ```
> with the corresponding
> ```
> sudo tail -f /var/log/syslog
> TS HOST dnsmasq[171213]: query[A] nas-server.home from 127.0.0.1
> TS HOST dnsmasq[171213]: cached nas-server.home is NXDOMAIN
> TS HOST dnsmasq[171213]: query[AAAA] nas-server.home from 127.0.0.1
> TS HOST dnsmasq[171213]: cached nas-server.home is NXDOMAIN
> TS HOST dnsmasq[171213]: query[A] nas-server from 127.0.0.1
> TS HOST dnsmasq[171213]: forwarded nas-server to 192.168.1.254
> TS HOST dnsmasq[171213]: query[AAAA] nas-server from 127.0.0.1
> TS HOST dnsmasq[171213]: forwarded nas-server to 192.168.1.254
> TS HOST dnsmasq[171213]: reply nas-server is 192.168.1.103
> TS HOST dnsmasq[171213]: reply nas-server is NXDOMAIN
> TS HOST dnsmasq[171213]: query[PTR] 103.1.168.192.in-addr.arpa from 127.0.0.1
> TS HOST dnsmasq[171213]: forwarded 103.1.168.192.in-addr.arpa to 192.168.1.254
> TS HOST dnsmasq[171213]: reply 192.168.1.103 is nas-server.home
> ```
> Notice that the FQDN caches with NXDOMAIN are followed up with just the
> host name and the same two replies, one with the IP and the other with
> NXDOMAIN.
> 
> But all subsequent queries will fail with:
> ```
> ping -c 1 nas-server.home
> ping: nas-server.home: Name or service not known
> ```
> with the corresponding
> ```
> TS HOST dnsmasq[171213]: query[A] nas-server.home from 127.0.0.1
> TS HOST dnsmasq[171213]: cached nas-server.home is NXDOMAIN
> TS HOST dnsmasq[171213]: query[AAAA] nas-server.home from 127.0.0.1
> TS HOST dnsmasq[171213]: cached nas-server.home is NXDOMAIN
> TS HOST dnsmasq[171213]: query[A] nas-server from 127.0.0.1
> TS HOST dnsmasq[171213]: cached nas-server is NXDOMAIN
> TS HOST dnsmasq[171213]: query[AAAA] nas-server from 127.0.0.1
> TS HOST dnsmasq[171213]: cached nas-server is NXDOMAIN
> ```
> 
> Once I restart/reload NetworkManager (i.e. clear the cache) I get two
> successful name resolutions with subsequent requests failing again.
> 
> I do notice that when querying external domains, they seem to return
> NODATA-IPv6 instead of NXDOMAIN for what I assume are the AAAA queries.
> But I have no control of that my ZTE based ISP suppired router will
> reply for the AAAA queries.  I suppose, that the router is returning
> the wrong reply for its own local domain for AAAA queries.
> 
> So I guess my question is, can I tell dnsmasq somehow not to cache
> NXDOMAIN or interpret it as NODATA-IPv6 for queries to the *.home
> domain?
> 
> Any other suggestions are also welcome!
> 
> And in case this isn't it, where is the correct mailing list, to pose
> suche a question?
> 
> Thanks, anyone!
> David
> 
> [1] https://networkmanager.dev/docs/api/latest/NetworkManager.conf.html

There is also the file /etc/nsswitch.conf. That gives you fine grained 
control over name services and the order they are consulted

If you have a very small .home network you can create static entries in 
/etc/hosts and if configured in nsswitch.conf will be used before any 
call to an external dns provider.

[toc] | [prev] | [next] | [standalone]

#270932

FromMichael Kjörling <c9bc136c6063@ewoof.net>
Date2024-07-08 09:50 +0200
Message-ID<IXRih-DyH-5@gated-at.bofh.it>
In reply to#270912
On 8 Jul 2024 01:03 +0200, from ayers@fsfe.org (David Ayers):
> Hello everyone!
> 
> My Debian 12/bookworm laptop uses DHCP with NetworkManager which
> produce an /etc/resolv.conf containing:
> # Generated by NetworkManager
> ```
> search home
> nameserver 192.168.1.254
> ```

Note that .home is somewhat of a special snowflake with regards to
TLDs. It was suggested as the default for HNCP in 2016 (RFC 7788
section 8 <https://www.rfc-editor.org/rfc/rfc7788#section-8>);
rejected as a gTLD in 2018
<https://www.icann.org/en/board-activities-and-meetings/materials/approved-board-resolutions-regular-meeting-of-the-icann-board-04-02-2018-en#2.c>;
and then the usage from RFC 7788 was effectively superceded by the
recommendation and assignment for non-unique use of home.arpa a few
months later in RFC 8375 <https://www.rfc-editor.org/rfc/rfc8375>.

This may or may not have anything to do with your issues; but in
general, making up own TLDs and hoping that they will never conflict
with public ones is a bad idea these days. Just look at how many
internal names suddenly started having issues after Google was
assigned .dev in 2019; to say nothing of that they made it a
preloaded-HSTS TLD.

It's better to either use .home.arpa (which is specifically reserved
for the purpose) or to actually register a domain (even if the name
server delegations are bogus so it never meaningfully resolves on the
public Internet).

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web