Qu'est-ce que cela signifie lorsque les serveurs de noms signalés par Whois ne correspondent pas à ceux signalés par nslookup?
Je suis en train d'étudier la possibilité de transférer certains enregistrements vers un nouvel ensemble de serveurs de noms et, lors de la préparation de la recherche, nous nous sommes heurtés à une inadéquation déroutante. Un peu de contexte sur la situation -
- c'est un domaine .com.au, si c'est important (ne le croyez pas).
- Plusieurs parties sont impliquées ici - la société d’hébergement Web, qui, au départ, j’avais eu l’impression de fournir les serveurs de noms; le greffier, que je commence à penser, pourrait être celui qui les fournit; et l'entreprise pour laquelle je travaille, qui a un serveur DNS interne qui remplace l'un des enregistrements (encore une fois, je ne pense pas que cela devrait avoir de l'importance, je fais mes requêtes whois/nslookup en utilisant des outils en ligne extérieurs à notre réseau pour tenter de le garantir. ne complique pas les choses).
- Pour garder la question générale, appelons ces parties et leurs serveurs de noms HostCo, RegCo et OurCo, et appelons le domaine en question * .ourco.com.au.
Voici les deux résultats contradictoires que je vois (certains obscurcissements):
Whois response for ourco.com.au:
Domain Name ourco.com.au
Last Modified 12-Apr-2014 11:39:38 UTC
Registrar ID RegCo
Registrar Name RegCo
Status ok
Registrant OURCO PTY LTD
Registrant ID ACN ### ### ###
Eligibility Type Company
Registrant Contact ID JB#######
Registrant Contact Name Joe Bloggs
Registrant Contact Email [email protected]
Tech Contact ID CO2415740
Tech Contact Name Chris O\'Kelly
Tech Contact Email [email protected]
Name Server ns1.hostco.com.au
Name Server IP ###.###.###.###
Name Server ns2.hostco.com.au
Name Server IP ###.###.###.###
qui suggère HostCo héberge les serveurs de noms, et
>nslookup - 8.8.8.8
Default Server: google-public-dns-a.google.com
Address: 8.8.8.8
> set querytype=soa
> ourco.com.au
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
ourco.com.au
primary name server = ns1.regco.com.au
responsible mail addr = hostmaster.ourco.com.au
serial = 20030501
refresh = 10800 (3 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 10800 (3 hours)
ce qui suggère que RegCo les héberge.
J'ai fait des recherches plus poussées. la lecture cette question m'a conduit à un outil de propagation DNS conçu par David Precious . Cet outil renvoie les serveurs de noms RegCo et conseille "Tous les serveurs ayant répondu à la même réponse se sont mis d'accord".
De plus, j'ai essayé de nslookup le domaine sur les serveurs de noms HostCo, comme ceci:
>nslookup ourco.com.au ns1.hostco.com.au
(root) nameserver = L.ROOT-SERVERS.NET
(root) nameserver = M.ROOT-SERVERS.NET
(root) nameserver = A.ROOT-SERVERS.NET
(root) nameserver = B.ROOT-SERVERS.NET
(root) nameserver = C.ROOT-SERVERS.NET
(root) nameserver = D.ROOT-SERVERS.NET
(root) nameserver = E.ROOT-SERVERS.NET
(root) nameserver = F.ROOT-SERVERS.NET
(root) nameserver = G.ROOT-SERVERS.NET
(root) nameserver = H.ROOT-SERVERS.NET
(root) nameserver = I.ROOT-SERVERS.NET
(root) nameserver = J.ROOT-SERVERS.NET
(root) nameserver = K.ROOT-SERVERS.NET
Server: UnKnown
Address: ###.###.###.###
Name: ourco.com.au
Address: ###.###.###.###
Ce qui suggère que HostCo pointe juste en arrière vers les serveurs de noms Internet racine pour cette adresse ... je pense.
Enfin, lorsque je me connecte aux outils de gestion de domaine de RegCo, il répertorie ns1.hostco.com.au et ns2.hostco.com.au en tant que serveurs de noms du domaine, à la fois dans la section "Informations sur le domaine" et dans la section dans laquelle je définis des serveurs de noms. Dans la section "Mettre à jour les détails DNS", j'ai les détails pour tous les hôtes, avec les enregistrements MX, CNAME et A appropriés à ce que j'attendais.
Ma théorie est que les informations sur la section du serveur de noms de RegCo ont été mal entrées et que les informations de domaine et le whois sont également erronés; Si tel est le cas, les paramètres de "Update DNS Details" correspondent à ce qui est utilisé et je peux affirmer en toute sécurité que le serveur de noms actuel est avec RegCo. Le seul défaut que je vois dans cette théorie est que, si elle était vraie, ne pointerait-elle pas incorrectement les requêtes DNS vers HostCo, et cela ne voudrait-il pas dire que les choses ne devraient pas fonctionner (elles le sont)?
Quelqu'un peut-il confirmer ou infirmer ma théorie?
Editez le premier
Au cas où cela ne serait pas encore assez déroutant, voici les résultats d’une trace Dig + suggérée par closetnoc :
Dig @8.8.8.8 ourco.com.au +trace any
; <<>> Dig 9.7.0-P1 <<>> @8.8.8.8 ourco.com.au +trace any
; (1 server found)
;; global options: +cmd
. 6055 IN NS f.root-servers.net.
. 6055 IN NS j.root-servers.net.
. 6055 IN NS a.root-servers.net.
. 6055 IN NS c.root-servers.net.
. 6055 IN NS m.root-servers.net.
. 6055 IN NS k.root-servers.net.
. 6055 IN NS g.root-servers.net.
. 6055 IN NS b.root-servers.net.
. 6055 IN NS h.root-servers.net.
. 6055 IN NS d.root-servers.net.
. 6055 IN NS i.root-servers.net.
. 6055 IN NS l.root-servers.net.
. 6055 IN NS e.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 172 ms
au. 172800 IN NS a.au.
au. 172800 IN NS b.au.
au. 172800 IN NS r.au.
au. 172800 IN NS s.au.
au. 172800 IN NS u.au.
au. 172800 IN NS v.au.
au. 172800 IN NS w.au.
au. 172800 IN NS x.au.
au. 172800 IN NS y.au.
au. 172800 IN NS z.au.
;; Received 493 bytes from 199.7.83.42#53(l.root-servers.net) in 993 ms
com.au. 86400 IN NS z.au.
com.au. 86400 IN NS w.au.
com.au. 86400 IN NS y.au.
com.au. 86400 IN NS x.au.
;; Received 273 bytes from 202.12.31.141#53(v.au) in 1038 ms
ourco.com.au. 14400 IN NS ns2.hostco.com.au.
ourco.com.au. 14400 IN NS ns1.hostco.com.au.
;; Received 111 bytes from 37.209.194.5#53(x.au) in 998 ms
ourco.com.au. 14400 IN TXT "v=spf1 +a +mx +ip4:###.###.###.### ?all"
ourco.com.au. 14400 IN MX 0 mail.ourco.com.au.
ourco.com.au. 86400 IN SOA ns1.hostco.com.au. security.bitcloud.com.au. 2013051700 86400 7200 3600000 86400
ourco.com.au. 86400 IN NS ns2.hostco.com.au.
ourco.com.au. 86400 IN NS ns1.hostco.com.au.
ourco.com.au. 14400 IN A ###.###.###.###
;; Received 236 bytes from ###.###.###.####53(ns1.hostco.com.au) in 158 ms
ce qui mine ma théorie selon laquelle le registraire détient les serveurs de noms
Votre situation est étrange et votre question plus qu’intrigante. J'imagine que cette question peut être utile car ce serait une situation très déroutante pour quiconque. Je le fais tous les jours et cela m’a échappé même s’il était facile de faire abstraction des allusions à la question.
Lorsque vous utilisez nslookup ou whois, il est possible que les données renvoyées soient une réponse ne faisant pas autorité, ce qui signifie qu'il ne s'agit pas de l'étalon-or. Normalement, vous voulez une réponse faisant autorité, mais il n’est pas toujours clair si une réponse fait autorité ou non. Le résultat de whois était correct et celui de nslookup ne faisait pas autorité. Mais comment savoir réellement ce qui se passe sans deviner? Et si vous voulez être sûr de rien?
J'utilise Dig +trace mydomainname.com any pour savoir avec certitude. Cette commande effectue une trace des serveurs de noms racine jusqu'à l'autorité de nom de domaine de votre site. De cette façon, vous pouvez savoir quelles entrées sont correctes. Vous pouvez rechercher un enregistrement SOA (déclaration d'autorité), un enregistrement A, un enregistrement NS, un enregistrement MX, etc. afin de savoir quel ensemble d'entrées DNS fait autorité. .
Dans ce cas, votre société hôte est l'autorité et les enregistrements du registraire sont incorrects. Vous devrez vous connecter sur le panneau de contrôle de votre registraire et vérifier que les entrées sont corrigées. Dans ce cas, tout enregistrement A est probablement incorrect et doit être supprimé pour des raisons de sécurité. De même, vous pouvez changer les serveurs de noms pour qu'ils soient les serveurs de noms de domaine de votre hôte. S'il existe un enregistrement MX, vous pouvez le supprimer, mais je m'assurerais qu'il existe déjà dans le panneau de configuration de votre hôte DNS ou très peu de temps après.
Il est apparu que les entrées DNS des bureaux d'enregistrement prêtaient à confusion. Il est possible que ces données interrompent le service pour un utilisateur. La correction et/ou la suppression de ces entrées DNS devrait permettre de résoudre tous les problèmes et de résoudre des problèmes que vous ignorez.
Sur la base des données présentées ici:
L'enregistrement de début d'autorité, dans un serveur de noms du registrar (RegCo), pointe vers un serveur de noms du registrar.
Le serveur de noms du registraire a NS enregistrements pour le domaine.
Les enregistrements NS pointent vers HostCo.
Chez HostCo, il existe des serveurs de noms que vous pouvez utiliser pour fournir des enregistrements A, etc.
Ce n'est pas une erreur. C'est comme ça que le système est censé fonctionner.
Notez que le SOA ne pointe pas vers vos serveurs de noms. Comment pourrait-il? Le SOA vous enverrait chercher votre domaine, qui l'enverrait au SOA de votre domaine, qui l'enverrait au SOA de votre domaine, qui l'enverrait au SOA de votre domaine, ce qui ....
En théorie, la SOA pourrait répertorier un serveur de noms sur un autre domaine correctement enregistré auprès d'un autre registraire. Mon registre ne me permet pas de le faire, car (1) Ce serait assez inhabituel. (2) Pourquoi ferais-je cela? Et (3) la plupart des petits utilisateurs (comme vous et moi) voudraient tout gâcher.
Pourquoi ne pas déplacer l’enregistrement SOA du serveur de noms dans le registre? Oui, tu peux faire ça. Vous pouvez le déplacer vers un autre registre.
Techniquement, vous n'avez pas besoin d'un registre (l'organisation qui/enregistre/votre nom de domaine) pour héberger votre enregistrement SOA: vous devez simplement trouver un autre moyen de/enregistrer/votre SOA record. Mais ne prenons pas d'avance sur nous-mêmes.
Si vous voulez gérer sous-domaines, vous pouvez mettre SOA enregistrements sur vos propres serveurs de noms. Cela nécessite quelques enregistrements A supplémentaires au niveau du domaine, car le mécanisme des sous-domaines utilise des enregistrements de liaison DNS au lieu de transferts de zone.