Ich habe keine Ahnung, was ich mit DNS mache, und weiß genug, um das Ausmaß meiner Unwissenheit zu kennen, aber ich habe die Aufgabe, ein Remote-Gerät in einem Remote-Netzwerk zu reparieren, auf das ich keinen Zugriff habe. Was anscheinend passiert, ist, dass das DHCP-konfigurierte Gerät in einem bestimmten Netzwerk Namen nicht auflösen kann. In allen anderen Netzwerken läuft alles einwandfrei, sodass wir über das spezielle Verhalten in diesem bestimmten Netzwerk in Bezug auf DHCP und wahrscheinlich DNS nachdenken müssen.
Der Aufruf nslookup
dieses Remote-Netzwerks auf einem Windows-Host erfolgt wie folgt:
nslookup
>server ns1.[theserver].net
Default Server: ns1.[theserver].net
Addresses: 1716:efb7::3
125.75.227.17
> set timout=10
> set q=ns
> [bigsubdomainnamewithdashes].[thedomaininquestion].com
Server: ns1.[theserver].net
Addresses: 1716:efb7::3
125.75.227.17
*** ns1.[theserver].net can't find [bigsubdomainnamewithdashes].[thedomaininquestion].com:No response from server
aber die Angabe der IPv4-Adresse ns1.[theserver].net
allein funktioniert.
> server 125.75.227.17
Default Server: [125.75.227.17]
Address: 125.75.227.17
> [bigsubdomainnamewithdashes].[thedomaininquestion].com
Server: [125.75.227.17]
Address: 125.75.227.17
Non-authoritative answer:
[bigsubdomainnamewithdashes].[thedomaininquestion].com canonical name = [yep a cname].com [yep a cname].com canonical name = [yep a cname].us-east-1.elb.amazonaws.com
Dieses interaktive Verhalten nslookup
ist überraschend. Im ersten Fall nslookup
kennt es einen benannten Server, für den zwei IP-Adressen verfügbar sind, IPv4 und IPv6, und es löst keine Namen auf, für die es IPv4-Adressen gibt. Im zweiten Fall nslookup
wird eine IPv4-Adresse bereitgestellt und löst die Namen wie erwartet auf.
Aufgrund meiner zugegebenermaßen vorhandenen Unwissenheit möchte ich nicht gleich zu der offensichtlichen Antwort springen und stelle daher die Frage: „Welche Zauberei führt nslookup aus, wenn es sowohl eine IPv4- als auch eine IPv6-Adresse erhält?“