จริงๆแล้วมันซับซ้อนกว่านั้น - มากกว่าหนึ่ง "รีจิสทรีกลาง (ที่) ถือตารางที่จับคู่โดเมน (www.mysite.com) กับเซิร์ฟเวอร์ DNS" มีหลายลำดับชั้น
- The NS (nameserver) สำหรับทุกโดเมนระดับบนสุด: มีรีจิสทรีกลาง (เซิร์ฟเวอร์ราก) ซึ่งมีเพียงชุดเล็ก ๆ ของรายการเป็น.com, .net, .org, .uk, .us, .auและอื่น ๆ
เซิร์ฟเวอร์เหล่านั้นมีระเบียน NS สำหรับระดับถัดไปลง ที่จะเลือกหนึ่งตัวอย่างเช่นเซิร์ฟเวอร์สำหรับ.ukโดเมนก็มีรายการสำหรับ.co.uk, .ac.ukและโซนระดับที่สองอื่น ๆ ในการใช้งานในสหราชอาณาจักร
เซิร์ฟเวอร์เหล่านั้นมีระเบียน NS สำหรับระดับถัดไป - เพื่อดำเนินการต่อตัวอย่างพวกเขาจะบอกคุณว่าจะหาระเบียน NS ได้จากgoogle.co.ukที่ไหน ในเซิร์ฟเวอร์เหล่านั้นในที่สุดคุณจะพบการจับคู่ระหว่างชื่อโฮสต์www.google.co.ukและที่อยู่ IP
ในฐานะที่เป็นริ้วรอยพิเศษแต่ละชั้นจะทำหน้าที่บันทึก 'กาว' ระเบียน NS แต่ละรายการจะจับคู่โดเมนกับชื่อโฮสต์ - ตัวอย่างเช่นระเบียน NS สำหรับ.ukรายการnsa.nic.ukเป็นหนึ่งในเซิร์ฟเวอร์ ในการที่จะไปสู่ระดับต่อไปเราต้องค้นหาระเบียน NS ที่nic.ukเป็นและพวกเขาก็รวมไปถึงnsa.nic.ukเช่นกัน ดังนั้นตอนนี้เราจำเป็นต้องรู้ IP ของnsa.nic.ukแต่เพื่อหาว่าเราต้องทำแบบสอบถามไปnsa.nic.ukแต่เราไม่สามารถทำแบบสอบถามนั้นจนกว่าเราจะรู้ว่า IP สำหรับnsa.nic.uk...
เมื่อต้องการแก้ไขความไม่แน่ใจนี้เซิร์ฟเวอร์สำหรับการ.ukเพิ่มระเบียนสำหรับการnsa.nic.ukเข้ามาADDITIONAL SECTIONของการตอบสนอง (การตอบสนองด้านล่างตัดแต่งสำหรับความกะทัดรัด):
jamezpolley@li101-70:~$dig nic.uk ns
; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION:
;nic.uk. IN NS
;; ANSWER SECTION:
nic.uk. 172800 IN NS nsb.nic.uk.
nic.uk. 172800 IN NS nsa.nic.uk.
;; ADDITIONAL SECTION:
nsa.nic.uk. 172800 IN A 156.154.100.3
nsb.nic.uk. 172800 IN A 156.154.101.3
หากไม่มีประวัติกาวพิเศษเหล่านี้เราจะไม่สามารถค้นหาเซิร์ฟเวอร์ชื่อได้nic.uk.ดังนั้นเราจึงไม่สามารถค้นหาโดเมนที่โฮสต์อยู่ที่นั่นได้
เพื่อกลับไปที่คำถามของคุณ ...
a) ข้อดีคืออะไร? ทำไมไม่แมปโดยตรงไปยังที่อยู่ IP
สำหรับสิ่งหนึ่งมันช่วยให้การแก้ไขแต่ละโซนจะมีการกระจาย หากคุณต้องการอัปเดตรายการwww.mydomain.co.ukคุณเพียงแค่ต้องแก้ไขข้อมูลในเนมmydomain.co.ukเซิร์ฟเวอร์ของคุณ ไม่จำเป็นต้องแจ้ง.co.ukเซิร์ฟเวอร์กลางหรือ.ukเซิร์ฟเวอร์หรือเซิร์ฟเวอร์ชื่อรูท หากมีเพียงรีจิสทรีกลางเดียวที่แมประดับทั้งหมดลงไปตามลำดับชั้นที่ต้องได้รับการแจ้งเตือนเกี่ยวกับการเปลี่ยนแปลงรายการ DNS ทุกครั้งไปจนสุดลูกโซ่มันจะล้นมือกับการจราจรอย่างแน่นอน
ก่อนปี 1982 นี่เป็นวิธีที่การจำแนกชื่อเกิดขึ้นจริง หนึ่งรีจิสทรีกลางได้รับแจ้งเกี่ยวกับการปรับปรุงทั้งหมดและพวกเขาแจกจ่ายไฟล์ที่เรียกว่าhosts.txtซึ่งมีชื่อโฮสต์และที่อยู่ IP ของทุกเครื่องบนอินเทอร์เน็ต มีการเผยแพร่ไฟล์ใหม่เวอร์ชันนี้ทุกสองสามสัปดาห์และทุกเครื่องบนอินเทอร์เน็ตจะต้องดาวน์โหลดสำเนาใหม่ ก่อนปี 2525 สิ่งนี้เริ่มเป็นปัญหาและดังนั้น DNS จึงถูกคิดค้นเพื่อให้เป็นระบบที่กระจายมากขึ้น
อีกสิ่งหนึ่งนี่จะเป็น Single Point of Failure - หากการลงทะเบียนกลางเดียวล้มเหลวอินเทอร์เน็ตทั้งหมดจะออฟไลน์ การมีระบบแบบกระจายหมายความว่าความล้มเหลวมีผลเฉพาะกับส่วนเล็ก ๆ ของอินเทอร์เน็ตไม่ใช่ทุกสิ่ง
(เพื่อให้มีความซ้ำซ้อนมากขึ้นจริง ๆ แล้วมีกลุ่มเซิร์ฟเวอร์แยกต่างหาก 13 แห่งที่ให้บริการรูทโซนการเปลี่ยนแปลงใด ๆ ในระเบียนโดเมนระดับบนสุดจะต้องถูกผลักไปสู่ทั้ง 13 รายการโดยจินตนาการว่าต้องประสานงานการอัพเดททั้งหมด 13 รายการสำหรับทุกการเปลี่ยนแปลง ไปยังชื่อโฮสต์ใดก็ได้ในโลก ... )
b) หากระเบียนเดียวที่ต้องเปลี่ยนเมื่อฉันกำหนดค่าเซิร์ฟเวอร์ DNS ให้ชี้ไปยังที่อยู่ IP อื่นนั้นจะอยู่ที่เซิร์ฟเวอร์ DNS เหตุใดกระบวนการจึงไม่ประมวลผลทันที
เพราะ DNS ใช้การแคชจำนวนมากเพื่อเร่งความเร็วและลดภาระให้กับ NSes โดยไม่ต้องแคชทุกเวลาเดียวที่คุณเข้าเยี่ยมชมgoogle.co.ukเครื่องคอมพิวเตอร์ของคุณจะต้องออกไปกับเครือข่ายที่จะมองขึ้นเซิร์ฟเวอร์สำหรับ.ukแล้ว.co.ukจากนั้นแล้ว.google.co.uk www.google.co.ukคำตอบเหล่านั้นไม่ได้เปลี่ยนแปลงมากนักดังนั้นการค้นหาพวกเขาทุกครั้งจึงเป็นการเสียเวลาและทราฟฟิกเครือข่าย แต่เมื่อ NS ส่งคืนระเบียนไปยังคอมพิวเตอร์ของคุณจะมีค่า TTL ซึ่งจะบอกให้คอมพิวเตอร์ของคุณแคชผลลัพธ์เป็นเวลาหลายวินาที
ตัวอย่างเช่นระเบียน NS สำหรับ.ukมี TTL 172800 วินาที - 2 วัน Google ยิ่งอนุรักษ์มากขึ้น - ระเบียน NS สำหรับgoogle.co.ukมี TTL 4 วัน บริการที่ต้องพึ่งพาการอัปเดตอย่างรวดเร็วสามารถเลือก TTL ที่ต่ำกว่าได้ตัวอย่างเช่นtelegraph.co.ukมี TTL เพียง 600 วินาทีในระเบียน NS ของพวกเขา
หากคุณต้องการให้การอัปเดตในโซนของคุณใกล้เข้ามาคุณสามารถเลือกที่จะลด TTL ของคุณลงได้เท่าที่คุณต้องการ ยิ่งคุณตั้งค่าไว้ต่ำเท่าใดปริมาณการใช้งานเซิร์ฟเวอร์ของคุณจะยิ่งมากขึ้นเมื่อลูกค้ารีเฟรชบันทึกบ่อยขึ้น ทุกครั้งที่ลูกค้าต้องติดต่อเซิร์ฟเวอร์ของคุณเพื่อทำแบบสอบถามสิ่งนี้จะทำให้เกิดความล่าช้าเนื่องจากช้ากว่าการค้นหาคำตอบในแคชในเครื่องของพวกเขาดังนั้นคุณจะต้องพิจารณาข้อเสียระหว่างการอัพเดทที่รวดเร็วและบริการที่รวดเร็ว
c) หากเหตุผลเดียวของความล่าช้าคือแคช DNS เป็นไปได้ไหมที่จะข้ามพวกเขาไปดังนั้นฉันจะเห็นว่าเกิดอะไรขึ้นในเวลาจริง
ใช่มันเป็นเรื่องง่ายถ้าคุณกำลังทดสอบด้วยตนเองdigหรือเครื่องมือที่คล้ายกัน - เพียงแค่บอกเซิร์ฟเวอร์ที่จะติดต่อ
นี่คือตัวอย่างของการตอบกลับที่แคช:
jamezpolley@host:~$dig telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 319 IN NS ns1-63.akam.net.
telegraph.co.uk. 319 IN NS eur3.akam.net.
telegraph.co.uk. 319 IN NS use2.akam.net.
telegraph.co.uk. 319 IN NS usw2.akam.net.
telegraph.co.uk. 319 IN NS use4.akam.net.
telegraph.co.uk. 319 IN NS use1.akam.net.
telegraph.co.uk. 319 IN NS usc4.akam.net.
telegraph.co.uk. 319 IN NS ns1-224.akam.net.
;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb 2 05:46:02 2012
;; MSG SIZE rcvd: 198
ส่วนธงที่นี่ไม่มีaaธงดังนั้นเราจะเห็นว่าผลลัพธ์นี้มาจากแคชมากกว่าโดยตรงจากแหล่งที่เชื่อถือได้ ในความเป็นจริงเราสามารถเห็นได้ว่ามันมาจาก97.107.133.4ซึ่งเป็นหนึ่งในตัวแก้ไข DNS ของ Linode ความจริงที่ว่าคำตอบนั้นถูกส่งออกมาจากแคชใกล้กับฉันมากนั่นหมายความว่าฉันใช้เวลา 0msec ในการรับคำตอบ แต่อย่างที่เราจะเห็นในอีกสักครู่ราคาที่ฉันจ่ายสำหรับความเร็วนั้นคือคำตอบนั้นล้าสมัยไปเกือบ 5 นาที
ในการเลี่ยงผ่านตัวแก้ไขของ Linode และตรงไปที่แหล่งที่มาเพียงเลือกหนึ่งใน NSes เหล่านั้นและบอกให้ขุดติดต่อโดยตรง:
jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 600 IN NS use2.akam.net.
telegraph.co.uk. 600 IN NS eur3.akam.net.
telegraph.co.uk. 600 IN NS use1.akam.net.
telegraph.co.uk. 600 IN NS ns1-63.akam.net.
telegraph.co.uk. 600 IN NS usc4.akam.net.
telegraph.co.uk. 600 IN NS ns1-224.akam.net.
telegraph.co.uk. 600 IN NS usw2.akam.net.
telegraph.co.uk. 600 IN NS use4.akam.net.
;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb 2 05:48:47 2012
;; MSG SIZE rcvd: 198
คุณจะเห็นได้ว่าในเวลานี้ผลที่ได้รับการให้บริการโดยตรงจากแหล่งที่มา - หมายเหตุaaธงซึ่งบ่งชี้ว่าผลลัพธ์ที่มาจากแหล่งที่เชื่อถือได้ ในตัวอย่างก่อนหน้าของฉันผลลัพธ์มาจากแคชภายในเครื่องของฉันดังนั้นจึงไม่มีการaaตั้งค่าสถานะ ฉันเห็นว่าแหล่งข้อมูลที่เชื่อถือได้สำหรับโดเมนนี้ตั้งค่า TTL 600 วินาที ผลลัพธ์ที่ฉันได้รับก่อนหน้านี้จากแคชในพื้นที่มี TTL เพียง 319 วินาทีซึ่งบอกฉันว่าพวกเขานั่งอยู่ในแคชเป็นเวลา (600-319) วินาที - เกือบ 5 นาที - ก่อนที่ฉันจะเห็นพวกเขา
แม้ว่า TTL ที่นี่จะมีเพียง 600 วินาทีผู้ให้บริการอินเทอร์เน็ตบางรายจะพยายามลดทราฟฟิกของพวกเขาให้มากขึ้นด้วยการบังคับให้ตัวแก้ไข DNS ทำการแคชผลลัพธ์นานขึ้น - ในบางกรณีเป็นเวลา 24 ชั่วโมงขึ้นไป มันเป็นแบบดั้งเดิม (ในแบบที่เราไม่ทราบว่านี่คือสิ่งที่จำเป็น แต่เป็นวิธีที่ปลอดภัย) เพื่อสมมติว่าการเปลี่ยนแปลง DNS ที่คุณทำจะไม่ปรากฏให้เห็นทุกที่บน อินเทอร์เน็ต 24-48 ชั่วโมง