0

I wonder why fails to retrieve the ipv4 of dk TLD on my Debian 10. It's a valid domain name, the shortest I ever know on earth via (with a A record). Good to test network connection.

When I use , all is running as expected :

dig A +short dk
193.163.102.58

But when I use , dk is prepended to a domain I own, with wildcard enabled. Let's say example.org, so : 

ping -c1 dk
PING dk.example.org (x.x.x.x) 56(84) bytes of data.
64 bytes from x.x.x.x-reverse-dns (x.x.x.x): icmp_seq=1 ttl=57 time=3.72 ms

--- dk.example.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.716/3.716/3.716/0.000 ms

But if I append a dot, it works :

ping -c1 dk.
PING dk (193.163.102.58) 56(84) bytes of data.
64 bytes from static3.prod.dkhm.dk (193.163.102.58): icmp_seq=1 ttl=51 time=24.6 ms

--- dk ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 24.569/24.569/24.569/0.000 ms

Tested both via DoT/stubby and via some public static DNS resolvers in /etc/resolv.conf (same result).

I don't have any local resolver like unbound nor bind.

Nothing interesting matching example.org in /etc directory nor IP address.

My /etc/nsswitch.conf in case of an improper configuration:

[...]
hosts:          files mdns4_minimal [NOTFOUND=return] dns
networks:       files
[...]

Anyone knows what's going on ?

| improve this question | |
2

The shortest domain name is .. This is important because dk is not a fully-qualified domain name. Its human-readable form does not end in a full stop. Ending in a full stop is what denotes a (human-readable form) fully qualified domain name.

The DNS proper works in terms of fully-qualified domain names, which your DNS client library (linked into programs like ping) has to turn dk into, by appending one or more suffixes. Your DNS client is appending the suffix that you see. In the case of the BIND DNS client library that is included in most C libraries, the suffix list comes from directives in /etc/resolv.conf, falling back to the dynamic domain name suffix fed to the operating system (in various ways).

dk. in contrast is a fully-qualfied domain name, and the DNS client library does not pass it through name qualfication.

There is nothing actually going wrong, here.

Further reading

| improve this answer | |
  • . is shortest, but not resolvable. Thanks for explanation, a very good exercise to fully understand FQDN – Gilles Quenot May 15 at 19:48
  • 1
    It most definitely is resolvable. You are erroneously conflating having an A resource record set with being resolvable. – JdeBP May 15 at 20:41
  • Hey, makes sense now. Good to learn some technical details that helps understanding more in depth – Gilles Quenot May 15 at 22:12
  • 1
    @GillesQuenot ping is almost never the good troubleshooting tool to use and is specifically not the one for DNS troubles. getent hosts can show how the resolution is done, based on the content of nsswitch.conf. – Patrick Mevzek Jun 1 at 5:47
  • 1
    @GillesQuenot See man page of resolv.conf, and notably the ndots option that has this text: "The default for n is 1, meaning that if there are any dots in a name, the name will be tried first as an absolute name before any search list elements are appended to it.". And if you look at the search option: "by default, it contains only the local domain name." – Patrick Mevzek Jun 1 at 5:49
1

What is being resolved using dig A dk is an RR A defined the domain, which might or not might be a DNS server; it is not defined as a way of asking the authoritative server(s) of a domain. In the past before MX times, it used to be utilized to point to the address of the email server answering to that domain, functionality which is deprecated nowadays.

For getting the IP addresses of authoritative name servers responsible for the dk TLD, better ask the NS records to a root name server.

$ dig -t NS dk @a.root-servers.net. | sed "s/^/    /"

; <<>> DiG 9.10.6 <<>> -t NS dk @a.root-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2109
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 15
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;dk.                IN  NS

;; AUTHORITY SECTION:
dk.         172800  IN  NS  a.nic.dk.
dk.         172800  IN  NS  b.nic.dk.
dk.         172800  IN  NS  c.nic.dk.
dk.         172800  IN  NS  d.nic.dk.
dk.         172800  IN  NS  l.nic.dk.
dk.         172800  IN  NS  p.nic.dk.
dk.         172800  IN  NS  s.nic.dk.

