[SOLVED] Re: Strange DNS behaviour

[Xavier Humbert]

On 09/05/2021 12:32, Xavier Humbert via bind-users wrote:
>
> Hi,
>
> My DNS system if perfectly working :
>
>> [xavier at numenor ~]$ dig dns.google.com
>>
>> ; <<>> DiG 9.16.15 <<>> dns.google.com
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12276
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 1232
>> ; COOKIE: 7b606d7c32a99906010000006097b6d7f61894ea0a92dac2 (good)
>> ;; QUESTION SECTION:
>> ;dns.google.com.                        
>> IN      A
>>
>> ;; ANSWER SECTION:
>> dns.google.com.         880     IN      
>> A       8.8.4.4
>> dns.google.com.         880     IN      
>> A       8.8.8.8
>>
>> ;; Query time: 0 msec
>> ;; SERVER: ::1#53(::1)
>> ;; WHEN: Sun May 09 12:17:59 CEST 2021
>> ;; MSG SIZE  rcvd: 103
>
> On other hosts in my home, it works, too.
>
> But on one machine, it fails :
>
>> [xavier at feanor ~]$ dig @numenor dns.google.com +trace
>>
>> ; <<>> DiG 9.16.8-Ubuntu <<>> @numenor dns.google.com +trace
>> ; (1 server found)
>> ;; global options: +cmd
>> .                       518400  IN 
>>      NS      m.root-servers.net.
>> .                       518400  IN 
>>      NS      b.root-servers.net.
>> .                       518400  IN 
>>      NS      e.root-servers.net.
>> .                       518400  IN 
>>      NS      d.root-servers.net.
>> .                       518400  IN 
>>      NS      h.root-servers.net.
>> .                       518400  IN 
>>      NS      f.root-servers.net.
>> .                       518400  IN 
>>      NS      g.root-servers.net.
>> .                       518400  IN 
>>      NS      c.root-servers.net.
>> .                       518400  IN 
>>      NS      i.root-servers.net.
>> .                       518400  IN 
>>      NS      j.root-servers.net.
>> .                       518400  IN 
>>      NS      k.root-servers.net.
>> .                       518400  IN 
>>      NS      l.root-servers.net.
>> .                       518400  IN 
>>      NS      a.root-servers.net.
>> .                       518400  IN 
>>      RRSIG   NS 8 0 518400 20210521170000 20210508160000 14631 
>> . IgUiqHrRXT5hTAa5wnubyCL0T9iq+iRAQIUQlIStRYqZh6Qp5W3sZLum 
>> 6O+EkYZALJda6RJwQY8oPEgQVQymGmGyAxcZBekX5vsMm8MgovQIA+Ev 
>> SroSeV9yXDURHqt8af+25bw
>> 6YyUQEOblPehxyUYYkF9cP8FlieAUw1Fn 
>> HMvqpQlEn2sYS4UjA+euhcS2k7jnyEdBNbXbEZVq56zHK1aHPQIp2f4/ 
>> byHaC55zPJ5rgLwMUh+8JuP47wb4NWAKIj76EUlqcidfI8hxZI5KPoNZ 
>> vmIcEtQSfRYqVxoc+BiEEgalw5afAmXjEtvJaWm4v5383uatiQ1s9AgC MPQFHw==
>> couldn't get address for 'm.root-servers.net': not found
>
> None of the root servers can't be found. My root hint file is up to date.
>
> The network configuration on this machine :
>
>> [xavier at feanor ~]$ nmcli device show enp10s0
>> GENERAL.DEVICE:                         enp10s0
>> GENERAL.TYPE: 
>>                           ethernet
>> GENERAL.HWADDR: 
>>                         04:7D:7B:02:68:67
>> GENERAL.MTU:                            1500
>> GENERAL.STATE:                          100 
>> (connected)
>> GENERAL.CONNECTION:                     Wired
>> GENERAL.CON-PATH: 
>>                       /org/freedesktop/NetworkManager/ActiveConnection/3 
>>
>> WIRED-PROPERTIES.CARRIER:               on
>> IP4.ADDRESS[1]: 
>>                         192.168.100.25/24
>> IP4.GATEWAY: 
>>                            192.168.100.254
>> IP4.ROUTE[1]:                           dst 
>> = 0.0.0.0/0, nh = 192.168.100.254, mt = 100
>> IP4.ROUTE[2]:                           dst 
>> = 192.168.100.0/24, nh = 0.0.0.0, mt = 100
>> IP4.ROUTE[3]:                           dst 
>> = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
>> IP4.DNS[1]: 
>>                             192.168.100.144
>> IP4.DNS[2]: 
>>                             192.168.100.254
> This is not an ACL problem, the whole subnet is allowed. Nmap and/or 
> telnet shows no blocked port problem
>
> Trying on the secondary leads to the same behaviour
>
> Eventually, I am lost.
>
Sorry for the disturbance, it was caused by faulty remnants of a VPN 
connection. I fixed that in /etc/systemd/resolved.conf

Cheers

-- 
Xavier Humbert
CRT Supervision et Exploitation de Niveau 1
Rectorat de Nancy-Metz
03 83 86 27 39

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/8808f43b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x90B78A89BCC49C10.asc
Type: application/pgp-keys
Size: 3154 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/8808f43b/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210509/8808f43b/attachment-0003.bin>