Comment trouver le serveur de noms faisant autorité pour un nom de domaine?

317

Comment puis-je trouver l'origine des enregistrements DNS en conflit?

dns

— Contes binaires
source

413

Vous aurez besoin de l'enregistrement SOA (début de l'autorité) pour un nom de domaine donné, et voici comment vous pouvez l'accomplir en utilisant l' outil de ligne de commande nslookup universellement disponible :

command line> nslookup
> set querytype=soa
> stackoverflow.com
Server:         217.30.180.230
Address:        217.30.180.230#53

Non-authoritative answer:
stackoverflow.com
        origin = ns51.domaincontrol.com # ("primary name server" on Windows)
        mail addr = dns.jomax.net       # ("responsible mail addr" on Windows)
        serial = 2008041300
        refresh = 28800
        retry = 7200
        expire = 604800
        minimum = 86400
Authoritative answers can be found from:
stackoverflow.com       nameserver = ns52.domaincontrol.com.
stackoverflow.com       nameserver = ns51.domaincontrol.com.

La ligne d' origine (ou serveur de noms principal sous Windows) vous indique que ns51.domaincontrol est le serveur de noms principal pour stackoverflow.com .

À la fin de la sortie, tous les serveurs faisant autorité, y compris les serveurs de sauvegarde pour le domaine donné, sont répertoriés.

— Antti Kissaniemi
source

158

nslookup -type = soa stackoverflow.com

— Ben Amada

6

Sous Windows cependant, je ne parviens pas à voir la réponse "Réponses faisant autorité". J'ai Windows 8 et Ubuntu 12 côte à côte, puis la même commande pour le même domaine fonctionne correctement sur Ubuntu mais pas sur Windows.

— Mario Awad

1

méfiez-vous que cela ne montre pas nécessairement les modifications récentes apportées aux configurations DNS, cependant l'utilisation digsemble, pour moi (voir la réponse ci-dessous)

— rogerdpack

6

Qu'est-ce que cela signifie s'il n'y a pas de réponse faisant autorité mais que la réponse sans autorité est correcte?

— Overmind

6

Si vous utilisez nslookup -type=soa stackoverflow.comLinux aujourd'hui (2019-février), la section faisant autorité est vide.

— simpleuser

174

Vous avez utilisé le singulier dans votre question, mais il existe généralement plusieurs serveurs de noms faisant autorité, le RFC 1034 en recommande au moins deux.

Sauf si vous voulez dire «serveur de noms principal» et non «serveur de noms faisant autorité». Les serveurs de noms secondaires font autorité.

Pour connaître les serveurs de noms d'un domaine sous Unix:

  % dig +short NS stackoverflow.com
 ns52.domaincontrol.com.
 ns51.domaincontrol.com.

Pour découvrir le serveur répertorié comme principal (la notion de "principal" est assez floue ces jours-ci et n'a généralement pas de bonne réponse):

% dig +short  SOA stackoverflow.com | cut -d' ' -f1
ns51.domaincontrol.com.

Pour vérifier les écarts entre les serveurs de noms, ma préférence va à l'ancien check_soaoutil, décrit dans le livre Liu & Albitz "DNS & BIND" (éditeur O'Reilly). Le code source est disponible sur http://examples.oreilly.com/dns5/

% check_soa stackoverflow.com
ns51.domaincontrol.com has serial number 2008041300
ns52.domaincontrol.com has serial number 2008041300

Ici, les deux serveurs de noms faisant autorité ont le même numéro de série. Bien.

— bortzmeyer
source

5

dig + short ne donne pas toujours la réponse que j'attends. Par exemple, un site défini comme www.pressero.com, qui est un CNAME pour un autre site - dig + short SOA renvoie simplement la cible CNAME.

— Ross Presser

Comment faire autorité en NS?

— Overmind

1

@Overmind vous ne faites pas une NS "faisant autorité". Si un serveur de noms est configuré comme faisant autorité pour certains domaines, cela signifie qu'il a localement des fichiers de zone (généralement des fichiers textuels plats, mais pourrait également être fait différemment) pour ces domaines et il répond aux requêtes pour eux. Pour être utiles, ils doivent être répertoriés comme enregistrements NS dans la zone parent pour chacun des domaines pour lesquels ils font autorité, sinon personne ne les interrogerait par défaut.

