Неверный ответ DNS при использовании ping от iputils-s20180629 и самого короткого имени DNS (с записью «A»): dk
Установите пакет Ubuntu «intel -microcode» и перезагрузите компьютер. Это позаботится о ПК «X86/X86 -64» на базе Intel -.
Установите пакет микрокода amd64 -Ubuntu и перезагрузите компьютер. Это позаботится о ПК «X86 -64» на базе AMD -.
Вам нужна последняя версия вышеперечисленного, которая доступна на -поддерживаемом LTS. В противном случае пакет обновления микрокода может не содержать последних обновлений Intel/AMD.
Самое короткое доменное имя — .. Это важно, потому что dk— это не полностью -квалифицированное доменное имя . Его -удобочитаемая форма не заканчивается точкой. Окончание точки означает полное доменное имя (человека, -удобочитаемую форму ).
Собственно DNS работает с полными -определенными доменными именами, которые ваша клиентская библиотека DNS (, связанная с такими программами, как ping), должна преобразовать dkв , добавив один или несколько суффиксов. Ваш DNS-клиент добавляет суффикс, который вы видите. В случае клиентской библиотеки DNS BIND, которая включена в большинство библиотек C, список суффиксов берется из директив в /etc/resolv.conf, возвращаясь к суффиксу динамического доменного имени, передаваемому в операционную систему (различными способами )..
dk.напротив, является полностью -определенным доменным именем, и клиентская библиотека DNS не пропускает его через уточнение имени.
На самом деле здесь ничего не происходит.
Дополнительная литература
- Джонатан де Бойн Поллард (2017 ). "Понятие полного имени ". Что такое квалификация имени DNS . Часто задаваемые ответы.
То, что разрешается с использованием dig A dk, является RR A, определяющим домен, который может быть или не быть DNS-сервером; он не определяется как способ опроса полномочного сервера (с )домена. В прошлом, до времен MX, он использовался для указания на адрес почтового сервера, отвечающего на этот домен, функциональность, которая в настоящее время устарела.
Для получения IP-адресов авторитетных серверов имен, отвечающих за TLD dk, лучше запросить записи NS на корневом сервере имен.
$ 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
Ресурсная запись dkтакже может быть замечена, указывающая на веб-сервер (s )этого домена в этой записи A, для удобства посетителей сети. В этом случае RR A dk., похоже, указывает не на DNS-сервер, а на сервер ngINX (eksempel.dk), который отвечает перенаправлением HTML на www.dk-hostmaster.dk/217.70.186.102.
Что касается pingпоказа другого имени,это связано с тем, что для запроса имени, такого как dk без точки, он добавит список суффиксов доменов, используемых преобразователем DNS, как говорит и разрешает @JdeBP, к RR A, а затем к связанной записи PTR DNS.
Или с помощью точки (дк. )с ping, он разрешается в A RR dk., 193.163.102.58, а затем получает PTR/обратный RR 193.163.102.58, static3.prod.dkhm.dk.
static3.prod.dkhm.dk— сгенерированное по умолчанию имя для производственной сети организации, ответственной за домен dk.
$ 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.
Или мониторинг пинга:
ping -c1 dk.
С 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 На языке BIND вы определяете вышеупомянутый RR A как:
$ORIGIN dk.
@ IN A 193.163.102.58
RR = запись ресурса
TLDR Это не неправильный ответ DNS, это задокументированное и ожидаемое поведение.
Замечание "Не по -теме" :Как ни странно, eksempel.dkпохоже является сервером документации/обучения/разработки, что дополнительно подтверждается сертификатом let's encrypt.