異なるNSレコードを信頼できるDNSで信頼できるものとして設定する
ドメインのDNSサーバーをレジストラ上の権限のあるDNSサーバーの1つのセットに設定しています。ただし、ドメインのこれらのDNSサーバーゾーンファイルには、別のNSレコードのセットがあります。一部のDNSサーバーは、要求をNSサーバーはゾーンファイルに設定されていますが、他の一部（Google、レベル3、OpenDNSのパブリックDNSサーバーなど）はレコードを適切に解決していません。適切なNSレコードを返しますが、サブ委任されたDNSサーバーのAレコードが返されていません。以下に多くの出力を提供しましたが、その要点は、リクエストがNSレコードを参照していないことです。ドメインのQUICKROUTEDNS.COMに設定します。これは、AmazonのクラウドDNSを指すNSレコードです。代わりに、QUICKROUTEDNS.COMでリクエストが停止します。DNSサーバーにクエリを続行するように指示するにはどうすればよいですか？レジストラでDNSレコードを変更せずに、ドメインの権限があるとしてAmazonに送信しますか？
次に例を示します。
レジストラでのドメインのDNSレコード：
Name Server: NS1.QUICKROUTEDNS.COM
Name Server: NS2.QUICKROUTEDNS.COM
Name Server: NS3.QUICKROUTEDNS.COM
ドメインのNSレコードをプルする（権限のあるDNS、QUICKROUTEDNS.COMでは、これらのサーバーはNSレコード）として設定されています）：
$ Host -t NS domain.com
domain.com name server ns-1622.awsdns-10.co.uk.
domain.com name server ns-1387.awsdns-45.org.
domain.com name server ns-774.awsdns-32.net.
domain.com name server ns-48.awsdns-06.com.
ドメインをホストしているAmazon DNSサーバーからのAレコード：
$ Host www.domain.com ns-1387.awsdns-45.org
Using domain server:
Name: ns-1387.awsdns-45.org.
Address: 205.251.197.107#53
Aliases:
www.domain.com has address 201.201.201.201
それでも、特定のネームサーバーにリクエストすると、次のようになります。
$ Host www.domain.com 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
Host www.domain.com not found: 3(NXDOMAIN)
これは、ほぼすべてのDNSサーバー間で一貫していますが、期待どおりにAレコードを報告するFEWがあります。
AレコードをプルしようとしたときのDig + trace出力は次のとおりです。
$ Dig @8.8.8.8 www.domain.com A +trace
; <<>> Dig 9.8.3-P1 <<>> @8.8.8.8 www.domain.com A +trace
; (1 server found)
;; global options: +cmd
. 1341 IN NS m.root-servers.net.
. 1341 IN NS j.root-servers.net.
. 1341 IN NS a.root-servers.net.
. 1341 IN NS d.root-servers.net.
. 1341 IN NS f.root-servers.net.
. 1341 IN NS c.root-servers.net.
. 1341 IN NS b.root-servers.net.
. 1341 IN NS e.root-servers.net.
. 1341 IN NS i.root-servers.net.
. 1341 IN NS h.root-servers.net.
. 1341 IN NS g.root-servers.net.
. 1341 IN NS l.root-servers.net.
. 1341 IN NS k.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 58 ms
net. 172800 IN NS a.gtld-servers.net.
net. 172800 IN NS e.gtld-servers.net.
net. 172800 IN NS c.gtld-servers.net.
net. 172800 IN NS b.gtld-servers.net.
net. 172800 IN NS g.gtld-servers.net.
net. 172800 IN NS i.gtld-servers.net.
net. 172800 IN NS j.gtld-servers.net.
net. 172800 IN NS k.gtld-servers.net.
net. 172800 IN NS h.gtld-servers.net.
net. 172800 IN NS f.gtld-servers.net.
net. 172800 IN NS d.gtld-servers.net.
net. 172800 IN NS m.gtld-servers.net.
net. 172800 IN NS l.gtld-servers.net.
;; Received 503 bytes from 192.36.148.17#53(192.36.148.17) in 586 ms
domain.com. 172800 IN NS ns1.quickroutedns.com.
domain.com. 172800 IN NS ns2.quickroutedns.com.
domain.com. 172800 IN NS ns3.quickroutedns.com.
;; Received 153 bytes from 192.55.83.30#53(192.55.83.30) in 790 ms
domain.com. 3600 IN SOA cns1.atlantic.net. noc.atlantic.net. 2016033004 28800 7200 604800 3600
;; Received 88 bytes from 69.16.156.227#53(69.16.156.227) in 712 ms
ご覧のとおり、QUICKROUTEDNS.COMネームサーバーにのみアクセスし、Amazonネームサーバーからのリクエストは行いません。では、DNSサーバーにAmazonサーバーからクエリをフェッチし、QuickRouteDNS.COMで停止しないようにするにはどうすればよいですか？
ここで実際に2つの質問があり、それらは直接互いに矛盾します。
- レジストラでDNSレコードを変更せずに、ドメインに対する権限があるとしてAmazonへのクエリを続行するようにDNSサーバーに指示するにはどうすればよいですか？
- DNSサーバーにAmazonサーバーからクエリをフェッチし、QuickRouteDNS.COMで停止しないように指示するにはどうすればよいですか？
DNS階層内のすべての委任は、最後の委任よりも具体的である必要があります。つまり、サブドメインを委任することはできますが、サーバーに委任された名前とまったく同じre-delegateはできません。正しい解決策は、回避しようとしているレジストラレベルで構成を変更することです。
あなたが今持っているのは、NSレコードの不一致として知られている一般的な誤設定です。これは、この設計が達成可能であるという誤った印象を与えます。 DNSの概念を十分に理解せずに従う必要があります。私があなたを失った場合は、レジストラデータを修正することが問題に対処する適切な方法であることを当然のことと考えてください。
説明のために、次の2つのゾーンスニペットの例を示します。
$Origin example.com
@ 2941 IN SOA ns1.example.com. someone.example.com. (
2015071001 ; serial
7200 ; refresh (2 hours)
900 ; retry (15 minutes)
7200000 ; expire (11 weeks 6 days 8 hours)
3600 ; minimum (1 hour)
)
@ IN NS ns1
@ IN NS ns2
sub IN NS ns1.contoso.com.
sub IN NS ns2.contoso.com.
Contoso.comネームサーバー：
$Origin sub.example.com.
@ 2941 IN SOA ns1.sub.example.com. someone.contoso.com. (
2015071001 ; serial
7200 ; refresh (2 hours)
900 ; retry (15 minutes)
7200000 ; expire (11 weeks 6 days 8 hours)
3600 ; minimum (1 hour)
)
@ IN NS bagel.contoso.com.
@ IN NS bacon.contoso.com.
NSレコードはsub.example.comに対して権限がありますか？ns1とns2.contoso.comであると思われた場合、それは間違いです。一般的な考えでは、委任を実行するネームサーバーは、その委任を定義するために使用されるNSレコードに対して権限があるとは見なされません。権限のある定義は代わりにの受信側のゾーンによって所有されます代表団。
baconとbagelが信頼できることを確認しました。ここでそれほど明白ではないのは、名前を付ける人が必ずしもすぐにそれを理解するわけではないということです。委任は誠実にフォローされ、委任を受信するサーバーが信頼できると最初に想定されます。脳の損傷が発生するのは、それらのNSレコードが更新されたときだけです。更新は、委任するNSレコードの有効期限が切れるTTLから、それらのNSレコードの値の明示的な要求まで、さまざまなものによってトリガーできます。 NSレコードが上書きされ、新しいサーバーが使用されます。
すべてをまとめると、レジストラが定義したネームサーバーが使用されている最初の期間があり、その後に2番目のネームサーバーのセットが使用されている期間があります。最初の期間中、2番目のサーバーセットにのみ存在するレコードは失敗します。 2番目の期間中、最初のサーバーセットにのみ存在するレコードは失敗します。
問題は最終的には解決するように聞こえるかもしれませんが（すべてが更新されるのを待つだけです）、それは決して起こりません。人々はネームサーバーを再起動するか、キャッシュをフラッシュするか、新しいネームサーバーを立ち上げます。 NSレコードが整合するまで、ドメインはフラックスの不整合な状態で存在します。 DNSの達人はこれを使っていくつかの興味深いことを行うことができますが、このタイプの構成の有効な使用例はほとんどありません。平均的なユーザーは、ネームサーバー定義の競合を絶対に避けてください。
「ドメインのDNSサーバーがレジストラの権限のあるDNSサーバーの1つのセットに設定されています。ただし、ドメインのDNSサーバーのゾーンファイルには、異なるセットのNSレコードがあります。 "は、不完全な委任を作成したことを意味します。この種の設定では何も正しく機能しないため、そこで停止できます。これを行わないでください。
トラブルシューティングに役立つツール： http://dnsviz.net/ および https://www.zonemaster.net/
さらに2つ：
- トラブルシューティングに
Hostを使用せず、Digのみを使用します（ただし、@ somethingと+ traceは矛盾しています） - @Wardが言ったように、あなたがあなたに良い助けを返したいかどうかあなたが尋ねている本当のドメイン名を提供してください