— Patrick Mevzek

@RossPresser, la réponse parlait des enregistrements NS / SOA et je doute que vous le fassiez pour www.pressero.com, vous pensiez probablement aux enregistrements A (qui est le type d'enregistrement par défaut digsi vous ne le spécifiez pas). Mais si nécessaire, ajoutez simplement un tail -1pour récupérer le résultat final.

— Patrick Mevzek

@PatrickMevzek Comme je l'ai dit dans mon commentaire, j'ai utilisé dig +short SOA www.pressero.com. Cela renvoie uniquement la cible CNAME - pas l'enregistrement SOA pour le pressero.comdomaine, ce que j'attendais. tail -1n'aide pas les choses; dig +short SOAn'émet qu'une seule ligne.

— Ross Presser

40

Sur * nix:

$ dig -t ns <domain name>

— aryeh
source

3

Il a demandé les serveurs de noms, pas l'adresse IPv4. Donc, le type (-t) doit être NS, pas A.

— bortzmeyer

1

pourquoi ne pas taper SOA @bortzmeyer?

— Randy L

Euh, parce que cela renvoie le SOA au lieu du résultat NS?

— tripleee

17

J'ai un outil de propagation DNS conçu pour répondre à ce genre de questions.

La source est publiée sous AGPLv3.

(Oui, l'interface est plutôt basique pour le moment :))

Vous pouvez également trouver les serveurs de noms pour un domaine avec la commande "host":

[davidp @ supernova: ~] $ host -t ns stackoverflow.com
serveur de noms stackoverflow.com ns51.domaincontrol.com.
serveur de noms stackoverflow.com ns52.domaincontrol.com.

— David Precious
source

@cacho C'est vrai; Je pourrais bien ajouter cela, si j'en ai l'occasion.

— David Precious

1

C'est cassé, ça montre "502 Bad Gateway nginx / 1.14.2"

— Marco Demaio

8

J'ai trouvé que la meilleure façon d'ajouter toujours l'option + trace:

dig SOA +trace stackoverflow.com

Il fonctionne également avec CNAME récursif hébergé dans un fournisseur différent. + trace trace implique + norecurse donc le résultat est juste pour le domaine que vous spécifiez.

— Alex
source

Notez que si vous utilisez un serveur NS local comme dnsmasq + trace ne retournera rien ...

— Daniel Sokolowski

Cette commande fournit 53 lignes, 3652 octets de sortie, dont la plupart sont des valeurs aléatoires. Comment quelqu'un devrait-il interpréter la sortie pour déterminer quel est le serveur de noms faisant autorité?

— theferrit32

Je l'ai lu de bas en haut. L'enregistrement SOA est ce que vous recherchez. Vous pouvez demander à SOA d'avoir moins de données.

— Alex

6

Le terme que vous devriez rechercher sur Google est «faisant autorité» et non «définitif».

Sous Linux ou Mac , vous pouvez utiliser les commandes whois, dig, host, nslookupou plusieurs autres. nslookuppeut également fonctionner sous Windows.

Un exemple:

$ whois stackoverflow.com
[...]
   Domain servers in listed order:
      NS51.DOMAINCONTROL.COM
      NS52.DOMAINCONTROL.COM

Quant au crédit supplémentaire: Oui, c'est possible.

aryeh a définitivement tort, car sa suggestion ne vous donne généralement que l'adresse IP du nom d'hôte. Si vous utilisez dig, vous devez rechercher des enregistrements NS, comme ceci:

dig ns stackoverflow.com

Gardez à l'esprit que cela peut demander à votre serveur DNS local et donc donner des réponses incorrectes ou obsolètes qu'il a dans son cache.

6

Ces commandes ne sont pas équivalentes. Rien ne dit que les informations fournies par le whois sont à jour. Souvent, ce n'est pas parce que les gens mettent à jour les enregistrements NS dans le fichier de zone sans en informer le registre ou le registraire.

— bortzmeyer

Je n'ai jamais dit qu'ils l'étaient;) Vous pouvez modifier les enregistrements NS dans votre zone autant que vous le souhaitez, tant que la zone parent n'est pas mise à jour, rien ne changera. Et une mise à jour de la zone parent va généralement de pair avec une mise à jour des données whois (au moins avec mes fournisseurs).

5

Nous avons créé un outil de recherche DNS qui vous donne les serveurs de noms faisant autorité du domaine et ses enregistrements DNS communs en une seule demande.

Exemple: https://www.misk.com/tools/#dns/stackoverflow.com

Notre outil recherche les serveurs de noms faisant autorité en effectuant une recherche DNS en temps réel (non mise en cache) sur les serveurs de noms racine, puis en suivant les références de serveurs de noms jusqu'à ce que nous atteignions les serveurs de noms faisant autorité. C'est la même logique que les résolveurs DNS utilisent pour obtenir des réponses faisant autorité. Un serveur de noms faisant autorité au hasard est sélectionné (et identifié) sur chaque requête, ce qui vous permet de trouver des enregistrements DNS conflictuels en effectuant plusieurs requêtes.

Vous pouvez également afficher le chemin de délégation du serveur de noms en cliquant sur "Serveurs de noms faisant autorité" en bas des résultats de la recherche DNS de l'exemple ci-dessus.

Exemple: https://www.misk.com/tools/#dns/stackoverflow.com@f.root-servers.net

— Nitin Agarwal
source

2

Vous pouvez utiliser le service whois. Sur un système d'exploitation de type UNIX, vous exécuteriez la commande suivante. Vous pouvez également le faire sur le Web à l' adresse http://www.internic.net/whois.html .

whois stackoverflow.com

Vous obtiendriez la réponse suivante.

... texte supprimé ici ...

Serveurs de domaine dans l'ordre indiqué: NS51.DOMAINCONTROL.COM NS52.DOMAINCONTROL.COM

Vous pouvez utiliser nslookup ou creuser pour en savoir plus sur les enregistrements d'un domaine donné. Cela pourrait vous aider à résoudre les conflits que vous avez décrits.

— Chris de Vries
source

2

Rien ne dit que les informations fournies par le whois sont à jour. Souvent, ce n'est pas parce que les gens mettent à jour les enregistrements NS dans le fichier de zone sans en informer le registre ou le registraire.

— bortzmeyer

Bien qu'il ne soit pas une réponse directe à la question, "whois" est utile car il vous indique qui sont censés être les serveurs de noms quelque part (même si pour une raison quelconque ils ne le sont pas actuellement).

— SomeoneElse

1

Malheureusement, la plupart de ces outils ne renvoient que l'enregistrement NS fourni par le serveur de noms lui-même. Pour être plus précis dans la détermination des serveurs de noms qui sont réellement responsables d'un domaine, vous devez soit utiliser "whois" et vérifier les domaines qui y sont répertoriés OU utiliser "dig [domaine] NS @ [serveur de noms racine]" et l'exécuter récursivement jusqu'à ce que vous obteniez les listes de serveurs de noms ...

Je souhaite qu'il y ait une simple ligne de commande que vous pourriez exécuter pour obtenir CE résultat de manière fiable et dans un format cohérent, pas seulement le résultat qui est donné par le serveur de noms lui-même. Le but de cela est pour moi de pouvoir interroger environ 330 noms de domaine que je gère afin de pouvoir déterminer exactement vers quel serveur de noms chaque domaine pointe (selon leurs paramètres de bureau d'enregistrement).

Quelqu'un connaît une commande utilisant "dig" ou "host" ou autre chose sur * nix?

2

Facile. Supposons que le domaine soit example.org. Tout d'abord, vous devez trouver les serveurs de noms de ".org" avec 'dig + short NS org.'. Ensuite, vous interrogez l'un d'eux (n'importe qui, ils font tous autorité). Choisissons d0.org.afilias-nst.org. Vous interrogez avec 'dig @ d0.org.afilias-nst.org NS example.org.'.

