12

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:\Users\Luis>telnet Midnighter- 22
SSH-2.0-OpenSSH_6.7p1 Debian-5

Third party tools accepted. Command line and Open source preferred.

Sopalajo de Arrierez
  • 6,481
  • 1
    The DNS server seems to be working fine. The likely bug is that your system is asking it for an IPV6 address even though your system doesn't have IPV6 connectivity. An IP address can also be unreachable from your system if some ISP in between has a broken router. What kinds of errors do you want to detect? – Mark Plotnick Oct 02 '15 at 16:09
  • Well, @MarkPlotnick, the operating system doesn't have internet fully working. In this case, this is the error. Or so I think, as long as I can not access to domain names (accessing only to IPs is not valid for me). – Sopalajo de Arrierez Oct 02 '15 at 16:13
  • @MarkPlotnick, how can you tell that the DNS server is working? It only answers pings, but doesn't return DNS requestions. – Sopalajo de Arrierez Oct 02 '15 at 16:14
  • If the DNS server weren't working, ping would have said ping: unknown host www.google.es. – Mark Plotnick Oct 02 '15 at 16:18
  • 1
    You can also do nslookup www.google.es or nslookup www.google.es 80.58.61.250 to check the DNS server. – Mark Plotnick Oct 02 '15 at 16:20
  • for completeness, you see that ping www.google.es translated the name into an IP(v6) for you, in the parenthesis: "(2a00:1450:4007:808::101f)". Also: nslookup www.google.es or host www.google.es. as per thrig's answer. – Jeff Schaller Oct 02 '15 at 17:01

2 Answers2

15

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.

Kusalananda
  • 333,661
thrig
  • 34,938
  • While on a Starbuck's WiFi, I noticed that I was getting answers to my DNS queries no matter what IP address I used to specify the DNS server to query. I could only surmise that my DNS queries were being caught and that I was getting spoofed responses. The WiFi subnet was 10.something, and I could do "dig @192.168.X.Y" and get back a correct response, supposedly from 192.168.X.Y . I could use any IP address and I'd get back a (spoofed) response from that IP. – Marnix A. van Ammers Jul 03 '22 at 21:50
0

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

Alexis Wilke
  • 2,857