This case scenario is for a router with embedded linux, but I think
the answer could be the same for any Linux system.
This is my DNS check:
~ $ cat /etc/resolv.conf nameserver 80.58.61.250 nameserver 80.58.61.254 ~ $ ping 80.58.61.250 PING 80.58.61.250 (80.58.61.250): 56 data bytes 64 bytes from 80.58.61.250: seq=0 ttl=250 time=50.0 ms 64 bytes from 80.58.61.250: seq=1 ttl=250 time=40.0 ms ^C --- 80.58.61.250 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 40.0/45.0/50.0 ms ~ $ ping www.google.es PING www.google.es (2a00:1450:4007:808::101f): 56 data bytes ping: sendto: Network is unreachable ~ $ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=57 time=50.0 ms 64 bytes from 8.8.8.8: seq=1 ttl=57 time=40.0 ms 64 bytes from 8.8.8.8: seq=2 ttl=57 time=40.0 ms ^C --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 40.0/43.3/50.0 ms
As can be seen, there is a response from internet (8.8.8.8) but not from domain names (www.google.es, same for www.google.com).
The DNS server (80.58.61.250) answers to pings.
So I was wondering if the problem could be in that DNS server.
Is there some way, like telneting or similar, to check if a given DNS IP works as it must (this is: answering with a IP address when requested for a domain name)?
For example, when testing a SSH server, a possible trick is:
C:UsersLuis>telnet Midnighter- 22 SSH-2.0-OpenSSH_6.7p1 Debian-5
Third party tools accepted. Command line and Open source preferred.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
ICMP ping is a poor test, as a working DNS server may firewall such requests. DNS-over-UDP has no “got a connection” handshake (SYN/SYN+ACK/ACK) that SSH-over-TCP does, so the best one can do is to throw DNS queries at the presumed DNS server and see what happens. These queries may not work if there is a firewall, or if the query runs afoul DNS rate throttling (at a firewall level or in the DNS server itself, more common these days due to DNS amplification attacks), or depending on the query or the DNS server (e.g. was it a recursive query to a non-recursive NS? or is the client in what the DNS server considers a non-local view? etc.)
I usually use dig (or Net::DNS in Perl programs) for DNS checks. Also look into monitoring software, as these should have support for monitoring, graphing, and reporting on DNS, though may be too heavy for use on an embedded router. Some dig examples:
# possibly get server version info (unreliable) $ dig +short @128.95.120.1 TXT CHAOS version.bind "UW 3A7_3" $ dig +short @8.8.8.8 TXT CHAOS version.bind $
$ dig +short @8.8.8.8 NS example.org b.iana-servers.net. a.iana-servers.net. $ dig +short @8.8.8.8 SOA example.org sns.dns.icann.org. noc.dns.icann.org. 2015082419 7200 3600 1209600 3600 $
$ dig +short @8.8.4.4 A www.example.org 93.184.216.34 $ dig +short @8.8.4.4 CNAME www.example.org $
# checking via TCP and via IPv6 might also be useful $ dig +tcp +short @2001:4860:4860::8888 A www.example.org 93.184.216.34 $
There are also the nslookup and getent hosts commands, if you do not want to install the BIND utils. These are less or very much less powerful than dig, though may suffice if you only need to check that a lookup for a particular host returns a particular IP.
Method 2
Today I ran in a problem which was really weird. The fact was that my DNS server worked for all but one domain. Since it worked for all my other domains, it clearly wasn’t a firewall issue. Not only that, I did not change the firewall in a while.
Looking further, I finally found a page that mentioned the cached version of the zone. That cache was the culprit. I deleted it and restarted the server and it worked again. I just made changes to that domain prior the failures, but still. That’s not an expected behavior.
$ dig NS www.example.com ; <<>> DiG 9.11.3-1ubuntu1.12-Ubuntu <<>> NS www.example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62918 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;www.example.com. IN NS ;; Query time: 605 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Fri Jun 05 13:20:25 PDT 2020 ;; MSG SIZE rcvd: 42
The commands to reset the file:
$ sudo rm /var/lib/bind/example.com.zone.jnl $ sudo systemctl restart bind9
After that, it worked as expected.
An interesting aspect to that: the named-checkzone tool would not return an error since the source file was just fine…
$ sudo named-checkzone example.com /etc/lib/bind/example.com.zone
As I mentioned above, that file was just fine. It’s just the journal that, once in a while, goes bogus on us.
Source: Journal rollfoward failed out of sync. with zone
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0