2:14 p.m.
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
Then it works.
What do I need to do on F34 systems to get DNS lookups working?
Any help is appreciated.
Paolo
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.
2:53 p.m.
On 21 Feb 2022, at 20:15, Paolo Galtieri <pgaltieri(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
3:52 p.m.
On 21 Feb 2022, at 20:15, Paolo Galtieri <pgaltieri(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
4:09 p.m.
On Mon, Feb 21, 2022 at 4:52 PM Barry <barry(a)barrys-emacs.org> wrote:
> On 21 Feb 2022, at 20:15, Paolo Galtieri <pgaltieri(a)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
5:18 p.m.
On 2/21/22 14:09, Jamie Fargen wrote:
On Mon, Feb 21, 2022 at 4:52 PM Barry <barry(a)barrys-emacs.org> wrote:
> On 21 Feb 2022, at 20:15, Paolo Galtieri <pgaltieri(a)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(a)lists.fedoraproject.org
To unsubscribe send an email tousers-leave(a)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.fedora...
Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
5:56 p.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
6:08 p.m.
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
; <<>> 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(a)lists.fedoraproject.org
> To unsubscribe send an email tousers-leave(a)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.fedora...
> Do not reply to spam on the list, report
it:https://pagure.io/fedora-infrastructure
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email tousers-leave(a)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.fedora...
Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
4:17 a.m.
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.
--
uname -rsvp
Linux 3.10.0-1160.53.1.el7.x86_64 #1 SMP Fri Jan 14 13:59:45 UTC 2022 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
10:23 a.m.
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
6:40 p.m.
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.
--
uname -rsvp
Linux 5.11.22-100.fc32.x86_64 #1 SMP Wed May 19 18:58:25 UTC 2021 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
801
days inactive
804
days old
9 comments
5 participants
participants (5)
-
Barry -
Jamie Fargen -
Mike Wright -
Paolo Galtieri -
Tim