☰

So teilen Sie die DNS-Konfiguration auf zwei Server auf

tag-icon • tag-icon domain-name-system dns-zone amazon-route53 ns-record
So teilen Sie die DNS-Konfiguration auf zwei Server auf

ich habe beidesAWS Route53und eindedizierter Server DNS-Conf

Ich habe versucht, NSRekorde aufzustellen

 - ns111.awsdns-xz.co.
 - ns112.awsdns-xz.co.
 - ns113.awsdns-xz.co.

Grundsätzlich möchte ich erreichen, dass auf beiden Servern mehrere unabhängige DNS-Einträge vorhanden sind, die von zwei verschiedenen Personen verwaltet werden.

NS-Record-Domain-Registrar

ns1.xxx.ovh.com

DNS-Einträge

dedicatedServer.ovh.com
  a  : example.com    
       sub.example.com 
  mx : mx.example.com 
  ns : ns111.awsdns-xz.co.
     : ns112.awsdns-xz.co.
     : ns113.awsdns-xz.co.
             on AWS router 
                  site2.example.com  -> loadbalancer 
                  site3.example.com  -> elasticbeanstalk

Ist diese Konfiguration in Ordnung und wird sie funktionieren?

2 Stunden und es funktioniert immer noch nicht. Soll ich die Ausbreitungsperiode abwarten?

Antwort1

Ich glaube nicht, dass das funktionieren wird, da die Öffentlichkeit keinen Zugriff darauf hat (und nicht einmal danach suchen kann).

Ok, nehmen wir an, Sie haben eine Domainexample.comdas registriert ist und auf Registrarebene und es hat NS-Einträge, die aufns1.xxx.ovh.com– diese Informationen werden an die DNS-Zone für die .com-Domäne weitergegeben, um die Delegierung für die Domäne site.com einzurichten.

Auf dem Server ns1.xxx.ovh.com würde ein funktionierender DNS-Server mit konfigurierter Zone example.com vorhanden sein. Sobald irgendjemand einen Datensatz abfragt, iteriert dieser von „root“ zu ns1.xxx.ovh.com, dem autoritativen Server für diese Domäne, und dieser Server weiß es oder weiß es nicht …

Der NS-Eintrag für die Zone ist auf der höheren Ebene wichtiger als auf der Domänenebene selbst und führt nicht zu einer Abfrage durch den „nächsten Server“ …

Wenn Sie Datensätze für die Subdomänen Site2 und Site3 in AWS verwalten möchten, müssen Sie die Subdomäne direkt an ns1.xxx.ovh.com delegieren.

site2.example.com. 3600 IN NS ns111.awsdns-xz.co.
site2.example.com. 3600 IN NS ns112.awsdns-xz.co.
site2.example.com. 3600 IN NS ns113.awsdns-xz.co.
site3.example.com. 3600 IN NS ns111.awsdns-xz.co.
site3.example.com. 3600 IN NS ns112.awsdns-xz.co.
site3.example.com. 3600 IN NS ns113.awsdns-xz.co.

Sobald die Abfrage bei ns1.xxx.ovh.com eingeht, wird sie an das AWS DNS-System delegiert, sodass diese Datensätze außerhalb von ns1.xxx.ovh.com verarbeitet werden. Diese Delegierung umfasst die erwähnte Domäne und ihre Subdomänen.site2.example.com NSdeckt site2.site.com und auch www.site2.example.com für die Delegierung ab.

Das Ergebnis würde so aussehen (im Fall von TTL 3600):

@ 3600 IN A <IP>
@ 3600 IN MX 10 mx.example.com.
@ 3600 IN NS ns1.xxx.ovh.com.
sub 3600 IN A <IP>
mx 3600 IN A <IP>
site2.example.com. 3600 IN NS ns111.awsdns-xz.co.
site2.example.com. 3600 IN NS ns112.awsdns-xz.co.
site2.example.com. 3600 IN NS ns113.awsdns-xz.co.
site3.example.com. 3600 IN NS ns111.awsdns-xz.co.
site3.example.com. 3600 IN NS ns112.awsdns-xz.co.
site3.example.com. 3600 IN NS ns113.awsdns-xz.co.

-- bearbeiten --

NS-Eintrag für @ und auch Priorität für MX-Einträge hinzugefügt, um sie in gültiger Form und konsistent zu haben.

verwandte Informationen