Score:0

เซิร์ฟเวอร์ชื่อโดเมน TLD ทำงานอย่างไรในทางปฏิบัติ

ธง cn

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

ขออภัย นี่ดูเหมือนเป็นคำถามง่ายๆ แต่ฉันไม่พบสิ่งใดทางออนไลน์ ฉันพบได้เฉพาะคำอธิบายระดับพื้นผิวของ DNS เช่น อันนี้ โดย CloudFlare แต่ไม่มีอะไรที่จะลงรายละเอียดที่สำคัญ

dave_thompson_085 avatar
jp flag
ในปี 1980 หรือ 1990 ใช่ว่าจะมีปัญหา ปัจจุบัน คุณสามารถซื้อดิสก์ขนาด 1e13 ไบต์ได้ในราคาต่ำกว่า 100 ดอลลาร์สหรัฐ และอาจน้อยกว่า 100 ไบต์ต่อโดเมน ซึ่งอนุญาตให้มีโดเมนได้หลายสิบโดเมนสำหรับทุกคนบนโลก
redpanda2236 avatar
cn flag
@dave_thompson_085 โอเค ฉันเดาว่าสัญชาตญาณในท้องของฉันผิด ฮ่าๆ คุณรู้หรือไม่ว่าพวกเขาจับคู่ชื่อโดเมนกับเนมเซิร์ฟเวอร์ที่ถูกต้องได้อย่างไร มันเป็นตารางแฮชหรือไม่?
dave_thompson_085 avatar
jp flag
อาจจะเป็น. คุณสามารถดูซอฟต์แวร์เซิร์ฟเวอร์ DNS แบบโอเพ่นซอร์สเช่น bind และ djbdns ได้ แต่ตัวดำเนินการ TLD&root เกือบจะใช้ซอฟต์แวร์ที่ปรับแต่งเองหากไม่ใช่ซอฟต์แวร์ที่กำหนดเองทั้งหมด เมื่อพิจารณาถึงความสำคัญแล้ว ฉันพนันได้เลยว่ามีแนวทางปฏิบัติ (หากไม่ใช่กฎโดยสิ้นเชิง) เพื่อ _not_ ทั้งหมดใช้ซอฟต์แวร์เดียวกันเพื่อป้องกันความเสี่ยงของความล้มเหลวทั้งหมดจากจุดบกพร่องหรือช่องโหว่ (คนในแวดวงโทรคมนาคมยังคงจำวันเมื่อ 32 ปีที่แล้วด้วยความเจ็บปวดที่สวิตช์ 'โทร' ของ AT&T ขัดข้องซ้ำแล้วซ้ำเล่าเนื่องจากข้อผิดพลาด ทำให้เครือข่ายทางไกลทั่วประเทศใช้งานไม่ได้เป็นเวลาหลายชั่วโมง)
Score:2
ธง cn

เซิร์ฟเวอร์ชื่อ TLD แก้ไขคำค้นหาและระบุเซิร์ฟเวอร์ชื่อที่เชื่อถือได้ด้วยข้อมูลที่จำเป็นได้อย่างไร

เนมเซิร์ฟเวอร์ TLD ไม่มีอะไรแตกต่างจากเนมเซิร์ฟเวอร์ที่มีสิทธิ์อื่นๆ ที่โหนดอื่นๆ ในแผนผัง DNS ซึ่งเป็นไปตามการออกแบบและคุณสมบัติของโปรโตคอล DNS ในฐานะฐานข้อมูลแบบกระจายอำนาจ

คุณอาจลืม "ทะเบียนเครื่องบิน" DNS จัดการกับความละเอียดหรือที่เรียกว่า "ระนาบความละเอียด" โดยจะอธิบายวิธีรับข้อมูล ไม่ใช่วิธีจัดเก็บข้อมูลตั้งแต่แรก (ยกเว้นการอัปเดต DNS แต่เป็นข้อมูลสำหรับการใช้งานภายในเครื่อง ไม่ใช่ส่วนกลาง)

