Folks, I have 3 Linux systems, one running F31 and 2 running F34. On one of the F34 systems I have a local DNS server running. This has worked fine in the past, but now I'm seeing strangeness on the 2 F34 systems.
I added a host to the DNS server for normal lookup and reverse lookup. On the F31 system both:
host centos8-opstcore-vm.homenet172-16-96.com
and
host 172.16.96.20
work. The first returns 172.16.96.20 and the second returns centos8-opstcore-vm.homenet172-16-96.com.
On the F34 which is the DNS server the first works, but the second fails with:
Host 20.96.16.172.in-addr.arpa. not found: 3(NXDOMAIN)
On the other F34 system I get:
host 172.16.96.20
;; connection timed out; no servers could be reached
The interface has the DNS server pointing to the correct system. If I run:
nslookup
server 192.168.10.66
Default server: 192.168.10.66 Address: 192.168.10.66#53
172.16.96.20
20.96.16.172.in-addr.arpa name = centos8-opstcore-vm.homenet172-16-96.com.
Then it works.
What do I need to do on F34 systems to get DNS lookups working?
Any help is appreciated.
Paolo
On 21 Feb 2022, at 20:15, Paolo Galtieri pgaltieri@gmail.com wrote:
Folks, I have 3 Linux systems, one running F31 and 2 running F34. On one of the F34 systems I have a local DNS server running. This has worked fine in the past, but now I'm seeing strangeness on the 2 F34 systems.
F31 is real old now.
I added a host to the DNS server for normal lookup and reverse lookup. On the F31 system both:
host centos8-opstcore-vm.homenet172-16-96.com
and
host 172.16.96.20
work. The first returns 172.16.96.20 and the second returns centos8-opstcore-vm.homenet172-16-96.com.
On the F34 which is the DNS server the first works, but the second fails with:
Host 20.96.16.172.in-addr.arpa. not found: 3(NXDOMAIN)
On the other F34 system I get:
host 172.16.96.20
;; connection timed out; no servers could be reached
The interface has the DNS server pointing to the correct system. If I run:
nslookup
server 192.168.10.66
Default server: 192.168.10.66 Address: 192.168.10.66#53
172.16.96.20
20.96.16.172.in-addr.arpa name = centos8-opstcore-vm.homenet172-16-96.com.
Then it works.
What do I need to do on F34 systems to get DNS lookups working?
Any help is appreciated.
I would check what is in /etc/resolv.conf for both machines. Do you have any dns caching on any of the hosts?
If you can repro at will next I would use wireshark to see what is send for the look ups.
Barry
Paolo
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 21 Feb 2022, at 20:15, Paolo Galtieri pgaltieri@gmail.com wrote:
Folks, I have 3 Linux systems, one running F31 and 2 running F34. On one of the F34 systems I have a local DNS server running. This has worked fine in the past, but now I'm seeing strangeness on the 2 F34 systems.
I added a host to the DNS server for normal lookup and reverse lookup. On the F31 system both:
host centos8-opstcore-vm.homenet172-16-96.com
and
host 172.16.96.20
work. The first returns 172.16.96.20 and the second returns centos8-opstcore-vm.homenet172-16-96.com.
On the F34 which is the DNS server the first works, but the second fails with:
Host 20.96.16.172.in-addr.arpa. not found: 3(NXDOMAIN)
On the other F34 system I get:
host 172.16.96.20
;; connection timed out; no servers could be reached
The interface has the DNS server pointing to the correct system. If I run:
nslookup
server 192.168.10.66
Default server: 192.168.10.66 Address: 192.168.10.66#53
172.16.96.20
20.96.16.172.in-addr.arpa name = centos8-opstcore-vm.homenet172-16-96.com.
Nslookup has been replaced by the dig program.
Barry
Then it works.
What do I need to do on F34 systems to get DNS lookups working?
Might you be using systemd-resolved on the f34 to cache for you? What does resolvectl report?
Barry
Any help is appreciated.
Paolo
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, Feb 21, 2022 at 4:52 PM Barry barry@barrys-emacs.org wrote:
On 21 Feb 2022, at 20:15, Paolo Galtieri pgaltieri@gmail.com wrote:
Folks, I have 3 Linux systems, one running F31 and 2 running F34. On one of
the F34 systems I have a local DNS server running. This has worked fine in the past, but now I'm seeing strangeness on the 2 F34 systems.
I added a host to the DNS server for normal lookup and reverse lookup.
On the F31 system both:
host centos8-opstcore-vm.homenet172-16-96.com
and
host 172.16.96.20
work. The first returns 172.16.96.20 and the second returns
centos8-opstcore-vm.homenet172-16-96.com.
On the F34 which is the DNS server the first works, but the second fails
with:
Host 20.96.16.172.in-addr.arpa. not found: 3(NXDOMAIN)
On the other F34 system I get:
host 172.16.96.20
;; connection timed out; no servers could be reached
The interface has the DNS server pointing to the correct system. If I
run:
nslookup
server 192.168.10.66
Default server: 192.168.10.66 Address: 192.168.10.66#53
172.16.96.20
20.96.16.172.in-addr.arpa name =
centos8-opstcore-vm.homenet172-16-96.com.
Nslookup has been replaced by the dig program.
Barry
Then it works.
What do I need to do on F34 systems to get DNS lookups working?
Might you be using systemd-resolved on the f34 to cache for you? What does resolvectl report?
Barry
Any help is appreciated.
Paolo
In Fedora 33 DNS resolution was changed (1)adding a DNS server to /etc/resolv.conf using systemd-resolve.
There is still an /etc/resolv.conf and it is configured to use a name service running on a loopback device where a local DNS service is listening.
# grep -v '#' /etc/resolv.conf
nameserver 127.0.0.53 options edns0 trust-ad search domain.com
If you are using the NetworkManager service just add the DNS server address and it should start working.
Something like this "nmcli con mod $connectionName ipv4.dns "1.1.1.1 9.9.9.9".
At first I didn't like this new way to manage DNS, but I am finding some of the features to work very well. Like the split dns feature is working really well with the multiple vpn clients run simultaneously, no more hacking on /etc/resolv.conf each time a new VPN is started, it just works.
1 - https://fedoraproject.org/wiki/Changes/systemd-resolved
Regards, -Jamie
On 2/21/22 14:09, Jamie Fargen wrote:
On Mon, Feb 21, 2022 at 4:52 PM Barry barry@barrys-emacs.org wrote:
> On 21 Feb 2022, at 20:15, Paolo Galtieri <pgaltieri@gmail.com> wrote: > > Folks, > I have 3 Linux systems, one running F31 and 2 running F34. On one of the F34 systems I have a local DNS server running. This has worked fine in the past, but now I'm seeing strangeness on the 2 F34 systems. > > I added a host to the DNS server for normal lookup and reverse lookup. On the F31 system both: > > host centos8-opstcore-vm.homenet172-16-96.com <http://centos8-opstcore-vm.homenet172-16-96.com> > > and > > host 172.16.96.20 > > work. The first returns 172.16.96.20 and the second returns centos8-opstcore-vm.homenet172-16-96.com <http://centos8-opstcore-vm.homenet172-16-96.com>. > > On the F34 which is the DNS server the first works, but the second fails with: > > Host 20.96.16.172.in-addr.arpa. not found: 3(NXDOMAIN) > > On the other F34 system I get: > > host 172.16.96.20 > > ;; connection timed out; no servers could be reached > > The interface has the DNS server pointing to the correct system. If I run: > > nslookup > > server 192.168.10.66 > Default server: 192.168.10.66 > Address: 192.168.10.66#53 > > 172.16.96.20 > 20.96.16.172.in-addr.arpa name = centos8-opstcore-vm.homenet172-16-96.com <http://centos8-opstcore-vm.homenet172-16-96.com>. > > Nslookup has been replaced by the dig program. Barry > > Then it works. > > What do I need to do on F34 systems to get DNS lookups working? Might you be using systemd-resolved on the f34 to cache for you? What does resolvectl report?
Yes I am
Barry
On the DNS server resolvectl shows:
resolvectl Global Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub
Link 2 (eno1) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.10.66 DNS Servers: 192.168.10.66 8.8.8.8 DNS Domain: homenet172-16-96.com homenet172-22-6.com homenet192-10.com
On the other F34 system
resolvecttl Global Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub
Link 2 (enp0s20f0u1u1u1) Current Scopes: LLMNR/IPv4 LLMNR/IPv6 Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 3 (enp0s20f0u1u1u4) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.10.66 DNS Servers: 192.168.10.66 DNS Domain: homenet172-16-96.com homenet172-22-6.com homenet192-10.com
In all cases it points to the correct DNS server
> > Any help is appreciated. > > Paolo >In Fedora 33 DNS resolution was changed (1)adding a DNS server to /etc/resolv.conf using systemd-resolve.
There is still an /etc/resolv.conf and it is configured to use a name service running on a loopback device where a local DNS service is listening.
# grep -v '#' /etc/resolv.conf
nameserver 127.0.0.53 options edns0 trust-ad search domain.com http://domain.com
If you are using the NetworkManager service just add the DNS server address and it should start working.
The entry for the network device includes the DNS server address
Something like this "nmcli con mod $connectionName ipv4.dns "1.1.1.1 9.9.9.9".
I tried this, but reverse lookup still doesn't work.
dig 172.16.96.20
; <<>> DiG 9.16.24-RH <<>> 172.16.96.20 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47273 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;172.16.96.20. IN A
;; AUTHORITY SECTION: . 6751 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2022022101 1800 900 604800 86400
;; Query time: 1 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Mon Feb 21 14:39:02 PST 2022 ;; MSG SIZE rcvd: 116
dig centos8-opstcore-vm.homenet172-16-96.com
; <<>> DiG 9.16.24-RH <<>> centos8-opstcore-vm.homenet172-16-96.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26457 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;centos8-opstcore-vm.homenet172-16-96.com. IN A
;; ANSWER SECTION: centos8-opstcore-vm.homenet172-16-96.com. 4778 IN A 172.16.96.20
;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Mon Feb 21 14:40:16 PST 2022 ;; MSG SIZE rcvd: 85
I tried stopping and restarting systemd-resolved to no avail as well as restarting the network interface also to no avail.
What's curious is for example
host 192.168.10.2 will return a host name most likely because it's cached.
host 172.16.96.20 results in host not found on one F34 system and no servers could be reached on the other F34 system
I ran wireshark on the DNS server and it showed the query to 127.0.0.53 with the hostname and a response of the ip address. But a query to 127.0.0.53 with the ip address returned a not found error.
At first I didn't like this new way to manage DNS, but I am finding some of the features to work very well. Like the split dns feature is working really well with the multiple vpn clients run simultaneously, no more hacking on /etc/resolv.conf each time a new VPN is started, it just works.
1 - https://fedoraproject.org/wiki/Changes/systemd-resolved
Regards, -Jamie
users mailing list --users@lists.fedoraproject.org To unsubscribe send an email tousers-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
dig 172.16.96.20
Do you mean dig -x 172.16.96.20
dig 1.1.1.1 doesn't return the host name:
You can see running dig followed by an IP doesn't return anything, to do a reverse DNS lookup, or to resolve the hostname from the IP, you can see in the second example dig -x followed by the IP returns the hostname one.one.one.one.
$ dig 1.1.1.1
; <<>> DiG 9.16.24-RH <<>> 1.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42214 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;1.1.1.1. IN A
;; AUTHORITY SECTION: . 60 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2022022101 1800 900 604800 86400
;; Query time: 241 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Mon Feb 21 18:53:50 EST 2022 ;; MSG SIZE rcvd: 111
# dig -x 1.1.1.1
; <<>> DiG 9.16.24-RH <<>> -x 1.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63485 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;1.1.1.1.in-addr.arpa. IN PTR
;; ANSWER SECTION: 1.1.1.1.in-addr.arpa. 1131 IN PTR one.one.one.one.
;; Query time: 74 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Mon Feb 21 18:53:57 EST 2022 ;; MSG SIZE rcvd: 78
; <<>> DiG 9.16.24-RH <<>> 172.16.96.20 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47273 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;172.16.96.20. IN A
;; AUTHORITY SECTION: . 6751 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2022022101 1800 900 604800 86400
;; Query time: 1 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Mon Feb 21 14:39:02 PST 2022 ;; MSG SIZE rcvd: 116
dig centos8-opstcore-vm.homenet172-16-96.com
; <<>> DiG 9.16.24-RH <<>> centos8-opstcore-vm.homenet172-16-96.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26457 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;centos8-opstcore-vm.homenet172-16-96.com. IN A
;; ANSWER SECTION: centos8-opstcore-vm.homenet172-16-96.com. 4778 IN A 172.16.96.20
;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Mon Feb 21 14:40:16 PST 2022 ;; MSG SIZE rcvd: 85
I tried stopping and restarting systemd-resolved to no avail as well as restarting the network interface also to no avail.
What's curious is for example
host 192.168.10.2 will return a host name most likely because it's cached.
host 172.16.96.20 results in host not found on one F34 system and no servers could be reached on the other F34 system
I ran wireshark on the DNS server and it showed the query to 127.0.0.53 with the hostname and a response of the ip address. But a query to 127.0.0.53 with the ip address returned a not found error.
At first I didn't like this new way to manage DNS, but I am finding some of the features to work very well. Like the split dns feature is working really well with the multiple vpn clients run simultaneously, no more hacking on /etc/resolv.conf each time a new VPN is started, it just works.
1 - https://fedoraproject.org/wiki/Changes/systemd-resolved
Regards, -Jamie
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 2/21/22 15:56, Jamie Fargen wrote:
dig 172.16.96.20Do you mean dig -x 172.16.96.20
dig 1.1.1.1 doesn't return the host name:
dig -x 172.16.96.20
returns
; <<>> DiG 9.16.24-RH <<>> -x 172.16.96.20 ;; global options: +cmd ;; connection timed out; no servers could be reached
but
dig centos8-opstcore-vm.homenet172-16-96.com
returns
; <<>> DiG 9.16.24-RH <<>> centos8-opstcore-vm.homenet172-16-96.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31140 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;centos8-opstcore-vm.homenet172-16-96.com. IN A
;; ANSWER SECTION: centos8-opstcore-vm.homenet172-16-96.com. 259200 IN A 172.16.96.20
;; Query time: 2 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Tue Feb 22 16:04:46 PST 2022 ;; MSG SIZE rcvd: 85
Paolo
You can see running dig followed by an IP doesn't return anything, to do a reverse DNS lookup, or to resolve the hostname from the IP, you can see in the second example dig -x followed by the IP returns the hostname one.one.one.one.
$ dig 1.1.1.1
; <<>> DiG 9.16.24-RH <<>> 1.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42214 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;1.1.1.1. IN A
;; AUTHORITY SECTION: . 60 IN SOA a.root-servers.net http://a.root-servers.net. nstld.verisign-grs.com http://nstld.verisign-grs.com. 2022022101 1800 900 604800 86400
;; Query time: 241 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Mon Feb 21 18:53:50 EST 2022 ;; MSG SIZE rcvd: 111
# dig -x 1.1.1.1
; <<>> DiG 9.16.24-RH <<>> -x 1.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63485 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;1.1.1.1.in-addr.arpa. IN PTR
;; ANSWER SECTION: 1.1.1.1.in-addr.arpa. 1131 IN PTR one.one.one.one.
;; Query time: 74 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Mon Feb 21 18:53:57 EST 2022 ;; MSG SIZE rcvd: 78
; <<>> DiG 9.16.24-RH <<>> 172.16.96.20 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47273 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;172.16.96.20. IN A ;; AUTHORITY SECTION: . 6751 IN SOA a.root-servers.net <http://a.root-servers.net>. nstld.verisign-grs.com <http://nstld.verisign-grs.com>. 2022022101 1800 900 604800 86400 ;; Query time: 1 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Mon Feb 21 14:39:02 PST 2022 ;; MSG SIZE rcvd: 116 dig centos8-opstcore-vm.homenet172-16-96.com <http://centos8-opstcore-vm.homenet172-16-96.com> ; <<>> DiG 9.16.24-RH <<>> centos8-opstcore-vm.homenet172-16-96.com <http://centos8-opstcore-vm.homenet172-16-96.com> ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26457 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;centos8-opstcore-vm.homenet172-16-96.com <http://centos8-opstcore-vm.homenet172-16-96.com>. IN A ;; ANSWER SECTION: centos8-opstcore-vm.homenet172-16-96.com <http://centos8-opstcore-vm.homenet172-16-96.com>. 4778 IN A 172.16.96.20 ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Mon Feb 21 14:40:16 PST 2022 ;; MSG SIZE rcvd: 85 I tried stopping and restarting systemd-resolved to no avail as well as restarting the network interface also to no avail. What's curious is for example host 192.168.10.2 will return a host name most likely because it's cached. host 172.16.96.20 results in host not found on one F34 system and no servers could be reached on the other F34 system I ran wireshark on the DNS server and it showed the query to 127.0.0.53 with the hostname and a response of the ip address. But a query to 127.0.0.53 with the ip address returned a not found error.At first I didn't like this new way to manage DNS, but I am finding some of the features to work very well. Like the split dns feature is working really well with the multiple vpn clients run simultaneously, no more hacking on /etc/resolv.conf each time a new VPN is started, it just works. 1 - https://fedoraproject.org/wiki/Changes/systemd-resolved Regards, -Jamie _______________________________________________ users mailing list --users@lists.fedoraproject.org To unsubscribe send an email tousers-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure_______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
users mailing list --users@lists.fedoraproject.org To unsubscribe send an email tousers-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
Paolo Galtieri wrote:
dig -x 172.16.96.20
returns
; <<>> DiG 9.16.24-RH <<>> -x 172.16.96.20 ;; global options: +cmd ;; connection timed out; no servers could be reached
but
dig centos8-opstcore-vm.homenet172-16-96.com
returns
; <<>> DiG 9.16.24-RH <<>> centos8-opstcore-vm.homenet172-16-96.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31140 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;centos8-opstcore-vm.homenet172-16-96.com. IN A
;; ANSWER SECTION: centos8-opstcore-vm.homenet172-16-96.com. 259200 IN A 172.16.96.20
;; Query time: 2 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Tue Feb 22 16:04:46 PST 2022 ;; MSG SIZE rcvd: 85
Forward and reverse DNS resolution uses two different set of record files. For instance, if you were using BIND as your name server, then there's be one file that controls what IPs belong to which name, and another which controls what name is returned for an IP.
Are you using BIND? Have you got the forward and reverse record files? Have they both got the records you expect to find? Does the named.conf file correctly reference both record files?
If you use something other than BIND, let us know. I didn't notice you saying what you used in prior messages.
On 2/22/22 16:08, Paolo Galtieri wrote:
On 2/21/22 15:56, Jamie Fargen wrote:
dig 172.16.96.20
Do you mean dig -x 172.16.96.20
dig 1.1.1.1 doesn't return the host name:
dig -x 172.16.96.20
returns
; <<>> DiG 9.16.24-RH <<>> -x 172.16.96.20 ;; global options: +cmd ;; connection timed out; no servers could be reached
but
dig centos8-opstcore-vm.homenet172-16-96.com
returns
;; ANSWER SECTION: centos8-opstcore-vm.homenet172-16-96.com. 259200 IN A 172.16.96.20
Tim is correct.
If you are using a hosted nameserver you will have to contact them and request a PTR record for 172.16.96.20 that points to centos8-opstcore-vm.homenet172-16-96.com.
If you are managing your own nameserver and it uses BIND format you need to have a zone file with the correct nameserver name(s).
$TTL 3d $ORIGIN 16.172.in-addr.arpa. @ IN SOA your.name.server. email.your.name.server. 1645631337 16384 2048 1048576 2560 ;; the @ record is all on one line IN NS your.name.server. 20.96 IN PTR centos8-opstcore-vm.homenet172-16-96.com.
Hope this helps, Mike Wright
On Wed, 2022-02-23 at 08:23 -0800, Mike Wright wrote:
If you are using a hosted nameserver you will have to contact them and request a PTR record for 172.16.96.20 that points to centos8-opstcore-vm.homenet172-16-96.com.
I don't think you could use that with an external DNS, 172.16.0.0 is one of the private LAN IP ranges, and shouldn't be able to traverse a network.
Public and private IP address ranges
Class A: 10.0.0.0 — 10.255.255.255. Class B: 172.16.0.0 — 172.31.255.255. Class C: 192.168.0.0 — 192.168.255.255.
Of course they could have one of /those/ service providers which do NATing and don't give their clients public IPs, but they're uncommon. At least that range has about one million available addresses, class C only has about sixty-five thousand addresses (might not be enough for a very large ISP).
But generally speaking, anybody using those IP addresses needs to run a nameserver of some kind within their own LAN.
-
Barry -
Jamie Fargen -
Mike Wright -
Paolo Galtieri -
Tim