Dlaczego rekordy NS nie zawierają adresów IP?

Celem rekordu NS jest poinformowanie klienta, który serwer nazw na pewno zna rzeczywisty adres IP nazwy domeny. Na przykład następujące zapytanie mówi, że jeśli chcesz uzyskać wiarygodną odpowiedź na swój temat facebook.com, musisz zapytać a.ns.facebook.com:

> dig ns facebook.com                                                                                                                                       19:58:27

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> ns facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32063
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;facebook.com.          IN  NS

;; ANSWER SECTION:
facebook.com.       65000   IN  NS  a.ns.facebook.com.
facebook.com.       65000   IN  NS  b.ns.facebook.com.

;; Query time: 13 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sun Mar 20 19:58:40 CET 2016
;; MSG SIZE  rcvd: 65

To wydaje się fajne i przydatne, ale zastanawiam się, dlaczego ANSWERsekcja zawiera nazwę hosta, a nie adres IP wiarygodnego źródła? Czy nie byłoby łatwiej klientowi uzyskać rzeczywisty adres IP wiarygodnego źródła, a nie nazwę hosta?

Mam na myśli, że jeśli otrzyma nazwę hosta, będzie musiał wykonać kolejne zapytanie, aby przekształcić tę nazwę hosta w adres IP, a następnie zapytać ten nowy adres IP o początkową facebook.comdomenę, której szukał. Czy to nie jest nieefektywne?

Byłbym zainteresowany odpowiedzią, która wskazuje mi kilka akapitów w niektórych RFC, które wyjaśniają ten problem.

Rozwiązaniem problemu są rekordy kleju DNS, które opisano w części Czym jest rekord kleju? .

RFC 1035 sekcja 3.3.11 stwierdza

„... Należy zauważyć, że klasa może nie wskazywać rodziny protokołów, które powinny być używane do komunikowania się„ z hostem, chociaż zazwyczaj jest to silna wskazówka ”.

Zwrócenie adresu IP byłoby równoznaczne ze wskazaniem metody, z którą można się skontaktować z hostem, co jest sprzeczne z RFC.

Jason zapewnił mechanizm DNS, który działa w oparciu o opisany przez Ciebie problem, ale nadal nie zastanawialiśmy się, dlaczego tak się dzieje.

Powiedzmy, że jestem właścicielem example.comi zleciłem część mojej witryny internetowej firmie dostarczającej treści o nazwie Contoso . Ich platforma wymaga od nas delegowania sub.example.comna ich serwery nazw, aby mogli kontrolować, jakie odpowiedzi są zwracane.

; SOA and MX omitted from this example
$ORIGIN example.com.

@           IN      NS            ns1
@           IN      NS            ns2

; delegate sub.example.com to Contoso's nameservers
sub         IN      NS            ns1.cdn.contoso.com.
sub         IN      NS            ns2.cdn.contoso.com.

; this is ours, not Contoso's
www         IN      A             198.51.100.1

Jak zauważyłeś, nie podaliśmy adresów IP serwerów nazw Contoso. Wszystko, co nasz serwer wie, to powiedzieć internetowi „nie zarządzamy sub.example.com, zamiast tego zapytaj Contoso” . Jest to bardzo ważne, ponieważ:

• Nie jesteśmy właścicielem Contoso.com.
• Nie możemy oczekiwać, że Contoso będzie koordynować zmianę adresów IP serwerów nazw ze wszystkimi swoimi klientami. Właśnie to musiałoby się stać, gdyby nasz serwer zapewniał te adresy IP.

Jak na razie dobrze. Minął rok i nie wiadomo nam, że Contoso zmienia adresy IP swoich serwerów nazw CDN. Ponieważ DNS działa tak, jak działa, wystarczy zaktualizować Arekordy, do których zwracają, ns1.cdni ns2.cdn.contoso.com..

To prowadzi nas do ważnej kwestii: rekordy kleju opisane przez Jasona istnieją, aby poradzić sobie ze scenariuszami „kurczaka i jajka” w DNS, takimi jak google.commówienie światu, że ich serwerami nazw są ns1.google.comi ns2.google.com. Nigdy nie należy tworzyć zapisów klejów wskazujących na infrastrukturę, której nie jesteś właścicielem, chyba że istnieją, aby rozwiązać taki problem:

@           IN      NS            ns1
@           IN      NS            ns2

; delegate sub.example.com to ns1 and ns2.sub.example.com
sub         IN      NS            ns1.sub
sub         IN      NS            ns2.sub

; provide the IP addresses of ns1 and ns2 so that nameservers
; on the internet can find them.
;
; these IP addresses are owned by Contoso, not us, and they must
; coordinate changes to these IPs with us
ns1.sub     IN       A            203.0.113.10
ns1.sub     IN       A            203.1.113.10

Pozwala to uniknąć scenariusza z kurczakiem i jajkiem, ale sprawia, że ​​Contoso musi z nami koordynować każdą zmianę adresu IP tych serwerów nazw. Jest to bardzo podatne na ryzyko i niepożądane.