Once a host has been configured to use the new nameserver one of the simplest tests is the ping utility. From a terminal prompt enter:
ping example.com
This tests if the nameserver can resolve the name example.com to an IP Address. The command output should resemble:
PING example.com (192.168.1.10) 56(84) bytes of data.
64 bytes from ns (192.168.1.10): icmp_seq=1 ttl=64 time=0.800 ms
64 bytes from ns (192.168.1.10): icmp_seq=2 ttl=64 time=0.813 ms
------------------------------
This section has errors in two aspects:
A.
Using "ping" to test hostname resolution is the wrong approach. Ping is a tool that tests if you can get an "ICMP echo request" message to a host and receive an "ICMP echo" message back. Nothing more.
If someone for some reason happens to have a weird configuration in /etc/nsswitch.conf, a completely different name resolution mechanism might return an unuseable or even false (either positive or negative) answer. I suggest moving the "ping" section to come after the "dig" section and rephrasing it to read "now let's demonstrate how applications make use of DNS to resolve a host name".
-----------------------
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.example.com. root.example.com. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL
;
@ IN NS ns.example.com.
@ IN A 192.168.1.10
ns IN A 192.168.1.10
------------------------
There is no "IN A" record for example.com. "ping example.com" will return "ping: unknown host example.com". The ping test should either be for ns.example.com, or the sample zone file should include the IN A record for example.com.
However, I suggest not to include the A record for example.com, as it can be quite confusing for a novice user that what looks like an "upper level" domain name (and is therefore not a "host" or "computer") can have an IP address. The "ping test" (if included at all, see A.) should test for ns.example.com instead of example.com.
Hi all!
https:/ /help.ubuntu. com/8.10/ serverguide/ C/dns-troublesh ooting. html
suggests that:
------- ------- ------- ------- --
ping
Once a host has been configured to use the new nameserver one of the simplest tests is the ping utility. From a terminal prompt enter:
ping example.com
This tests if the nameserver can resolve the name example.com to an IP Address. The command output should resemble:
PING example.com (192.168.1.10) 56(84) bytes of data. ------- ------- ------- --
64 bytes from ns (192.168.1.10): icmp_seq=1 ttl=64 time=0.800 ms
64 bytes from ns (192.168.1.10): icmp_seq=2 ttl=64 time=0.813 ms
-------
This section has errors in two aspects:
A.
Using "ping" to test hostname resolution is the wrong approach. Ping is a tool that tests if you can get an "ICMP echo request" message to a host and receive an "ICMP echo" message back. Nothing more.
If someone for some reason happens to have a weird configuration in /etc/nsswitch.conf, a completely different name resolution mechanism might return an unuseable or even false (either positive or negative) answer. I suggest moving the "ping" section to come after the "dig" section and rephrasing it to read "now let's demonstrate how applications make use of DNS to resolve a host name".
B. /help.ubuntu. com/8.10/ serverguide/ C/dns-configura tion.html), the page before this one, will not enable resolution of the "example.com" name:
The example zone data for example.com, given in (https:/
------- ------- ------- --
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL ------- ------- ---
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.example.com. root.example.com. (
;
@ IN NS ns.example.com.
@ IN A 192.168.1.10
ns IN A 192.168.1.10
-------
There is no "IN A" record for example.com. "ping example.com" will return "ping: unknown host example.com". The ping test should either be for ns.example.com, or the sample zone file should include the IN A record for example.com.
However, I suggest not to include the A record for example.com, as it can be quite confusing for a novice user that what looks like an "upper level" domain name (and is therefore not a "host" or "computer") can have an IP address. The "ping test" (if included at all, see A.) should test for ns.example.com instead of example.com.
regards
Marc