ระนาบการลงทะเบียนคือมีการลงทะเบียนและผู้รับจดทะเบียนโดยทั่วไป รีจิสทรีจัดการ TLD ช่วยให้มั่นใจได้ว่าเนมเซิร์ฟเวอร์ทำงานและได้รับคำสั่งจากผู้รับจดทะเบียน ผู้รับจดทะเบียนมีลูกค้าปลายทางที่เลือกโดเมนและจดทะเบียน ผู้รับจดทะเบียนจะส่งคำสั่งไปยังสำนักทะเบียนโดยทั่วไปโดยใช้โปรโตคอลที่เรียกว่า EPP

โดยสรุปแล้ว รีจิสทรีจะรักษาฐานข้อมูล (โดยทั่วไปจะเป็นเชิงสัมพันธ์) กับข้อมูลทั้งหมด รวมถึงสิ่งที่ไม่ได้เผยแพร่ใน DNS แต่พร้อมใช้งานผ่านโปรโตคอลอื่นๆ เช่น whois หรือ RDAP (เช่น: ผู้ติดต่อ)ฐานข้อมูลนี้ใช้เพื่อกำหนดค่าเนมเซิร์ฟเวอร์ที่มีสิทธิ์ TLD พร้อมการมอบหมายทั้งหมด หรือที่รู้จักในชื่อ สวพ.FM91 บันทึก

เซิร์ฟเวอร์ชื่อ TLD สำหรับ ".com" เก็บเซิร์ฟเวอร์ชื่อที่เกี่ยวข้องสำหรับทุกเว็บไซต์ที่มี TLD ".com" หรือไม่

ใช่ตามการสนทนาข้างต้น

นั่นไม่ใช่ฐานข้อมูลขนาดใหญ่ใช่ไหม

สำหรับ TLD บางตัวเช่น .com ใช่ แต่:

  • เพียงไม่กี่ร้อยล้านเรกคอร์ด ซึ่งเป็นสิ่งที่ฐานข้อมูลสามารถจัดการได้อย่างสมบูรณ์ แต่เป็นกรณีอื่นๆ ที่มีข้อมูลมากกว่านั้นมาก
  • TLD แบบนั้นเป็นข้อยกเว้น TLD ส่วนใหญ่มีขนาดเล็กกว่ามาก ตัวอย่างเช่น ccTLD ทั่วไปคือโดเมนสองสามล้านโดเมน

หรือมีอัลกอริทึมบางประเภทที่ตัดสินใจว่าชื่อโดเมนใดถูกกำหนดให้กับเนมเซิร์ฟเวอร์ที่มีสิทธิ์ และทำให้ชื่อโดเมนนั้นทำงานผ่านอัลกอริทึม คุณจะสามารถระบุเนมเซิร์ฟเวอร์ที่ถูกต้องได้

ไม่ไม่มี เมื่อคุณจดทะเบียนชื่อโดเมน (ที่จริงทุกระดับในแผนผัง DNS) คุณมีอิสระที่จะเลือกเนมเซิร์ฟเวอร์ใดก็ได้ที่คุณต้องการให้จัดการ (ยกเว้นบางกรณีขอบที่เฉพาะเจาะจงมาก เช่น .tel ในอดีตที่ Registry บังคับให้ระบุเนมเซิร์ฟเวอร์)

ขออภัย ดูเหมือนเป็นคำถามง่ายๆ แต่ฉันไม่พบสิ่งใดทางออนไลน์

https://en.wikipedia.org/wiki/Domain_name_registry สั้น ๆ แต่สามารถเป็นการแนะนำที่ดี ทันทีที่คุณเข้าใจว่ามีการแก้ปัญหาด้านหนึ่ง (DNS) และการลงทะเบียนอีกด้านหนึ่ง (เกี่ยวกับรีจิสทรี/ผู้รับจดทะเบียนทั้งหมด) จะช่วยให้คุณเข้าใจสิ่งต่างๆ ได้ดีขึ้น

Score:1
ธง in

