เหตุใดระเบียน NS จึงไม่มีที่อยู่ IP

จุดของการบันทึก NS คือการบอกลูกค้าว่าเซิร์ฟเวอร์ชื่อใดจะรู้ว่าที่อยู่ IP ที่แท้จริงสำหรับชื่อโดเมน ตัวอย่างเช่นเคียวรีต่อไปนี้จะบอกคุณว่าถ้าคุณต้องการรับคำตอบที่มีสิทธิ์เกี่ยวกับfacebook.comคุณต้องถาม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

สิ่งนี้ดูดีและมีประโยชน์ แต่ฉันสงสัยว่าทำไมANSWERส่วนนี้มีชื่อโฮสต์และไม่ใช่ IP ของแหล่งข้อมูลที่เชื่อถือได้ ลูกค้าจะได้รับที่อยู่ IP จริงของแหล่งข้อมูลที่เชื่อถือได้หรือไม่ไม่ใช่ชื่อโฮสต์

ฉันหมายความว่าถ้ามันได้รับชื่อโฮสต์มันจะต้องทำแบบสอบถามอื่นเพื่อแก้ไขชื่อโฮสต์นี้เป็น IP แล้วถาม IP ใหม่นี้เกี่ยวกับfacebook.comโดเมนเริ่มต้นที่มันกำลังมองหา มันไม่มีประสิทธิภาพหรือ

ฉันสนใจที่จะตอบว่าชี้ไปที่ย่อหน้าใน RFC บางตัวที่อธิบายปัญหานี้

วิธีแก้ไขปัญหาคือระเบียน DNS ของกาวซึ่งอธิบายไว้ในบันทึกกาวคืออะไร .

RFC 1035 มาตรา 3.3.11รัฐ

"... โปรดทราบว่าคลาสอาจไม่ได้ระบุตระกูลโปรโตคอลซึ่งควรใช้ในการสื่อสาร" กับโฮสต์แม้ว่าโดยทั่วไปจะเป็นคำใบ้ที่แข็งแกร่ง "

การส่งคืนที่อยู่ IP จะเท่ากับการระบุวิธีการที่โฮสต์สามารถติดต่อได้ซึ่งขัดกับ RFC

Jason ให้กลไก DNS ที่แก้ไขปัญหาที่คุณอธิบายไว้ แต่เรายังไม่ได้ดูว่าทำไมสิ่งต่าง ๆจึงถูกทำแบบนี้

สมมติว่าผมเองexample.comและฉันได้ทำสัญญาบางส่วนของเนื้อหาในเว็บไซต์ของฉันให้กับ บริษัท จัดส่งเนื้อหาที่มีชื่อขายกระเป๋า แพลตฟอร์มของพวกเขาต้องการให้เรามอบหมายsub.example.comให้เซิร์ฟเวอร์ของพวกเขาเพื่อให้พวกเขาสามารถควบคุมสิ่งที่ตอบกลับ

; 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

ดังที่คุณบันทึกไว้เราไม่ได้ระบุที่อยู่ IP ของเนมเซิร์ฟเวอร์ของ Contoso ทุกเซิร์ฟเวอร์ของเรารู้คือการบอกอินเทอร์เน็ต"เราไม่ได้จัดการsub.example.comขอขายกระเป๋าแทน" สิ่งนี้สำคัญมากเพราะ:

• เราไม่ได้เป็นเจ้าของ Contoso.com
• เราไม่สามารถคาดหวังได้ว่า Contoso จะประสานการเปลี่ยนแปลงเนมเซิร์ฟเวอร์ของ IP กับลูกค้าของพวกเขาทั้งหมด นั่นคือสิ่งที่จะต้องเกิดขึ้นถ้าเซิร์ฟเวอร์ของเราให้บริการ IP เหล่านั้น

จนถึงตอนนี้ดีมาก หนึ่งปีผ่านไปและไม่รู้จักเรา Contoso กำลังเปลี่ยนที่อยู่ IP ของเนมเซิร์ฟเวอร์ CDN ของพวกเขา เพราะ DNS ทำงานในลักษณะว่ามันไม่ทั้งหมดที่พวกเขาต้องทำคือการปรับปรุงการAบันทึกพวกเขากลับมาและns1.cdnns2.cdn.contoso.com.

นี้จะทำให้เราเป็นจุดสำคัญ: บันทึกกาวอธิบายโดยเจสันอยู่ที่จะจัดการกับ "ไก่และไข่" สถานการณ์ใน DNS เช่นgoogle.comบอกโลกว่าเซิร์ฟเวอร์ของพวกเขาและns1.google.com ns2.google.comคุณไม่ควรสร้างเรคคอร์ดกาวที่ชี้ไปยังโครงสร้างพื้นฐานที่คุณไม่ได้เป็นเจ้าของเว้นแต่มีอยู่เพื่อแก้ไขปัญหาเช่นนี้:

@           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

สิ่งนี้จะหลีกเลี่ยงสถานการณ์ไก่และไข่ แต่ยังทำให้เป็นเช่นนั้น Contoso ต้องประสานการเปลี่ยนแปลง IP ทั้งหมดของเซิร์ฟเวอร์ชื่อเหล่านั้นกับเรา นี่เป็นความเสี่ยงอย่างมากและไม่พึงประสงค์