— bortzmeyer

Le fait que le résolveur renvoie, par défaut, les serveurs de noms répertoriés par le domaine lui-même est une bonne chose. Ce sont les informations faisant autorité. La délégation dans la zone parent ne fait PAS autorité.

— bortzmeyer

Et le pointeur sur whois est un hareng rouge. Les informations du serveur de noms whois sont souvent périmées. La ressource faisant autorité est le DNS.

— tripleee

1

Whois est complètement arbitraire. La valeur que vous voyez dans la liste whois n'a aucun lien technique avec le DNS. C'est souvent obsolète ou bien faux. J'irais jusqu'à dire que les données whois ne devraient presque jamais être fiables. Il existe des registres «fins» et «épais». Les deux registres épais bien connus sont les registres .com et .net. Ces registres contiennent toutes les données DNS et servent des réponses whois fiables. Presque d'autres autres registres sont «chose» et gèrent leurs propres registres whois. Ces données sont souvent erronées.

— Mark

1

Les enregistrements SOA sont présents sur tous les serveurs plus haut dans la hiérarchie, sur lesquels le propriétaire du domaine n'a AUCUN contrôle, et ils pointent tous vers le seul serveur de noms faisant autorité sous le contrôle du propriétaire du domaine.

En revanche, l'enregistrement SOA sur le serveur faisant autorité n'est pas strictement nécessaire pour résoudre ce domaine et peut contenir de fausses informations (ou des serveurs principaux masqués ou autrement limités) et ne doit pas être utilisé pour déterminer le serveur de noms faisant autorité. pour un domaine donné.