;; ADDITIONAL SECTION:
a.nic.dk.       172800  IN  A   212.88.78.122
b.nic.dk.       172800  IN  A   193.163.102.222
c.nic.dk.       172800  IN  A   194.0.46.53
d.nic.dk.       172800  IN  A   185.159.198.45
l.nic.dk.       172800  IN  A   192.38.7.242
p.nic.dk.       172800  IN  A   194.0.47.42
s.nic.dk.       172800  IN  A   193.176.144.15
a.nic.dk.       172800  IN  AAAA    2001:1580:0:180d::122
b.nic.dk.       172800  IN  AAAA    2a01:630:0:80::53
c.nic.dk.       172800  IN  AAAA    2001:678:74::53
d.nic.dk.       172800  IN  AAAA    2620:10a:80ab::45
l.nic.dk.       172800  IN  AAAA    2001:7f8:1f::1835:242:0
p.nic.dk.       172800  IN  AAAA    2001:678:78:42:ad::53
s.nic.dk.       172800  IN  AAAA    2a00:d78:0:102:193:176:144:15

;; Query time: 38 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Jun 01 08:26:00 WEST 2020
;; MSG SIZE  rcvd: 455

A Resource Record dk can also be seen pointing to the web server(s) of that domain in that A record, for the convenience of human web visitors. In this case RR A dk. seems to point not to a DNS server, but to an ngINX server (eksempel.dk) that answers with an HTML redirect to www.dk-hostmaster.dk/217.70.186.102.

As for ping showing another name, it is because for a name request such as dk without the dot, it will append the suffix list of the domains used by the DNS resolver as @JdeBP says and resolves to the RR A, and then to the associated PTR DNS record.

Or using the dot (dk.) with ping, it resolves to the A RR of dk., 193.163.102.58, and then gets the PTR/reverse RR of 193.163.102.58, static3.prod.dkhm.dk.

static3.prod.dkhm.dk is a default generated name, for a production network, of the organization responsible for the dk domain.

$ nslookup
> set type=A
> dk.
Server:     127.0.0.1
Address:    127.0.0.1#53

Non-authoritative answer:
Name:   dk
Address: 193.163.102.58
> 193.163.102.58
Server:     127.0.0.1
Address:    127.0.0.1#53

Non-authoritative answer:
58.102.163.193.in-addr.arpa name = static3.prod.dkhm.dk.

Or monitoring the ping:

ping -c1 dk.

With a tcpdump:

$ sudo tcpdump -n port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:44:04.742533 IP 192.168.5.143.46424 > 192.168.5.2.53: 12659+ A? dk. (20)
12:44:04.744365 IP 192.168.5.2.53 > 192.168.5.143.46424: 12659*- 1/0/0 A 193.163.102.58 (48)
12:44:04.849969 IP 192.168.5.143.46424 > 192.168.5.2.53: 37304+ PTR? 58.102.163.193.in-addr.arpa. (45)
12:44:04.893196 IP 192.168.5.2.53 > 192.168.5.143.46424: 37304 1/0/1 PTR static3.prod.dkhm.dk. (117)

PS In BIND parlance, you define the above mentioned RR A as:

$ORIGIN dk.
@          IN       A   193.163.102.58

RR = Resource Record

TLDR It is not a wrong DNS answer, it is documented and expected behaviour.

"Off-topic" remark: Oddly enough, eksempel.dk seems to be a documentation/training/development server, which is further confirmed by it using a let's encrypt certificate.

| improve this answer | |
  • "What is being resolved using dig A dk is an RR A associated with the SOA" No, it is asking an A record, that is all. Nothing to do with SOA. "For getting the IP addresses of authoritative name servers responsible for the dk TLD, better ask the SOA records" No, if you want authoritative records, you query for NS records, not SOA again. SOA is mostly used only for internal nameserver housekeeping, outside of people managing it it has almost no relevant use (except for learning the negative TTL to be applied in the zone) – Patrick Mevzek Jun 1 at 5:45
  • Thanks, editing accordingly. You are right. – Rui F Ribeiro Jun 1 at 7:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.