พวกเขาต้องมีบันทึกการมอบหมาย (NS) และกาว (A/AAAA) ทั้งหมดสำหรับโซนของพวกเขา ขุด com NS เผยให้เห็นว่ามีเนมเซิร์ฟเวอร์มากพอๆ กับที่มีรูทเซิร์ฟเวอร์:

;; ส่วนคำตอบ:
คอม 63343 ใน NS i.gtld-servers.net
คอม 63343 ใน NS l.gtld-servers.net
คอม 63343 ใน NS f.gtld-servers.net
คอม 63343 ใน NS b.gtld-servers.net
คอม 63343 ใน NS k.gtld-servers.net
คอม 63343 ใน NS h.gtld-servers.net
คอม 63343 ใน NS j.gtld-servers.net
คอม 63343 ใน NS c.gtld-servers.net
คอม 63343 ใน NS d.gtld-servers.net
คอม 63343 ใน NS g.gtld-servers.net
คอม 63343 ใน NS เช่น gtld-servers.net
คอม 63343 ใน NS a.gtld-servers.net
คอม 63343 ใน NS m.gtld-servers.net

ดังนั้นคุณจึงสามารถสอบถามสิ่งเหล่านี้ได้ดังนี้: ขุด google.com @a.gtld-servers.net. และพวกเขาจะบอกคุณถึงเนมเซิร์ฟเวอร์ที่เชื่อถือได้สำหรับโดเมนที่ร้องขอ:

;; ส่วนผู้มีอำนาจ:
กูเกิล.คอม. 172800 ใน NS ns2.google.com
กูเกิล.คอม. 172800 ใน NS ns1.google.com
กูเกิล.คอม. 172800 ใน NS ns3.google.com
กูเกิล.คอม. 172800 ใน NS ns4.google.com

;; ส่วนเพิ่มเติม:
ns2.google.com. 172800 ใน AAAA 2001:4860:4802:34::ก
ns2.google.com. 172800 ใน 216.239.34.10
ns1.google.com. 172800 ใน AAAA 2001:4860:4802:32::ก
ns1.google.com. 172800 ใน 216.239.32.10
ns3.google.com 172800 ใน AAAA 2001:4860:4802:36::ก
ns3.google.com 172800 ใน 216.239.36.10
ns4.google.com. 172800 ใน AAAA 2001:4860:4802:38::ก
ns4.google.com. 172800 ใน 216.239.38.10
Score:1
ธง cn

เซิร์ฟเวอร์ชื่อ TLD สำหรับ ".com" เก็บเซิร์ฟเวอร์ชื่อที่เกี่ยวข้องหรือไม่ สำหรับทุก ๆ เว็บไซต์ที่มี ".com" TLD?

ใช่. มีเซิร์ฟเวอร์จำนวนมากที่อยู่เบื้องหลัง IP ของบริการหลายตัว ซึ่งเซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งสามารถให้บริการการสืบค้นได้ ขุด -t NS คอม เพื่อรับรายชื่อ

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

โซนประกอบด้วยเซิร์ฟเวอร์ DNS ที่มีสิทธิ์สำหรับชื่อที่กำหนด ผู้ที่ติดตามบล็อกโครงสร้างพื้นฐานของ Stack Exchange อาจจำได้ว่าพวกเขากำลังป้องกันความเสี่ยงในการเดิมพันกับผู้ให้บริการ DNS และยังคงมีอยู่:

ns1.serverfault.com. 172800 ใน 198.252.206.80
ns3.serverfault.com 172800 ใน 69.59.197.60
serverfault.com 172800 ใน ns ns-1135.awsdns-13.org
serverfault.com 172800 ใน ns ns-860.awsdns-43.net
serverfault.com 172800 ใน ns ns-cloud-c1.googledomains.com
serverfault.com 172800 ใน ns ns-cloud-c2.googledomains.com
stackoverflowdevinsights.com 172800 ใน ns ns1.serverfault.com
stackoverflowdevinsights.com 172800 ใน ns ns3.serverfault.com

ดูเพิ่มเติมที่ Super User: มีวิธีรับไฟล์โซนที่สมบูรณ์สำหรับโดเมนโดยไม่ต้องติดต่อโฮสต์หรือไม่

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา