NS kayıtları neden IP adresleri içermiyor?

NS kaydının amacı, istemciye hangi ad sunucusunun bir etki alanı adı için gerçek IP adresinden emin olacağını bildirmektir. Örneğin, aşağıdaki sorgu size, hakkında yetkili bir yanıt almak facebook.comistiyorsanız sormanız gerektiğini söyler 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

Bu harika ve yararlı görünüyor ama ANSWERbölüm neden yetkili kaynağın IP değil ana bilgisayar adını içerdiğini merak ediyorum ? İstemcinin ana bilgisayar adını değil, yetkili kaynağın gerçek IP adresini alması daha kolay olmaz mıydı?

Ana bilgisayar adını alırsa, bu ana bilgisayar adını bir IP'ye çözmek için başka bir sorgu yapması ve ardından bu yeni IP'yi facebook.comaradığı ilk etki alanı hakkında sorması gerekir. Bu verimsiz değil mi?

Beni bu sorunu açıklayan bazı RFC'deki bazı paragraflara yönlendiren cevapla ilgilenirim.

Sorunun çözümü, Tutkal kaydı nedir? Bölümünde açıklanan DNS tutkal kayıtlarıdır. .

RFC 1035 Bölüm 3.3.11 durumları

"... Sınıfın" genellikle güçlü bir ipucu olmasına rağmen "ana bilgisayarla iletişim kurmak için kullanılması gereken protokol ailesini göstermeyebileceğini unutmayın.

Bir IP adresi döndürmek, ana bilgisayar ile bağlantı kurulabilecek yöntemi belirtmekle eşdeğerdir, bu da RFC'ye aykırıdır.

Jason, tanımladığınız sorun etrafında çalışan DNS mekanizmasını sağladı, ancak yine de işlerin neden bu şekilde yapıldığına bir göz atmadık.

Diyelim ki ben sahibim example.comve web sitesi içeriğimin bir kısmını Contoso adlı bir içerik dağıtım şirketine sözleştim . Platformları, sub.example.comhangi yanıtların döndürüleceğini kontrol edebilmeleri için ad sunucularına yetki vermemizi gerektirir .

; 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

Belirttiğiniz gibi, Contoso'nun ad sunucularının IP adreslerini belirtmedik. Sunucumuzun bildiği tek şey internete "yönetmiyoruz sub.example.com, Contoso'ya sor" demektir . Bu çok önemlidir, çünkü:

• Contoso.com'a sahip değiliz.
• Contoso'nun ad sunucusu IP'lerindeki bir değişikliği tüm müşterileri ile koordine etmesini bekleyemeyiz. Sunucumuz bu IP'leri sağlasaydı tam olarak ne olurdu.

Çok uzak çok iyi. Bir yıl geçti ve bize habersiz Contoso, CDN ad sunucularının IP adreslerini değiştiriyor. DNS olduğu gibi çalıştığı için tek yapmaları gereken, ve Aiçin döndükleri kayıtları güncellemektir .ns1.cdnns2.cdn.contoso.com.

Bu önemli bir noktaya getiriyor: Jason tarafından tarif tutkal kayıtları gibi DNS "tavuk ve yumurta" senaryoları ile başa çıkmak için var google.comonların ad sunucularının olduğunu dünyaya yaymaya ns1.google.comve ns2.google.com. Sen gerektiğini asla onlar böyle bir sorunu çözmek için mevcut değilse sahibi olmadığını altyapı işaret tutkal kayıtlarını oluşturun:

@           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

Bu, tavuk ve yumurta senaryosunu önler, ancak Contoso'nun bu isim sunucularının her IP değişikliğini bizimle koordine etmesini sağlar . Bu çok riskli ve istenmeyen bir durumdur.