☰

Der Dig DNS-Root-Server bietet keinen Antwortbereich

tag-icon • tag-icon domain-name-system
Der Dig DNS-Root-Server bietet keinen Antwortbereich

Ich habe versucht, den Nameserver für comTLD abzurufen. Hier ist die erfolgreiche Ausgabe, wenn dnscrypt-proxyaktiviert ist und der ausgeführte Befehl lautet dig com. ns: graben erfolg

Dies ist das Ergebnis für dig @a.root-servers.net com. ns: dig keine Antwort Abschnitt

Dies ist die Ausgabe über die Online-Dig-Schnittstelle und der Befehl lautetdig NS +noadditional +noquestion +nocomments +nocmd +nostats com. @a.root-servers.net Verknüpfung

;; Truncated, retrying in TCP mode.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.

Über die Online-Dig-Schnittstelle erhalte ich die Information, dass a.rooteine Antwort möglich ist, ich kann sie jedoch nicht in meinem System reproduzieren.

Antwort1

Aufgrund der unerwarteten Ergebnisse, die Sie angezeigt haben, habe ich den Eindruck, dass Sie digin einer Umgebung arbeiten, in der Sie keinen „sauberen“ Netzwerkpfad haben, der es Ihnen ermöglicht, DNS-Abfragen an beliebige Orte zu senden. Etwas fängt die Abfragen ab und verarbeitet sie.

Ihre digAusgabe (unten zitiert) führt mich auf der Grundlage dieser Erkenntnisse zu der oben genannten Schlussfolgerung:

; <<>> DiG 9.18.1-1-Debian <<>> @a.root-servers.net com. ns
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50284
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;com.                           IN      NS

;; Query time: 12 msec
;; SERVER: 2001:503:ba3e::2:30#53(a.root-servers.net) (UDP)
;; WHEN: Wed Jun 15 18:15:11 WIB 2022
;; MSG SIZE  rcvd: 32

  1. Wie Sie in Ihrer Frage bereits sagten, würde man erwarten, dass die comDelegationsdatensätze NSim AUTHORITYAbschnitt für diese Abfrage an einen der Stammserver gerichtet sind. In Ihrer Umgebung ist dies jedoch nicht der Fall.

  2. Die Root-Server bieten definitiv keine Rekursionsdienste an, aber Sie erhalten trotzdem eine Antwort mit dem ra(Rekursion verfügbar) Flagge gesetzt.

  3. Die Abfrage wurde eindeutig an die Adresse gesendet 2001:503:ba3e::2:30(das ist die IP-Adresse von a.root-servers.net), aber das obige Verhalten entspricht nicht dem, was die Root-Server tun würden. Daraus schließe ich, dass in Ihrem Netzwerk etwas anderes eine solche Abfrage abfängt und beantwortet.

Sie können mit Abfragen wie diesen experimentieren:

dig @a.root-servers.net version.bind CH TXT

dig @a.root-servers.net id.server CH TXT

welchekönntegeben Sie einen Hinweis darauf, was eigentlich die Antwort ist.

verwandte Informationen