web-dev-qa-db-ja.com

whoisによって報告されたネームサーバーがnslookupによって報告されたネームサーバーと一致しないとはどういう意味ですか?

現在、いくつかのレコードをネームサーバーの新しいセットに移動することを調査しており、それに備えて調査を行うと、混乱を招くミスマッチが見つかりました。状況に関する少しの背景-

  • それが注目に値する場合、それは.com.auドメインです(そうではないと思います)。
  • ここにはいくつかの関係者がいます-私が当初印象を持っていたウェブホスティング会社は、ネームサーバーを提供していました。私が考え始めているレジストラは、実際にそれらを提供するものかもしれません。そして、私が働いている会社は、レコードの1つを上書きする内部DNSサーバーを持っています(これは重要ではないと思いますが、ネットワークの外部のオンラインツールを使用してwhois/nslookupクエリを作成し、これを保証しようとしています)物事を複雑にすることはありません)。
  • 質問を一般的にするために、これらの関係者とそのネームサーバーHostCo、RegCo、およびOurCoを呼び出し、問題のドメイン* .ourco.com.auを呼び出します。

ここに私が見ている2つの矛盾する結果があります(難読化):

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  ###.###.###.###

hostCoがネームサーバーをホストすることを提案します。

>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)

regCoがそれらをホストすることを示唆しています。

さらに調査を行いました。 この質問 を読んで DNS伝播ツールDavid Precious によって設計されました。このツールは、RegCoネームサーバーを返し、「応答するすべてのサーバーが同じ回答に同意した」ことを通知します。

さらに、次のようにHostCoのネームサーバーでドメインをnslookupしようとしました。

>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:  ###.###.###.###

これは、HostCoがそのアドレスのルートインターネットネームサーバーを指すだけであることを示唆しています...私は思う。

最後に、RegCoのドメイン管理ツールにログオンすると、ns1.hostco.com.auとns2.hostco.com.auが「Domain Info」セクションとネームサーバーを設定したセクションの両方にドメインのネームサーバーとしてリストされます。 [DNSの詳細の更新]セクションには、すべてのホストの詳細と、適切なMX、CNAME、およびAレコードが含まれています。

私の理論では、RegCoのネームサーバーセクションの情報が誤って入力されたため、ドメイン情報とwhoisも間違っているということです。その場合、「DNS詳細の更新」の設定は使用されているものであり、現在のネームサーバーはRegCoを使用していると安全に言えます。私がこの理論で見る唯一の欠点は、もしそれが本当なら、それがDNSリクエストを誤ってHostCoに向けていないということであり、それは物事が機能してはならないことを意味しないでしょうか?

誰でも私の理論を確認または否定できますか?

最初の編集

これがまだ十分に混乱していない場合は、 closetnoc が示唆するDig + traceの結果を以下に示します。

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

レジストラがネームサーバーを保持しているという私の理論を損なう

2
Chris O'Kelly

あなたの状況は奇妙なものであり、あなたの質問は興味をそそる以上のものです。これは誰にとっても非常に紛らわしい状況になるので、この質問が役立つと思います。私はこれを毎日行いますが、問題の中に見落としがちなヒントがあったとしても、それは私を逃しました。

nslookupまたはwhoisを使用すると、返されるデータが信頼できない回答である可能性があります。これは、それがゴールドスタンダードではないことを意味します。通常は信頼できる回答が必要ですが、回答が信頼できるかどうかは必ずしも明確ではありません。 whoisの結果は正しく、nslookupは信頼できませんでした。しかし、推測せずに何が起こっているのかを実際に知るにはどうすればよいですか?確実に死にたい場合はどうしますか?

私はDig +trace mydomainname.com anyを使用して確実に知っています。このコマンドは、ルートネームサーバーからサイトのドメイン名機関までトレースします。これにより、どのエントリが正しいかを知ることができます。 SOA(権限のステートメント)レコード、Aレコード、NSレコード、MXレコードなどを検索して、どのDNSエントリのセットが信頼できるものであるかを知ることができます。 。

この場合、ホスト会社が当局であり、レジストラの記録が正しくありません。レジストラのコントロールパネルにログオンし、エントリが修正されていることを確認する必要があります。この場合、Aレコードはすべて間違っている可能性が高いため、安全のために削除する必要があります。また、ネームサーバーをホストのドメインネームサーバーに変更することもできます。 MXレコードがある場合は、それを削除できますが、最初に、またはその後すぐにホストDNSコントロールパネル内に存在することを確認します。

レジストラのDNSエントリが問題を混乱させているようです。このデータがユーザーのサービスを中断する可能性があります。これらのDNSエントリを修正および/または削除すると、問題が解消され、気付かない問題を解決できる場合があります。

2
closetnoc

ここに示されているデータに基づいて:

レジストラのネームサーバー(RegCo)にある権限開始レコードは、レジストラのネームサーバーを指します。

レジストラのネームサーバーには、ドメインのNSレコードがあります。

NSレコードはHostCoを指します。

HostCoにはネームサーバーがあり、Aレコードなどを提供するために使用できます。

それはエラーではありません。これがシステムの動作方法です。

SOAはネームサーバーを指していないことに注意してください。どうして? SOAはドメインを見つけるために送信し、ドメインのSOAに送信し、ドメインのSOAに送信します。ドメインのSOAに送信され、....

理論的には、SOAは、他のレジストラに適切に登録された他のドメインのネームサーバーをリストできます。私のレジストリではそれができません。なぜなら(1)それは非常に珍しいことだからです。 (2)なぜそうするのですか? (3)ほとんどの小さなユーザー(あなたや私のような)はそれを台無しにします。

SOAレコードをレジストリのネームサーバーから移動するのはどうですか?はい、できます。別のレジストリに移動できます。

技術的には、あなたのSOAレコードをホストするためのレジストリ(ドメイン名を登録する組織)は必要ありません。あなたはSOAに他の方法を見つける必要があります_レコード。しかし、自分より先に進まないでください。

管理したい場合 サブドメイン、独自のネームサーバーにSOAレコードを配置できます。サブドメインのメカニズムはゾーン転送の代わりにDNSグルーレコードを使用するため、ドメインレベルでさらにAレコードが必要です。

1
david