Vous devez interroger le serveur faisant autorité pour le domaine de premier niveau pour obtenir des informations SOA fiables pour un domaine enfant donné.

(Les informations sur quel serveur fait autorité pour quel TLD peut être interrogé à partir des serveurs de noms racine).

Lorsque vous avez des informations fiables sur le SOA du serveur faisant autorité TLD, vous pouvez alors interroger le serveur de noms principal lui-même faisant autorité (celui qui se trouve dans l'enregistrement SOA sur le serveur de noms gTLD!) Pour tout autre enregistrement NS, puis procéder à la vérification de tous ces serveurs de noms que vous avez obtenus en interrogeant les enregistrements NS, pour voir s'il y a une incohérence pour tout autre enregistrement particulier, sur l'un de ces serveurs.

Tout cela fonctionne beaucoup mieux / fiable avec Linux et Dig qu'avec Nslookup / Windows.

— Dennis
source

0

Un moyen simple consiste à utiliser un outil de domaine en ligne. Mon préféré est Domain Tools (anciennement whois.sc). Je ne sais pas s'ils peuvent résoudre les enregistrements DNS conflictuels. Par exemple, les serveurs DNS pour stackoverflow.com sont

  NS51.DOMAINCONTROL.COM
  NS52.DOMAINCONTROL.COM

— Kyle Cronin
source

0

J'ai constaté que pour certains domaines, les réponses ci-dessus ne fonctionnent pas. Le moyen le plus rapide que j'ai trouvé est de vérifier d'abord un enregistrement NS. Si cela n'existe pas, recherchez un enregistrement SOA. Si cela n'existe pas, résolvez récursivement le nom en utilisant dig et prenez le dernier enregistrement NS retourné. Un exemple qui correspond à cela estanalyticsdcs.ccs.mcafee.com.

Rechercher un enregistrement NS

host -t NS analyticsdcs.ccs.mcafee.com.

Si aucun NS trouvé, vérifiez un enregistrement SOA

host -t SOA analyticsdcs.ccs.mcafee.com.

Si ni NS ni SOA, faites un récursif complet et prenez le dernier NS retourné

dig +trace analyticsdcs.ccs.mcafee.com. | grep -w 'IN[[:space:]]*NS' | tail -1

Testez que le serveur de noms a renvoyé des travaux

host analyticsdcs.ccs.mcafee.com. gtm2.mcafee.com.

— dannyw
source