ระบบชื่อโดเมน

จากวิกิพีเดีย สารานุกรมเสรี
ข้ามไปที่การนำทาง ข้ามไปที่การค้นหา

ระบบชื่อโดเมน ( DNS ) คือระบบการตั้งชื่อแบบมีลำดับชั้นและกระจายอำนาจใช้เพื่อระบุคอมพิวเตอร์ที่เข้าถึงได้ผ่านทางอินเทอร์เน็ตหรือ เครือข่าย อินเทอร์เน็ตโปรโตคอล (IP) อื่นๆ ระเบียนทรัพยากรที่อยู่ใน DNS จะเชื่อมโยงชื่อโดเมนกับข้อมูลรูปแบบอื่นๆ สิ่งเหล่านี้มักใช้เพื่อจับคู่ชื่อโดเมนที่เป็นมิตรกับมนุษย์กับที่อยู่ IP ที่ เป็นตัวเลข คอมพิวเตอร์จำเป็นต้องค้นหาบริการและอุปกรณ์โดยใช้โปรโตคอลเครือข่าย พื้นฐานแต่ได้ขยายเวลาออกไปเพื่อทำหน้าที่อื่นๆ อีกมากมายเช่นกัน ระบบชื่อโดเมนเป็นองค์ประกอบสำคัญของการทำงานของอินเทอร์เน็ตมาตั้งแต่ปี 1985

ฟังก์ชัน

การเปรียบเทียบที่ใช้บ่อยในการอธิบายระบบชื่อโดเมนคือมันทำหน้าที่เป็นสมุดโทรศัพท์สำหรับอินเทอร์เน็ตโดยการแปลชื่อโฮสต์ คอมพิวเตอร์ที่เป็นมิตรต่อมนุษย์ เป็นที่อยู่ IP ตัวอย่างเช่น ชื่อโดเมนwww.example.comแปลเป็นที่อยู่93.184.216.34 ( IPv4 ) และ2606:2800:220:1:248:1893:25c8:1946 ( IPv6 ) DNS สามารถอัปเดตได้อย่างรวดเร็วและโปร่งใส ทำให้ตำแหน่งของบริการบนเครือข่ายเปลี่ยนแปลงได้โดยไม่กระทบต่อผู้ใช้ปลายทาง ซึ่งยังคงใช้ชื่อโฮสต์เดิมต่อไป ผู้ใช้ใช้ประโยชน์จากสิ่งนี้เมื่อพวกเขาใช้ Uniform Resource Locators ( URL ) และที่อยู่อีเมลที่ มีความหมายโดยไม่ต้องรู้ว่าคอมพิวเตอร์หาตำแหน่งบริการได้อย่างไร

ฟังก์ชันที่สำคัญและแพร่หลายของ DNS คือบทบาทหลักในบริการอินเทอร์เน็ตแบบกระจาย เช่นบริการคลาวด์และ เครือข่ายการจัดส่งเนื้อหา [1]เมื่อผู้ใช้เข้าถึงบริการอินเทอร์เน็ตแบบกระจายโดยใช้ URL ชื่อโดเมนของ URL จะถูกแปลเป็นที่อยู่ IP ของเซิร์ฟเวอร์ที่ใกล้เคียงกับผู้ใช้ ฟังก์ชันหลักของ DNS ที่ใช้ประโยชน์ที่นี่คือผู้ใช้ที่แตกต่างกันสามารถรับการแปลที่แตกต่างกันได้ พร้อม กันชื่อโดเมน จุดสำคัญของความแตกต่างจากมุมมองสมุดโทรศัพท์แบบดั้งเดิมของ DNS ขั้นตอนการใช้ DNS เพื่อกำหนดเซิร์ฟเวอร์ใกล้เคียงให้กับผู้ใช้เป็นกุญแจสำคัญในการให้การตอบสนองที่รวดเร็วและเชื่อถือได้มากขึ้นบนอินเทอร์เน็ต และมีการใช้กันอย่างแพร่หลายในบริการอินเทอร์เน็ตหลักๆ ส่วนใหญ่ [2]

DNS สะท้อนถึงโครงสร้างความรับผิดชอบของผู้ดูแลระบบในอินเทอร์เน็ต [3]แต่ละโดเมนย่อยเป็นโซนของความเป็นอิสระในการบริหารที่มอบหมายให้ผู้จัดการ สำหรับโซนที่ดำเนินการ โดยสำนัก ทะเบียนข้อมูลการดูแลระบบมักจะเสริมด้วยบริการRDAP และ WHOIS ของ รีจิสทรี ข้อมูลดังกล่าวสามารถใช้เพื่อรับข้อมูลเชิงลึก และติดตามความรับผิดชอบสำหรับโฮสต์ที่ระบุบนอินเทอร์เน็ต [4]

ประวัติ

การใช้ชื่อที่ง่ายกว่าและน่าจดจำกว่าแทนที่อยู่ที่เป็นตัวเลขของโฮสต์นั้นมีอายุย้อนไปถึงยุคARPANET สถาบันวิจัยสแตนฟอร์ด (ปัจจุบันคือSRI International ) ได้ดูแลไฟล์ข้อความชื่อHOSTS.TXTซึ่งจับคู่ชื่อโฮสต์กับที่อยู่ที่เป็นตัวเลขของคอมพิวเตอร์บน ARPANET [5] [6] Elizabeth Feinlerพัฒนาและดูแลไดเรกทอรี ARPANET แรก [7] [8]การบำรุงรักษาที่อยู่ที่เป็นตัวเลข เรียกว่า Assigned Numbers List ซึ่งดูแลโดยJon Postelที่สถาบัน Information Sciences Institute (ISI) ของมหาวิทยาลัยเซาเทิร์ แคลิฟอร์เนีย [9]

ที่อยู่ถูกกำหนดด้วยตนเอง คอมพิวเตอร์ รวมถึงชื่อโฮสต์และที่อยู่ ถูกเพิ่มลงในไฟล์หลักโดยติดต่อ SRI Network Information Center (NIC) ซึ่งกำกับโดย Feinler โทรศัพท์ในช่วงเวลาทำการ [10]ต่อมา Feinler ได้ตั้งค่า ไดเร็กทอรี WHOISบนเซิร์ฟเวอร์ใน NIC เพื่อดึงข้อมูลเกี่ยวกับทรัพยากร ผู้ติดต่อ และเอนทิตี [11]เธอและทีมของเธอได้พัฒนาแนวคิดเรื่องโดเมน [11] Feinler แนะนำว่าโดเมนควรยึดตามตำแหน่งของที่อยู่จริงของคอมพิวเตอร์ [12]คอมพิวเตอร์ในสถาบันการศึกษาจะมีโดเมนeduเช่น [13]เธอและทีมงานจัดการ Host Naming Registry ตั้งแต่ปี 1972 ถึง 1989 [14]

ในช่วงต้นทศวรรษ 1980 การรักษาตารางโฮสต์แบบรวมศูนย์เพียงโต๊ะเดียวได้ช้าและเทอะทะ และเครือข่ายที่เกิดขึ้นใหม่จำเป็นต้องมีระบบการตั้งชื่ออัตโนมัติเพื่อแก้ไขปัญหาด้านเทคนิคและบุคลากร Postel กำกับดูแลงานของการประนีประนอมระหว่างข้อเสนอห้าข้อที่แข่งขันกันเพื่อแก้ปัญหาให้กับPaul Mockapetris Mockapetris ได้สร้างระบบชื่อโดเมนขึ้นในปี 1983 ในขณะที่อยู่ที่มหาวิทยาลัยเซาเทิร์นแคลิฟอร์เนีย [10] [15]

Internet Engineering Task Force ได้เผยแพร่ ข้อกำหนดดั้งเดิมใน RFC 882 และ RFC 883 ในเดือนพฤศจิกายน 1983 [16] [17]สิ่งเหล่านี้ได้รับการปรับปรุงใน RFC 973 ในเดือนมกราคม 1986

ในปี 1984 นักเรียน UC Berkeleyสี่คน ได้แก่ Douglas Terry, Mark Painter, David Riggle และ Songnian Zhou ได้เขียน เนมเซิร์ฟเวอร์ Unix ตัวแรก สำหรับ Berkeley Internet Name Domain หรือที่เรียกกันทั่วไปว่าBIND [18]ในปี 1985 Kevin Dunlap แห่งDECได้ปรับปรุงการใช้งาน DNS อย่างมาก Mike Karels , Phil Almquist และPaul Vixieจากนั้นจึงเข้าควบคุมดูแล BIND Internet Systems Consortium ก่อตั้งขึ้นในปี 1994 โดย Rick Adams, Paul Vixie และ Carl Malamud โดยชัดแจ้งเพื่อจัดหาบ้านสำหรับการพัฒนาและบำรุงรักษา BIND เวอร์ชัน BIND ตั้งแต่ 4.9.3 เป็นต้นไปได้รับการพัฒนาและดูแลโดย ISC โดยได้รับการสนับสนุนจากผู้สนับสนุนของ ISC ในฐานะสถาปนิกร่วม/โปรแกรมเมอร์ Bob Halley และ Paul Vixie ได้เปิดตัว BIND เวอร์ชัน 8 เวอร์ชันที่พร้อมสำหรับการผลิตเป็นครั้งแรกในเดือนพฤษภาคม 1997 ตั้งแต่ปี 2000 นักพัฒนาหลักมากกว่า 43 รายต่างทำงานบน BIND (19)

ในเดือนพฤศจิกายน พ.ศ. 2530 RFC 1034 [20]และ RFC 1035 [3]ได้เข้ามาแทนที่ข้อกำหนด DNS ในปี 1983 คำขอความคิดเห็นเพิ่มเติมหลาย รายการ ได้เสนอให้ขยายโปรโตคอล DNS หลัก (21)

โครงสร้าง

พื้นที่ชื่อโดเมน

พื้นที่ชื่อโดเมนประกอบด้วยโครงสร้างข้อมูลแบบต้นไม้ แต่ละโหนดหรือลีฟในทรีมีป้ายชื่อ และ บันทึกทรัพยากร (RR) เป็นศูนย์หรือมากกว่าซึ่งเก็บข้อมูลที่เกี่ยวข้องกับชื่อโดเมน ชื่อโดเมนประกอบด้วยป้ายกำกับ ต่อกับชื่อของโหนดหลักทางด้านขวา คั่นด้วยจุด [22]

ต้นไม้แบ่งย่อยออกเป็นโซนเริ่มต้นที่โซนราก โซน DNS อาจประกอบด้วย โดเมนเดียวเท่านั้น หรืออาจประกอบด้วยหลายโดเมนและโดเมนย่อย ขึ้นอยู่กับตัวเลือกการดูแลระบบของตัวจัดการโซน DNS ยังสามารถแบ่งพาร์ติชั่นตาม คลาสที่ คลาสที่แยกจากกันสามารถถูกมองว่าเป็นอาร์เรย์ของทรีเนมสเปซคู่ขนาน [23]

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

ความรับผิดชอบในการบริหารสำหรับโซนใด ๆ อาจแบ่งได้โดยการสร้างโซนเพิ่มเติม กล่าวกันว่าผู้มีอำนาจเหนือโซนใหม่จะมอบหมายให้เซิร์ฟเวอร์ชื่อที่กำหนด โซนหลักสิ้นสุดที่จะมีสิทธิ์สำหรับโซนใหม่ [23]

ไวยากรณ์ชื่อโดเมน การทำให้เป็นสากล

คำอธิบายที่ชัดเจนของกฎสำหรับการสร้างชื่อโดเมนปรากฏใน RFC 1035, RFC 1123, RFC 2181 และ RFC 5892 ชื่อโดเมนประกอบด้วยส่วนประกอบหนึ่งส่วนขึ้นไป ซึ่งในทางเทคนิคเรียกว่าlabelซึ่งต่อกันตามอัตภาพและคั่นด้วยจุด เช่น เช่น example.com

ป้ายกำกับด้านขวาสุดแสดงถึงโดเมนระดับบนสุด ตัวอย่างเช่น ชื่อโดเมน www.example.com เป็นของโดเมนระดับบนสุด com

ลำดับชั้นของโดเมนจากขวาไปซ้าย แต่ละป้ายทางด้านซ้ายระบุส่วนย่อยหรือโดเมนย่อยของโดเมนทางด้านขวา ตัวอย่างเช่น ตัวอย่างป้ายกำกับระบุโดเมนย่อยของ โดเมน comและwwwเป็นโดเมนย่อยของ example.com ผังย่อยนี้อาจมีมากถึง 127 ระดับ [24]

ป้ายกำกับอาจมีอักขระตั้งแต่ศูนย์ถึง 63 ตัว เลเบล null ที่มีความยาวศูนย์ สงวนไว้สำหรับโซนรูท ชื่อโดเมนแบบเต็มต้องมีความยาวไม่เกิน 253 อักขระในการแสดงข้อความ [20]ในการแทนค่าไบนารีภายในของ DNS ความยาวสูงสุดต้องใช้ที่เก็บข้อมูล 255 octets เนื่องจากจะเก็บความยาวของชื่อไว้ด้วย [3]

แม้ว่าจะไม่มีข้อจำกัดทางเทคนิคในการป้องกันป้ายชื่อโดเมนโดยใช้อักขระใดๆ ที่อ็อกเท็ตแสดง ชื่อโฮสต์ก็ใช้รูปแบบและชุดอักขระที่ต้องการ อักขระที่อนุญาตในป้ายกำกับคือชุดย่อยของชุดอักขระ ASCIIซึ่งประกอบด้วยอักขระaถึงz , AถึงZ , ตัวเลข0ถึง9และยัติภังค์ กฎนี้เรียกว่ากฎ LDH (ตัวอักษร ตัวเลข ยัติภังค์) ชื่อโดเมนจะถูกตีความในลักษณะที่ไม่ขึ้นกับตัวพิมพ์ใหญ่-เล็ก [25]ป้ายกำกับต้องไม่ขึ้นต้นหรือลงท้ายด้วยยัติภังค์ [26]กฎเพิ่มเติมกำหนดให้ชื่อโดเมนระดับบนสุดไม่ควรเป็นตัวเลขทั้งหมด(26)

ชุดอักขระ ASCII ที่จำกัดที่อนุญาตใน DNS ทำให้ไม่สามารถแสดงชื่อและคำในหลายภาษาในตัวอักษรหรือสคริปต์ดั้งเดิมได้ เพื่อให้เป็นไปได้ICANNได้อนุมัติระบบInternationalizing Domain Names in Applications (IDNA) โดยที่แอปพลิเคชันของผู้ใช้ เช่น เว็บเบราว์เซอร์ จะจับคู่ สตริง Unicodeลงในชุดอักขระ DNS ที่ถูกต้องโดยใช้Punycode ในปี 2552 ICANN อนุมัติการติดตั้งชื่อโดเมนสากลรหัสประเทศ โดเมนระดับบนสุด ( ccTLD s ) นอกจากนี้ การลงทะเบียน จำนวนมาก ของชื่อโดเมนระดับบนสุดที่มีอยู่ ( TLD s) ได้นำระบบ IDNA มาใช้ตามแนวทาง RFC 5890, RFC 5891, RFC 5892, RFC 5893

เนมเซิร์ฟเวอร์

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

เนมเซิร์ฟเวอร์ที่เชื่อถือได้

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

เนมเซิร์ฟเวอร์ที่เชื่อถือได้อาจเป็น เซิร์ฟเวอร์ หลักหรือ เซิร์ฟเวอร์ รองก็ได้ ในอดีต คำว่าmaster/slaveและprimary/secondaryบางครั้งใช้แทนกันได้[27]แต่แนวทางปฏิบัติในปัจจุบันคือการใช้รูปแบบหลัง เซิร์ฟเวอร์หลักคือเซิร์ฟเวอร์ที่เก็บสำเนาต้นฉบับของระเบียนโซนทั้งหมด เซิร์ฟเวอร์สำรองใช้กลไกการอัปเดตอัตโนมัติ แบบพิเศษ ในโปรโตคอล DNS ในการสื่อสารกับเซิร์ฟเวอร์หลัก เพื่อรักษาสำเนาที่เหมือนกันของเรคคอร์ดหลัก

ทุกโซน DNS จะต้องกำหนดชุดของเนมเซิร์ฟเวอร์ที่เชื่อถือได้ ชุดเซิร์ฟเวอร์นี้จัดเก็บไว้ในโซนโดเมนหลักที่มีระเบียนเซิร์ฟเวอร์ชื่อ (NS)

เซิร์ฟเวอร์ที่เชื่อถือได้ระบุสถานะของการให้คำตอบที่ชัดเจน ซึ่งถือว่าเชื่อถือได้ โดยการตั้งค่าสถานะโปรโตคอลที่เรียกว่าบิต " คำตอบที่เชื่อถือได้ " ( AA ) ในการตอบกลับ [3]แฟล็กนี้มักจะทำซ้ำอย่างเด่นชัดในผลลัพธ์ของเครื่องมือสืบค้นการดูแล DNS เช่นdigเพื่อระบุว่าเซิร์ฟเวอร์ชื่อที่ตอบสนองคือสิทธิ์สำหรับชื่อโดเมนที่เป็นปัญหา [3]

เมื่อเนมเซิร์ฟเวอร์ถูกกำหนดให้เป็นเซิร์ฟเวอร์ที่เชื่อถือได้สำหรับชื่อโดเมนที่ไม่มีข้อมูลที่เชื่อถือได้ จะแสดงประเภทของข้อผิดพลาดที่เรียกว่า "การมอบหมายที่อ่อนแอ" หรือ "การตอบสนองที่อ่อนแอ" [28] [29]

การดำเนินการ

กลไกการแก้ไขที่อยู่

ตัวแก้ไขชื่อโดเมนจะกำหนดเนมเซิร์ฟเวอร์ของโดเมนที่รับผิดชอบชื่อโดเมนที่เป็นปัญหาโดยลำดับของการค้นหาที่เริ่มต้นด้วยป้ายกำกับโดเมนด้านขวาสุด (ระดับบนสุด)

ตัวแก้ไข DNS ที่ใช้วิธีการวนซ้ำที่กำหนดโดย RFC 1034; ในกรณีนี้ ตัวแก้ไขจะปรึกษาเนมเซิร์ฟเวอร์สามแห่งเพื่อแก้ไขชื่อโดเมนแบบเต็ม "www.wikipedia.org"

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

สมมติว่าตัวแก้ไขไม่มีเร็กคอร์ดที่แคชไว้เพื่อเร่งกระบวนการ กระบวนการแก้ไขจะเริ่มต้นด้วยการสอบถามไปยังเซิร์ฟเวอร์รากตัวใดตัวหนึ่ง ในการดำเนินการทั่วไป รูทเซิร์ฟเวอร์จะไม่ตอบโดยตรง แต่ตอบกลับด้วยการอ้างอิงไปยังเซิร์ฟเวอร์ที่เชื่อถือได้มากกว่า เช่น แบบสอบถามสำหรับ "www.wikipedia.org" จะอ้างอิงถึงเซิร์ฟเวอร์ ของ องค์กร ตอนนี้ตัวแก้ไขจะสอบถามเซิร์ฟเวอร์ที่อ้างถึง และทำซ้ำขั้นตอนนี้จนกว่าจะได้รับคำตอบที่เชื่อถือได้ แผนภาพแสดงกระบวนการนี้สำหรับโฮสต์ที่ตั้งชื่อตามชื่อโดเมนแบบเต็ม "www.wikipedia.org"

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

เนมเซิร์ฟเวอร์แบบเรียกซ้ำและแคช

ตามทฤษฎีแล้ว เนมเซิร์ฟเวอร์ที่เชื่อถือได้นั้นเพียงพอสำหรับการทำงานของอินเทอร์เน็ต อย่างไรก็ตาม ด้วยการใช้งานเนมเซิร์ฟเวอร์ที่เชื่อถือได้เท่านั้น ทุกการสืบค้น DNS จะต้องเริ่มต้นด้วยการสืบค้นแบบเรียกซ้ำที่โซนรากของ Domain Name System และระบบผู้ใช้แต่ละระบบจะต้องใช้ซอฟต์แวร์ตัวแก้ไขที่สามารถดำเนินการแบบเรียกซ้ำได้ [30]

เพื่อปรับปรุงประสิทธิภาพ ลดทราฟฟิก DNS บนอินเทอร์เน็ต และเพิ่มประสิทธิภาพในแอปพลิเคชันของผู้ใช้ปลายทาง ระบบชื่อโดเมนรองรับเซิร์ฟเวอร์แคช DNS ซึ่งเก็บผลลัพธ์การสืบค้น DNS เป็นระยะเวลาที่กำหนดในการกำหนดค่า ( time-to-live ) ของ บันทึกชื่อโดเมนที่เป็นปัญหา โดยทั่วไปแล้ว เซิร์ฟเวอร์แคช DNS ดังกล่าวจะใช้อัลกอริธึมแบบเรียกซ้ำซึ่งจำเป็นในการแก้ไขชื่อที่กำหนดโดยเริ่มจากรูท DNS ไปจนถึงเนมเซิร์ฟเวอร์ที่เชื่อถือได้ของโดเมนที่สืบค้น ด้วยฟังก์ชันนี้ที่ใช้งานในเนมเซิร์ฟเวอร์ แอปพลิเคชันของผู้ใช้จะเพิ่มประสิทธิภาพในการออกแบบและการทำงาน

การรวมการแคช DNS และฟังก์ชันแบบเรียกซ้ำในเนมเซิร์ฟเวอร์นั้นไม่จำเป็น ฟังก์ชันต่างๆ สามารถนำไปใช้อย่างอิสระในเซิร์ฟเวอร์เพื่อวัตถุประสงค์พิเศษ

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

ตัวแก้ไข DNS

ฝั่งไคลเอ็นต์ของ DNS เรียกว่าตัวแก้ไข DNS รีโซลเวอร์มีหน้าที่รับผิดชอบในการเริ่มต้นและจัดลำดับการสืบค้นที่นำไปสู่การแก้ปัญหาที่สมบูรณ์ (การแปล) ของทรัพยากรที่ต้องการในท้ายที่สุด เช่น การแปลชื่อโดเมนเป็นที่อยู่ IP ตัวแก้ไข DNS ถูกจำแนกตามวิธีการสืบค้นที่หลากหลาย เช่นrecursive , non -recursiveและiterative กระบวนการแก้ไขอาจใช้วิธีการเหล่านี้ร่วมกัน (20)

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

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

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

การพึ่งพาแบบวงกลมและบันทึกกาว

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

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

ตัวอย่างเช่น หากเนมเซิร์ฟเวอร์ ที่เชื่อถือ ได้ของ example.org คือ ns1.example.org คอมพิวเตอร์ที่พยายามแก้ไข www.example.org จะแก้ไข ns1.example.org ก่อน เนื่องจาก ns1 มีอยู่ใน example.org จึงต้องแก้ไข example.org ก่อน ซึ่งจะแสดงการพึ่งพาแบบวงกลม ในการทำลายการพึ่งพา เนมเซิร์ฟเวอร์สำหรับ องค์กร โดเมนระดับบนสุดจะรวมกาวพร้อมกับการมอบหมายสำหรับ example.org บันทึกกาวคือบันทึกที่อยู่ซึ่งระบุที่อยู่ IP สำหรับ ns1.example.org ตัวแก้ไขใช้ที่อยู่ IP เหล่านี้อย่างน้อยหนึ่งรายการเพื่อสอบถามเซิร์ฟเวอร์ที่เชื่อถือได้ตัวใดตัวหนึ่งของโดเมน ซึ่งช่วยให้สามารถสืบค้น DNS ได้

บันทึกแคช

แนวทางปฏิบัติมาตรฐานในการใช้การจำแนกชื่อในแอปพลิเคชันคือการลดภาระงานบนเซิร์ฟเวอร์ระบบชื่อโดเมนโดยการแคชผลลัพธ์ในเครื่องหรือในโฮสต์ตัวแก้ไขระดับกลาง ผลลัพธ์ที่ได้รับจากคำขอ DNS จะเชื่อมโยงกับtime to live (TTL) เสมอ ซึ่งเป็นเวลาหมดอายุหลังจากนั้นจะต้องละทิ้งหรือรีเฟรชผลลัพธ์ TTL ถูกกำหนดโดยผู้ดูแลระบบของเซิร์ฟเวอร์ DNS ที่เชื่อถือได้ ระยะเวลาที่ใช้ได้อาจแตกต่างกันตั้งแต่ไม่กี่วินาทีจนถึงวันหรือสัปดาห์ [31]

อันเป็นผลมาจากสถาปัตยกรรมแคชแบบกระจายนี้ การเปลี่ยนแปลงในระเบียน DNS จะไม่เผยแพร่ทั่วทั้งเครือข่ายในทันที แต่ต้องการให้แคชทั้งหมดหมดอายุและต้องรีเฟรชหลังจาก TTL RFC 1912 นำเสนอกฎพื้นฐานสำหรับการกำหนดค่า TTL ที่เหมาะสม

ตัวแก้ไขบางตัวอาจแทนที่ค่า TTL เนื่องจากโปรโตคอลรองรับการแคชนานถึงหกสิบแปดปีหรือไม่มีการแคชเลย การ แคชเชิงลบกล่าวคือ การแคชในความเป็นจริงของการไม่มีบันทึกนั้น ถูกกำหนดโดยเซิร์ฟเวอร์ชื่อที่มีสิทธิ์สำหรับโซนที่ต้องมี เรก คอร์ด Start of Authority (SOA) เมื่อรายงานว่าไม่มีข้อมูลของประเภทที่ร้องขอ ค่าของ ฟิลด์ ต่ำสุดของบันทึก SOA และ TTL ของ SOA นั้นใช้เพื่อสร้าง TTL สำหรับคำตอบเชิงลบ

การค้นหาแบบย้อนกลับ

การค้นหา DNS แบบย้อนกลับเป็นการสอบถาม DNS สำหรับชื่อโดเมนเมื่อทราบที่อยู่ IP ชื่อโดเมนหลายชื่ออาจเชื่อมโยงกับที่อยู่ IP DNS เก็บที่อยู่ IP ในรูปแบบของชื่อโดเมนเป็นชื่อที่มีรูปแบบพิเศษในระเบียนตัวชี้ (PTR) ภายในโครงสร้างพื้นฐานโดเมนระดับบนสุดarpa สำหรับ IPv4 โดเมนคือ in-addr.arpa สำหรับ IPv6 โดเมนการค้นหาแบบย้อนกลับคือ ip6.arpa ที่อยู่ IP จะแสดงเป็นชื่อในรูปแบบออคเต็ตที่เรียงลำดับแบบย้อนกลับสำหรับ IPv4 และการแสดงแบบแท๊บแบบเรียงลำดับแบบย้อนกลับสำหรับ IPv6

เมื่อทำการค้นหาแบบย้อนกลับ ไคลเอ็นต์ DNS จะแปลงที่อยู่เป็นรูปแบบเหล่านี้ก่อนที่จะสอบถามชื่อสำหรับระเบียน PTR ตามสายการมอบหมายสำหรับการสืบค้น DNS ตัวอย่างเช่น สมมติว่าที่อยู่ IPv4 208.80.152.2 ถูกกำหนดให้กับ Wikimedia มันจะแสดงเป็นชื่อ DNS ในลำดับที่กลับกัน: 2.152.80.208.in-addr.arpa เมื่อตัวแก้ไข DNS ได้รับคำขอตัวชี้ (PTR) คำขอจะเริ่มต้นด้วยการสืบค้นเซิร์ฟเวอร์ราก ซึ่งชี้ไปที่เซิร์ฟเวอร์ของAmerican Registry for Internet Numbers (ARIN) สำหรับโซน 208.in-addr.arpa เซิร์ฟเวอร์ของ ARIN มอบหมาย 152.80.208.in-addr.arpa ไปยัง Wikimedia ซึ่งตัวแก้ไขจะส่งข้อความค้นหาอื่นสำหรับ 2.152.80.208.in-addr.arpa ซึ่งส่งผลให้มีการตอบกลับที่เชื่อถือได้

ค้นหาลูกค้า

ลำดับความละเอียด DNS

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

ตัวแก้ไข DNS เกือบจะมีแคช (ดูด้านบน) ที่มีการค้นหาล่าสุดอย่างสม่ำเสมอ หากแคชสามารถให้คำตอบสำหรับคำขอได้ ตัวแก้ไขจะคืนค่าในแคชไปยังโปรแกรมที่ส่งคำขอ หากแคชไม่มีคำตอบ ตัวแก้ไขจะส่งคำขอไปยังเซิร์ฟเวอร์ DNS ที่กำหนดตั้งแต่หนึ่งตัวขึ้นไป ในกรณีของผู้ใช้ตามบ้านส่วนใหญ่ ผู้ให้บริการอินเทอร์เน็ตที่เครื่องเชื่อมต่อมักจะจัดหาเซิร์ฟเวอร์ DNS นี้: ผู้ใช้ดังกล่าวจะกำหนดค่าที่อยู่ของเซิร์ฟเวอร์นั้นด้วยตนเองหรืออนุญาตDHCPเพื่อตั้งค่า; อย่างไรก็ตาม ที่ซึ่งผู้ดูแลระบบได้กำหนดค่าระบบเพื่อใช้เซิร์ฟเวอร์ DNS ของตนเอง ตัวแก้ไข DNS จะชี้ไปที่เนมเซิร์ฟเวอร์ที่ดูแลแยกต่างหากขององค์กร ไม่ว่าในกรณีใด เนมเซิร์ฟเวอร์ที่สอบถามจะปฏิบัติตามกระบวนการที่ระบุไว้ข้างต้นจนกว่าจะพบผลลัพธ์สำเร็จหรือไม่สำเร็จ จากนั้นจะส่งคืนผลลัพธ์ไปยังตัวแก้ไข DNS สมมติว่าพบผลลัพธ์แล้ว ตัวแก้ไขจะแคชอย่างถูกต้องซึ่งส่งผลให้เกิดการใช้งานในอนาคต และส่งผลลัพธ์กลับไปยังซอฟต์แวร์ที่เริ่มต้นคำขอ

ตัว แก้ไขที่ใช้งานไม่ได้

ISP ขนาดใหญ่บางรายได้กำหนดค่าเซิร์ฟเวอร์ DNS ของตนให้ละเมิดกฎ เช่น โดยไม่เชื่อฟัง TTL หรือโดยการระบุว่าชื่อโดเมนไม่มีอยู่เพียงเพราะหนึ่งในเซิร์ฟเวอร์ชื่อไม่ตอบสนอง (32)

แอปพลิเคชั่นบางตัว เช่น เว็บเบราว์เซอร์จะรักษาแคช DNS ภายในเพื่อหลีกเลี่ยงการค้นหาซ้ำๆ ผ่านเครือข่าย แนวทางปฏิบัตินี้อาจเพิ่มความยากเป็นพิเศษเมื่อทำการดีบักปัญหา DNS เนื่องจากปิดบังประวัติของข้อมูลดังกล่าว แคชเหล่านี้มักใช้เวลาแคชสั้นมากในลำดับหนึ่งนาที [33]

Internet Explorerแสดงถึงข้อยกเว้นที่โดดเด่น: เวอร์ชันสูงถึง IE 3.x cache DNS บันทึกเป็นเวลา 24 ชั่วโมงโดยค่าเริ่มต้น Internet Explorer 4.x และรุ่นที่ใหม่กว่า (สูงสุด IE 8) จะลดค่าระยะหมดเวลาเริ่มต้นลงเหลือครึ่งชั่วโมง ซึ่งอาจเปลี่ยนแปลงได้โดยการปรับเปลี่ยนการกำหนดค่าเริ่มต้น [34]

เมื่อGoogle Chromeตรวจพบปัญหากับเซิร์ฟเวอร์ DNS จะแสดงข้อความแสดงข้อผิดพลาดเฉพาะ

แอปพลิเคชันอื่นๆ

ระบบชื่อโดเมนมีฟังก์ชันและคุณสมบัติอื่นๆ อีกหลายอย่าง

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

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

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

ตัวอย่างเช่น:

  • ที่อยู่ 102.3.4.5 ถูกขึ้นบัญชีดำ มันชี้ไปที่ 5.4.3.102.blacklist.example ซึ่งแก้ไขเป็น 127.0.0.1
  • ที่อยู่ 102.3.4.6 ไม่อยู่ในบัญชีดำและชี้ไปที่ 6.4.3.102.blacklist.example ชื่อโฮสต์นี้ไม่ได้รับการกำหนดค่าหรือแก้ไขเป็น 127.0.0.2

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

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

DNS แบบไดนามิก (DDNS) จะอัปเดตเซิร์ฟเวอร์ DNS ด้วยที่อยู่ IP ของไคลเอ็นต์ทันที เช่น เมื่อย้ายระหว่าง ISP หรือฮอตสปอตมือถือ หรือเมื่อที่อยู่ IP มีการเปลี่ยนแปลงในการดูแลระบบ

รูปแบบข้อความ DNS

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

ส่วนหัวประกอบด้วยฟิลด์ต่อไปนี้: การระบุ , แฟล็ก , จำนวนคำถาม , จำนวนคำตอบ , จำนวนเร็กคอร์ดทรัพยากรของผู้มีอำนาจ (RR) และจำนวน RRเพิ่มเติม แต่ละฟิลด์มีความยาว 16 บิต และปรากฏในลำดับที่กำหนด ฟิลด์การระบุใช้เพื่อจับคู่คำตอบกับแบบสอบถาม ฟิลด์แฟล็กประกอบด้วยฟิลด์ย่อยดังนี้:

รูปแบบแฟล็กส่วนหัว
สนาม คำอธิบาย ความยาว ( บิต )
QR ระบุว่าข้อความนั้นเป็นแบบสอบถาม (0) หรือการตอบกลับ (1) 1
OPCODE ประเภทอาจเป็น QUERY (ข้อความค้นหามาตรฐาน 0) IQUERY (ข้อความค้นหาผกผัน 1) หรือสถานะ (คำขอสถานะเซิร์ฟเวอร์ 2) 4
AA คำตอบที่เชื่อถือได้ ในการตอบกลับระบุว่าเซิร์ฟเวอร์ DNS มีสิทธิ์สำหรับชื่อโฮสต์ที่สืบค้นหรือไม่ 1
TC TrunCation แสดงว่าข้อความนี้ถูกตัดทอนเนื่องจากมีความยาวมากเกินไป 1
RD ต้องการการเรียกซ้ำ ระบุว่าไคลเอนต์หมายถึงแบบสอบถามแบบเรียกซ้ำหรือไม่ 1
RA Recursion Available ในการตอบสนองระบุว่าเซิร์ฟเวอร์ DNS ตอบกลับรองรับการเรียกซ้ำหรือไม่ 1
Z Zero สงวนไว้สำหรับใช้ในอนาคต 3
RCODE รหัสตอบกลับ สามารถเป็น NOERROR (0), FORMERR (1, รูปแบบข้อผิดพลาด), SERVFAIL (2), NXDOMAIN (3, โดเมนที่ไม่มีอยู่) เป็นต้น[35] 4

หลังแฟล็ก ส่วนหัวจะลงท้ายด้วยจำนวนเต็ม 16 บิตสี่ตัวซึ่งมีจำนวนเร็กคอร์ดในแต่ละส่วนที่ตามมา ในลำดับเดียวกัน

ส่วนคำถาม

ส่วนคำถามมีรูปแบบที่ง่ายกว่ารูปแบบระเบียนทรัพยากรที่ใช้ในส่วนอื่นๆ บันทึกคำถามแต่ละข้อ (โดยปกติจะมีเพียงหนึ่งส่วนในส่วนนี้) ประกอบด้วยฟิลด์ต่อไปนี้:

เขตข้อมูลระเบียนทรัพยากร (RR)
สนาม คำอธิบาย ความยาว ( ออกเตต )
ชื่อ ชื่อของทรัพยากรที่ร้องขอ ตัวแปร
พิมพ์ ประเภทของ RR (A, AAAA, MX, TXT เป็นต้น) 2
ระดับ รหัสชั้นเรียน 2

ชื่อโดเมนแบ่งออกเป็นป้ายกำกับแยกกันซึ่งต่อกัน ป้ายกำกับแต่ละอันนำหน้าด้วยความยาวของป้ายกำกับนั้น (36)

โปรโตคอลการขนส่ง DNS

DNS-over-UDP/53 ("Do53")

นับตั้งแต่ต้นกำเนิดในปี 1983 จนกระทั่งเมื่อไม่นานมานี้ DNS ได้ตอบคำถามเกี่ยวกับพอร์ตUser Datagram Protocol (UDP) หมายเลข 53 เป็นหลัก [3]ข้อความค้นหาดังกล่าวประกอบด้วยคำขอข้อความธรรมดาที่ส่งในแพ็กเก็ต UDP เดียวจากไคลเอนต์ ตอบกลับด้วยการตอบกลับแบบข้อความธรรมดาที่ส่งในแพ็กเก็ต UDP เดียวจากเซิร์ฟเวอร์ เมื่อความยาวของคำตอบเกิน 512 ไบต์ และทั้งไคลเอ็นต์และเซิร์ฟเวอร์สนับสนุนกลไกส่วนขยายสำหรับ DNS (EDNS) อาจใช้แพ็กเก็ต UDP ที่ใหญ่กว่า [37]การใช้ DNS-over-UDP ถูกจำกัดด้วยการขาดการเข้ารหัสระดับการขนส่ง การตรวจสอบสิทธิ์ การส่งที่เชื่อถือได้ และความยาวของข้อความ

DNS-over-TCP/53 ("Do53/TCP")

ในปี 1989 RFC 1123 ระบุการส่งข้อมูล Transmission Control Protocol (TCP) ที่เป็นตัวเลือกสำหรับการสืบค้น DNS การตอบกลับ และโดยเฉพาะอย่างยิ่ง การถ่ายโอนโซน ผ่านการกระจายตัวของการตอบกลับที่ยาวนาน TCP ช่วยให้ตอบสนองได้ยาวนานขึ้น ส่งมอบที่เชื่อถือได้ และนำการเชื่อมต่อที่มีอายุการใช้งานยาวนานมาใช้ซ้ำระหว่างไคลเอนต์และเซิร์ฟเวอร์

DNSCrypt

โปรโตคอลDNSCryptซึ่งพัฒนาขึ้นในปี 2554 นอก กรอบมาตรฐาน IETFได้แนะนำการเข้ารหัส DNS ที่ฝั่งดาวน์สตรีมของตัวแก้ไขแบบเรียกซ้ำ โดยที่ไคลเอนต์เข้ารหัสเพย์โหลดการสืบค้นโดยใช้คีย์สาธารณะของเซิร์ฟเวอร์ ซึ่งเผยแพร่ใน DNS (แทนที่จะใช้บุคคลที่สาม ผู้ออกใบรับรองของฝ่าย) และอาจได้รับการปกป้องโดยลายเซ็น DNSSEC [38]DNSCrypt ใช้พอร์ต TCP หรือ UDP 443 ซึ่งเป็นพอร์ตเดียวกับการรับส่งข้อมูลเว็บที่เข้ารหัส HTTPS สิ่งนี้ไม่เพียงแต่แนะนำความเป็นส่วนตัวเกี่ยวกับเนื้อหาของการสืบค้น แต่ยังเป็นการวัดความสามารถในการข้ามผ่านไฟร์วอลล์ที่สำคัญอีกด้วย ในปี 2019 DNSCrypt ได้รับการขยายเพิ่มเติมเพื่อรองรับโหมด "ไม่ระบุชื่อ" คล้ายกับ " DNS ที่ลืมเลือน" ที่เสนอ ซึ่งโหนดขาเข้าจะได้รับข้อความค้นหาที่ได้รับการเข้ารหัสด้วยกุญแจสาธารณะของเซิร์ฟเวอร์อื่น และส่งต่อไปยังสิ่งนั้น เซิร์ฟเวอร์ซึ่งทำหน้าที่เป็นโหนดขาออก ดำเนินการแก้ไขแบบเรียกซ้ำ [39]ความเป็นส่วนตัวของคู่ผู้ใช้/การสืบค้นถูกสร้างขึ้น เนื่องจากโหนดขาเข้าไม่ทราบเนื้อหาของการสืบค้น ในขณะที่โหนดขาออกไม่ทราบตัวตนของลูกค้า

DNS-over-TLS ("DoT")

มาตรฐาน IETF สำหรับ DNS ที่เข้ารหัสปรากฏในปี 2559 โดยใช้ Transport Layer Security (TLS) มาตรฐานเพื่อปกป้องการเชื่อมต่อทั้งหมด ไม่ใช่แค่เพย์โหลด DNS เซิร์ฟเวอร์ DoT รับฟังบนพอร์ต TCP 853 RFC7858 ระบุว่าการเข้ารหัสฉวยโอกาสและการเข้ารหัสที่รับรองความถูกต้องอาจได้รับการสนับสนุน แต่ไม่ได้กำหนดให้มีการตรวจสอบสิทธิ์เซิร์ฟเวอร์หรือไคลเอ็นต์

DNS-over-HTTPS ("DoH")

มาตรฐานที่แข่งขันกันสำหรับการขนส่งการสืบค้น DNS ถูกนำมาใช้ในปี 2018 โดยการทันเนลข้อมูลการสืบค้น DNS ผ่าน HTTPS (ซึ่งจะส่งผ่าน HTTP ผ่าน TLS) DoH ได้รับการส่งเสริมให้เป็นทางเลือกที่เป็นมิตรต่อเว็บมากกว่า DNS เนื่องจากเช่น DNSCrypt มันเดินทางบนพอร์ต TCP 443 ดังนั้นจึงดูคล้ายกับการรับส่งข้อมูลเว็บ แม้ว่าในทางปฏิบัติจะแยกความแตกต่างได้ง่าย [40] DoH ได้รับการวิพากษ์วิจารณ์อย่างกว้างขวางเกี่ยวกับการลดการไม่เปิดเผยตัวตนของผู้ใช้เมื่อเทียบกับ DoT [41]

DNS-over-TOR

เช่นเดียวกับโปรโตคอลอินเทอร์เน็ตอื่นๆ DNS อาจทำงานผ่านVPNและช่องสัญญาณ การใช้งานหนึ่งซึ่งกลายเป็นเรื่องธรรมดามาตั้งแต่ปี 2019 เพื่อรับประกันตัวย่อที่ใช้บ่อยคือ DNS- over- Tor การเพิ่มความเป็นส่วนตัวของ Oblivious DNS สามารถรวบรวมได้ผ่านการใช้เครือข่าย Tor ที่มีอยู่ก่อนหน้าของโหนดขาเข้าและขาออก จับคู่กับการเข้ารหัสชั้นการขนส่งที่จัดเตรียมโดย TLS [42]

DNS-over-HTTPS ที่ลืมเลือน ("ODoH")

ในปี พ.ศ. 2564 ได้มีการเสนอให้มีการนำ DoH ไปใช้ "ที่มองไม่เห็น" และได้นำไปใช้ในรูปแบบร่าง ซึ่งรวมการแยกขาเข้า/ขาออกเข้ากับช่องสัญญาณ HTTPS และการเข้ารหัสชั้นการขนส่ง TLS ในโปรโตคอลที่กำหนดไว้เดียว [43]

บันทึกทรัพยากร

ระบบชื่อโดเมนระบุฐานข้อมูลขององค์ประกอบข้อมูลสำหรับทรัพยากรเครือข่าย ประเภทขององค์ประกอบข้อมูลได้รับการจัดหมวดหมู่และจัดระเบียบด้วยรายการประเภทระเบียน DNS ระเบียนทรัพยากร (RR) แต่ละเร็กคอร์ดมีประเภท (ชื่อและหมายเลข) เวลาหมดอายุ ( time to live ) คลาส และข้อมูลเฉพาะประเภท ระเบียนทรัพยากรประเภทเดียวกันได้รับการอธิบายว่าเป็นชุดระเบียนทรัพยากร (RRset) โดยไม่มีการสั่งซื้อพิเศษ ตัวแก้ไข DNS ส่งคืนทั้งชุดเมื่อสืบค้น แต่เซิร์ฟเวอร์อาจใช้การเรียงลำดับแบบวนซ้ำเพื่อให้สมดุลการโหลด ในทางตรงกันข้ามDomain Name System Security Extensions (DNSSEC) ทำงานกับชุดระเบียนทรัพยากรทั้งหมดตามลำดับบัญญัติ

เมื่อส่งผ่าน เครือข่าย Internet Protocolระเบียนทั้งหมดจะใช้รูปแบบทั่วไปที่ระบุใน RFC 1035: [44]

เขตข้อมูลระเบียนทรัพยากร (RR)
สนาม คำอธิบาย ความยาว ( ออกเตต )
ชื่อ ชื่อของโหนดที่เกี่ยวข้องกับเร็กคอร์ดนี้ ตัวแปร
พิมพ์ ประเภทของ RR ในรูปแบบตัวเลข (เช่น 15 สำหรับ MX RR) 2
ระดับ รหัสชั้นเรียน 2
TTL นับวินาทีที่ RR ยังคงใช้ได้ (สูงสุดคือ 2 31 -1 ซึ่งประมาณ 68 ปี) 4
RDLENGTH ความยาวของฟิลด์ RDATA (ระบุเป็น octets) 2
รดาต้า ข้อมูลเฉพาะ RR เพิ่มเติม ตัวแปรตาม RDLENGTH

NAMEคือชื่อโดเมนแบบเต็มของโหนดในแผนผัง[ ต้องการ คำชี้แจง ] บนสาย ชื่ออาจสั้นลงโดยใช้การบีบอัดฉลากที่ส่วนท้ายของชื่อโดเมนที่กล่าวถึงก่อนหน้านี้ในแพ็คเก็ตสามารถแทนที่สำหรับการสิ้นสุดของชื่อโดเมนปัจจุบัน

TYPEคือประเภทระเบียน ระบุรูปแบบของข้อมูลและให้คำแนะนำการใช้งานตามวัตถุประสงค์ ตัวอย่างเช่น ระเบียน Aใช้เพื่อแปลจากชื่อโดเมนเป็นที่อยู่ IPv4 ระเบียน NSแสดงรายการเซิร์ฟเวอร์ชื่อใดที่สามารถตอบการค้นหาในโซน DNSและ ระเบียน MXระบุเซิร์ฟเวอร์อีเมลที่ใช้จัดการอีเมลสำหรับโดเมนที่ระบุ ในที่อยู่อีเมล

RDATAคือข้อมูลที่มีความเกี่ยวข้องเฉพาะประเภท เช่น ที่อยู่ IP สำหรับระเบียนที่อยู่ หรือลำดับความสำคัญและชื่อโฮสต์สำหรับระเบียน MX ประเภทระเบียนที่รู้จักกันดีอาจใช้การบีบอัดป้ายกำกับในช่อง RDATA แต่ประเภทระเบียน "ที่ไม่รู้จัก" ต้องไม่ใช้ (RFC 3597)

CLASSของระเบียนถูกตั้งค่าเป็น IN (สำหรับInternet ) สำหรับระเบียน DNS ทั่วไปที่เกี่ยวข้องกับชื่อโฮสต์อินเทอร์เน็ต เซิร์ฟเวอร์ หรือที่อยู่ IP นอกจากนี้ยังมีคลาสChaos (CH) และHesiod (HS) [45] แต่ละคลาสเป็นเนมสเปซอิสระที่มีการมอบหมายโซน DNS ที่แตกต่างกัน

นอกจากบันทึกทรัพยากรที่กำหนดไว้ในไฟล์โซนแล้ว ระบบชื่อโดเมนยังกำหนดประเภทคำขอหลายประเภทที่ใช้เฉพาะในการสื่อสารกับโหนด DNS อื่นๆ ( บนสาย ) เช่น เมื่อทำการถ่ายโอนโซน (AXFR/IXFR) หรือสำหรับEDNS (เลือก).

ระเบียน DNS ตัวแทน

ระบบชื่อโดเมนรองรับระเบียน DNS แบบไว ด์การ์ด ซึ่งระบุชื่อที่ขึ้นต้นด้วยป้ายกำกับเครื่องหมายดอกจัน '*' เช่น *.example [20] [46]ระเบียน DNS ที่เป็นของชื่อโดเมนไวด์การ์ดจะระบุกฎสำหรับการสร้างระเบียนทรัพยากรภายในโซน DNS เดียวโดยแทนที่ป้ายกำกับทั้งหมดด้วยองค์ประกอบที่ตรงกันของชื่อการสืบค้น รวมถึงผู้สืบทอดที่ระบุ ตัวอย่างเช่น ในการกำหนดค่าต่อไปนี้ x.exampleโซน DNS ระบุว่าโดเมนย่อยทั้งหมด รวมถึงโดเมนย่อยของโดเมนย่อยของx.example ใช้ axexampleของตัวแลกเปลี่ยนเมล (MX) บันทึก A สำหรับaxexampleจำเป็นต้องระบุที่อยู่ IP ของตัวแลกเปลี่ยนเมล เนื่องจากสิ่งนี้มีผลจากการยกเว้นชื่อโดเมนนี้และโดเมนย่อยจากการจับคู่ไวด์การ์ด เรคคอร์ด MX เพิ่มเติมสำหรับaxexample ของโดเมนย่อย รวมถึงเรคคอร์ด MX แบบไวด์การ์ดสำหรับโดเมนย่อยทั้งหมดจึงต้องกำหนดในโซน DNS

x.ตัวอย่าง ตัวอย่าง MX 10
*.x.ตัวอย่าง ตัวอย่าง MX 10
*.ตัวอย่าง. ตัวอย่าง MX 10
ตัวอย่าง ตัวอย่าง MX 10
ตัวอย่าง AAAA 2001:db8::1

บทบาทของเร็กคอร์ดไวด์การ์ดได้รับการขัดเกลาในRFC  4592เนื่องจากคำจำกัดความดั้งเดิมในRFC 1034นั้นไม่สมบูรณ์และส่งผลให้เกิดการตีความที่ผิดโดยผู้ดำเนินการ [46] 

ส่วนขยายโปรโตคอล

โปรโตคอล DNS ดั้งเดิมมีข้อกำหนดที่จำกัดสำหรับการขยายด้วยคุณสมบัติใหม่ ในปี 2542 Paul Vixie ตีพิมพ์ใน RFC 2671 (แทนที่โดย RFC 6891) ซึ่งเป็นกลไกการขยายที่เรียกว่ากลไกส่วนขยายสำหรับ DNS (EDNS) ซึ่งแนะนำองค์ประกอบโปรโตคอลที่เป็นตัวเลือกโดยไม่เพิ่มค่าใช้จ่ายเมื่อไม่ได้ใช้งาน สิ่งนี้ทำได้สำเร็จผ่านเร็กคอร์ดทรัพยากรหลอก OPT ที่มีอยู่เฉพาะในการส่งผ่านสายของโปรโตคอล แต่ไม่มีในไฟล์โซนใดๆ นอกจากนี้ยังแนะนำส่วนขยายเริ่มต้น (EDNS0) เช่นการเพิ่มขนาดข้อความ DNS ในดาตาแกรม UDP

การอัปเดตโซนไดนามิก

การอัปเดต DNS แบบไดนามิกใช้ UPDATE DNS opcode เพื่อเพิ่มหรือลบระเบียนทรัพยากรแบบไดนามิกจากฐานข้อมูลโซนที่ดูแลอยู่บนเซิร์ฟเวอร์ DNS ที่เชื่อถือได้ คุณลักษณะนี้อธิบายไว้ใน RFC 2136 สิ่งอำนวยความสะดวกนี้มีประโยชน์ในการลงทะเบียนไคลเอ็นต์เครือข่ายใน DNS เมื่อบูตหรือพร้อมใช้งานบนเครือข่าย เนื่องจากไคลเอนต์สำหรับบู๊ตอาจได้รับที่อยู่ IP ที่แตกต่างกันในแต่ละครั้งจากเซิร์ฟเวอร์ DHCPจึงเป็นไปไม่ได้ที่จะให้การกำหนด DNS แบบคงที่สำหรับไคลเอนต์ดังกล่าว

ปัญหาด้านความปลอดภัย

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

ปัญหาช่องโหว่หลายอย่างถูกค้นพบและใช้ประโยชน์จากผู้ใช้ที่ประสงค์ร้าย ปัญหาดังกล่าวประการหนึ่งคือDNS cachepoisoningซึ่งข้อมูลถูกแจกจ่ายไปยังตัวแก้ไขการแคชโดยอ้างว่าเป็นเซิร์ฟเวอร์ต้นทางที่เชื่อถือได้ ซึ่งทำให้ที่เก็บข้อมูลเสียหายด้วยข้อมูลที่อาจผิดพลาดและเวลาหมดอายุที่ยาวนาน (time-to-live) ต่อมา คำขอแอปพลิเคชันที่ถูกต้องอาจถูกเปลี่ยนเส้นทางไปยังโฮสต์เครือข่ายที่ดำเนินการโดยมีเจตนาร้าย

การตอบสนอง DNS ตามเนื้อผ้าไม่มีลายเซ็นเข้ารหัสนำไปสู่ความเป็นไปได้ในการโจมตีมากมาย Domain Name System Security Extensions (DNSSEC) แก้ไข DNS เพื่อเพิ่มการสนับสนุนสำหรับการตอบกลับที่ลงนามด้วยการเข้ารหัส DNSCurveได้รับการเสนอให้เป็นทางเลือกแทน DNSSEC ส่วนขยายอื่นๆ เช่นTSIGเพิ่มการรองรับการตรวจสอบสิทธิ์การเข้ารหัสระหว่างเพียร์ที่เชื่อถือได้ และมักใช้เพื่ออนุญาตการถ่ายโอนโซนหรือการดำเนินการอัปเดตแบบไดนามิก

อาจใช้ชื่อโดเมนบางชื่อเพื่อให้ได้ผลการปลอมแปลง ตัวอย่างเช่น paypal.com และ paypa1.com เป็นชื่อที่แตกต่างกัน แต่ผู้ใช้อาจไม่สามารถแยกความแตกต่างได้ในส่วนติดต่อผู้ใช้แบบกราฟิกขึ้นอยู่กับแบบอักษรที่ ผู้ใช้เลือก ในแบบอักษรจำนวนมาก ตัวอักษรlและตัวเลข1จะดูเหมือนหรือเหมือนกันมาก ปัญหานี้เกิดขึ้นอย่างเฉียบพลันในระบบที่สนับสนุนชื่อโดเมนสากลเนื่องจากรหัสอักขระจำนวนมากในISO 10646อาจปรากฏเหมือนกันบนหน้าจอคอมพิวเตอร์ทั่วไป ช่องโหว่นี้ถูกใช้เป็นครั้งคราวใน ฟิ ชิ่ง [47]

เทคนิคต่างๆ เช่นDNS ย้อนกลับที่ยืนยันล่วงหน้ายังสามารถนำมาใช้เพื่อช่วยตรวจสอบผลลัพธ์ DNS ได้อีกด้วย

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

ปัญหาความเป็นส่วนตัวและการติดตาม

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

ความเป็นส่วนตัวของผู้ใช้ยังถูกเปิดเผยเพิ่มเติมโดยข้อเสนอสำหรับการเพิ่มระดับของข้อมูล IP ไคลเอนต์ในการสืบค้น DNS (RFC 7871) เพื่อประโยชน์ของ เครือข่าย การ จัดส่งเนื้อหา

แนวทางหลักที่ใช้ในการตอบโต้ปัญหาความเป็นส่วนตัวกับ DNS:

  • VPNsซึ่งย้ายความละเอียด DNS ไปยังตัวดำเนินการ VPN และซ่อนการรับส่งข้อมูลของผู้ใช้จาก ISP ในพื้นที่
  • Torซึ่งแทนที่การแก้ไข DNS แบบเดิมด้วย โดเมน .onion ที่ไม่ระบุชื่อ ซ่อนทั้งการแก้ไขชื่อและปริมาณการใช้งานของผู้ใช้ที่อยู่เบื้องหลัง การ เฝ้าระวังการต่อต้านการกำหนดเส้นทางหัวหอม
  • พ ร็อกซี่และเซิร์ฟเวอร์ DNS สาธารณะ ซึ่งย้ายความละเอียด DNS จริงไปยังผู้ให้บริการบุคคลที่สาม ซึ่งมักจะให้คำมั่นว่าจะมีการบันทึกคำขอเพียงเล็กน้อยหรือไม่มีเลย และคุณสมบัติเพิ่มเติมที่เป็นตัวเลือก เช่น การโฆษณา ระดับ DNS หรือการบล็อกภาพอนาจาร
    • สามารถสอบถามเซิร์ฟเวอร์ DNS สาธารณะได้โดยใช้โปรโตคอล DNS แบบดั้งเดิม ซึ่งในกรณีนี้จะไม่มีการป้องกันจากการเฝ้าระวังในพื้นที่ หรือDNS-over-HTTPS , DNS-over-TLSและDNSCryptซึ่งให้การป้องกันดังกล่าว

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

Google เป็นผู้ให้บริการที่โดดเด่นของแพลตฟอร์มในAndroidเบราว์เซอร์ใน Chrome และตัวแก้ไข DNS ในบริการ 8.8.8.8 ภาพจำลองนี้จะเป็นกรณีของนิติบุคคลองค์กรเดียวที่อยู่ในตำแหน่งที่ควบคุมเนมสเปซทั้งหมดของอินเทอร์เน็ตได้หรือไม่ Netflix ได้ติดตั้งแอปที่ใช้กลไกการแก้ปัญหา DNS ของตนเองโดยไม่ขึ้นกับแพลตฟอร์มที่แอปทำงานอยู่ จะเกิดอะไรขึ้นถ้า แอพ Facebookรวม DoH? จะเกิดอะไรขึ้นถ้าiOSของAppleใช้กลไกความละเอียด DoH เพื่อเลี่ยงการแก้ DNS ในเครื่องและคัดแยกการสืบค้น DNS ทั้งหมดจากแพลตฟอร์มของ Apple ไปยังชุดตัวแก้ไขชื่อที่ดำเนินการโดย Apple

—  ความเป็นส่วนตัว DNS และ IETF

การจดทะเบียนชื่อโดเมน

สิทธิ์ในการใช้ชื่อโดเมนนั้นมอบให้โดยผู้รับจดทะเบียนชื่อโดเมนซึ่งได้รับการรับรองจากInternet Corporation for Assigned Names and Numbers (ICANN) หรือองค์กรอื่นๆ เช่นOpenNICซึ่งมีหน้าที่ดูแลระบบชื่อและหมายเลขของอินเทอร์เน็ต นอกเหนือจาก ICANN แล้ว แต่ละโดเมนระดับบนสุด (TLD) จะได้รับการดูแลและให้บริการทางเทคนิคโดยองค์กรที่ดูแลระบบซึ่งดำเนินการจดทะเบียน สำนักทะเบียนมีหน้าที่ดำเนินการฐานข้อมูลของชื่อภายในเขตอำนาจ แม้ว่าคำนี้มักใช้สำหรับ TLD ผู้จดทะเบียนคือบุคคลหรือองค์กรที่ขอจดทะเบียนโดเมน [21] สำนักทะเบียนได้รับข้อมูลการจดทะเบียนจากชื่อโดเมนแต่ละชื่อregistrarซึ่งได้รับอนุญาต (ได้รับการรับรอง) เพื่อกำหนดชื่อในโซนที่เกี่ยวข้องและเผยแพร่ข้อมูลโดยใช้โปรโตคอลWHOIS ในปี 2558 มีการใช้RDAPอยู่ในระหว่างการพิจารณา [49]

ICANN เผยแพร่รายชื่อ TLD, สำนักจดทะเบียน TLD และผู้รับจดทะเบียนชื่อโดเมนทั้งหมด ข้อมูลผู้ลงทะเบียนที่เกี่ยวข้องกับชื่อโดเมนจะได้รับการเก็บรักษาไว้ในฐานข้อมูลออนไลน์ที่เข้าถึงได้ด้วยบริการ WHOIS สำหรับ โดเมนระดับบนสุดตามรหัสประเทศ (ccTLDs) มากกว่า 290 โดเมน สำนักทะเบียนโดเมนจะรักษาข้อมูล WHOIS (ผู้ลงทะเบียน เนมเซิร์ฟเวอร์ วันที่หมดอายุ ฯลฯ) ตัวอย่างเช่นDENICเยอรมนี NIC เก็บข้อมูลโดเมน DE ตั้งแต่ปี 2544 การลงทะเบียน โดเมนระดับบนสุดแบบทั่วไป (gTLD) ส่วนใหญ่ได้นำวิธีการลงทะเบียนแบบ หนาที่เรียกว่าการจดทะเบียนมาใช้ กล่าวคือ การเก็บข้อมูล WHOIS ไว้ในการลงทะเบียนส่วนกลาง แทนที่จะเป็นฐานข้อมูลของผู้รับจดทะเบียน

สำหรับโดเมนระดับบนสุดบน COM และ NET จะใช้โมเดลการลงทะเบียนแบบบาง การลงทะเบียนโดเมน (เช่นGoDaddy , BigRock และ PDR , VeriSignเป็นต้น) เก็บข้อมูล WHOIS พื้นฐาน (เช่น ผู้รับจดทะเบียนและเนมเซิร์ฟเวอร์ เป็นต้น) องค์กรหรือผู้ลงทะเบียนที่ใช้ ORG อยู่ในสำนักทะเบียนสาธารณประโยชน์เท่านั้น

การลงทะเบียนชื่อโดเมนบางแห่ง ซึ่งมักเรียกว่าศูนย์ข้อมูลเครือข่าย (NIC) ยังทำหน้าที่เป็นผู้รับจดทะเบียนให้กับผู้ใช้ปลายทาง นอกเหนือจากการให้สิทธิ์เข้าถึงชุดข้อมูล WHOIS บริษัทรับจดทะเบียนโดเมนระดับบนสุด เช่น สำหรับโดเมน COM, NET และ ORG ใช้แบบจำลองผู้รับจดทะเบียนโดเมนที่ประกอบด้วยผู้รับจดทะเบียนชื่อโดเมนหลายราย [50]ในวิธีการจัดการนี้ สำนักทะเบียนจะจัดการเฉพาะฐานข้อมูลชื่อโดเมนและความสัมพันธ์กับผู้รับจดทะเบียนเท่านั้น ผู้ลงทะเบียน (ผู้ใช้ชื่อโดเมน) เป็นลูกค้าของผู้รับจดทะเบียน ในบางกรณีผ่านการรับเหมาช่วงเพิ่มเติมของผู้ค้าปลีก

เอกสาร RFC

มาตรฐาน

ระบบชื่อโดเมนถูกกำหนดโดย เอกสาร คำขอความคิดเห็น (RFC) ที่เผยแพร่โดยInternet Engineering Task Force ( มาตรฐานอินเทอร์เน็ต ) ต่อไปนี้คือรายการ RFC ที่กำหนดโปรโตคอล DNS

  • RFC  1034 , ชื่อโดเมน - แนวคิดและสิ่งอำนวยความสะดวก
  • RFC  1035 , ชื่อโดเมน - การนำไปใช้และข้อกำหนด
  • RFC  1123 ข้อกำหนดสำหรับโฮสต์อินเทอร์เน็ต—แอปพลิเคชันและการสนับสนุน
  • RFC  1995 , การถ่ายโอนโซนที่เพิ่มขึ้นใน DNS
  • RFC  1996 , กลไกสำหรับการแจ้งการเปลี่ยนแปลงโซนทันที (DNS NOTIFY)
  • RFC  2136 , Dynamic Updates ในระบบชื่อโดเมน (DNS UPDATE)
  • RFC  2181 , การชี้แจงข้อกำหนด DNS
  • RFC  2308 , การแคชเชิงลบของแบบสอบถาม DNS (DNS NCACHE)
  • RFC  2672 , การเปลี่ยนเส้นทางชื่อ DNS ที่ไม่ใช่เทอร์มินัล
  • RFC  2845 , การตรวจสอบธุรกรรมรหัสลับสำหรับ DNS (TSIG)
  • RFC  3225ระบุการสนับสนุนตัวแก้ไขของ DNSSEC
  • ข้อกำหนดขนาดข้อความเซิร์ฟเวอร์/ตัวแก้ไข RFC  3226 , DNSSEC และ IPv6 A6
  • RFC  3596 , ส่วนขยาย DNS เพื่อรองรับ IP เวอร์ชัน 6
  • RFC  3597 , การจัดการประเภทระเบียนทรัพยากร DNS ที่ไม่รู้จัก (RR)
  • RFC  4343 , ระบบชื่อโดเมน (DNS) ชี้แจงกรณีไม่ละเอียดอ่อน
  • RFC  4592 บทบาท ของWildcards ในระบบชื่อโดเมน
  • RFC  4635 , HMAC SHA TSIG Algorithm Identifiers
  • RFC  5001ตัวเลือก DNS Name Server Identifier (NSID)
  • RFC  5011 การอัปเด ตอัตโนมัติของ DNS Security (DNSSEC) Trust Anchors
  • RFC  5452 มาตรการในการทำให้ DNS มีความยืดหยุ่นมากขึ้นกับคำตอบที่ ปลอมแปลง
  • RFC  5890ชื่อโดเมนสากลสำหรับแอปพลิเคชัน (IDNA):คำจำกัดความและกรอบงานเอกสาร
  • RFC  5891ชื่อโดเมนสากลในแอปพลิเคชัน (IDNA): Protocol
  • RFC  5892จุดUnicode Code และชื่อโดเมนสากลสำหรับแอปพลิเคชัน (IDNA)
  • RFC  5893 สคริปต์ จากขวาไปซ้ายสำหรับชื่อโดเมนสากลสำหรับแอปพลิเคชัน (IDNA)
  • RFC  6891 , กลไกการขยายสำหรับ DNS (EDNS0)
  • RFC  7766 , DNS Transport ผ่าน TCP - ข้อกำหนดการใช้งาน

มาตรฐานความปลอดภัยที่เสนอ

  • RFC  4033 , คำแนะนำและข้อกำหนดด้านความปลอดภัย DNS
  • RFC  4034 , Resource Records สำหรับ DNS Security Extensions
  • RFC  4035 , การปรับเปลี่ยนโปรโตคอลสำหรับส่วนขยายความปลอดภัย DNS
  • RFC  4509 , การใช้ SHA-256 ใน DNSSEC Delegation Signer (DS) Resource Records
  • RFC  4470 ครอบคลุมบันทึก NSEC และ DNSSEC Online Signing . น้อยที่สุด
  • RFC  5155 , DNS Security (DNSSEC) แฮชรับรองการปฏิเสธการมีอยู่จริง
  • RFC  5702การใช้อัลกอริทึม SHA-2 กับ RSA ใน DNSKEY และ RRSIG Resource Records สำหรับ DNSSEC
  • RFC  5910 , Domain Name System (DNS) Security Extensions Mapping สำหรับ Extensible Provisioning Protocol (EPP)
  • RFC  5933การใช้อัลกอริทึมลายเซ็น GOST ใน DNSKEY และ RRSIG Resource Records สำหรับ DNSSEC
  • RFC  7830 , ตัวเลือกการเติม EDNS(0)
  • RFC  7858 , ข้อมูลจำเพาะสำหรับ DNS ผ่าน Transport Layer Security (TLS)
  • RFC  8310 , โปรไฟล์การใช้งานสำหรับ DNS ผ่าน TLS และ DNS ผ่าน DTLS
  • RFC  8484 , การสืบค้น DNS ผ่าน HTTPS (DoH)

RFC ทดลอง

  • RFC  1183 , คำจำกัดความ DNS RR ใหม่

แนวทางปฏิบัติที่ดีที่สุดในปัจจุบัน

  • RFC  2182การเลือกและการทำงานของเซิร์ฟเวอร์ DNS สำรอง (BCP 16)
  • RFC  2317 , การมอบหมาย IN-ADDR.ARPA แบบไม่มีคลาส (BCP 20)
  • RFC  5625 , แนวทางการนำ DNS Proxy Implementation (BCP 152)
  • RFC  6895 , ระบบชื่อโดเมน (DNS) ข้อควรพิจารณาของ IANA (BCP 42)
  • RFC  7720 โปรโตคอลบริการชื่อรู ทDNS และข้อกำหนดการปรับใช้ (BCP 40)

RFC ที่ให้ข้อมูล

RFCs เหล่านี้เป็นคำแนะนำในลักษณะ แต่อาจให้ข้อมูลที่เป็นประโยชน์แม้จะไม่ได้กำหนดมาตรฐานหรือ BCP (อาร์เอฟซี 1796)

  • RFC  1178การเลือกชื่อสำหรับคอมพิวเตอร์ของคุณ (FYI 5)
  • RFC  1591 , โครงสร้างระบบชื่อโดเมนและการมอบหมาย
  • RFC  1912ข้อผิดพลาดในการดำเนินการและการกำหนดค่า DNS ทั่วไป
  • RFC  2100 , การตั้งชื่อโฮสต์
  • RFC  3696 เทคนิค การสมัครสำหรับการตรวจสอบและการเปลี่ยนชื่อ
  • อา  ร์เอฟซี 3833 . การวิเคราะห์ภัยคุกคามของระบบชื่อโดเมน (DNS)
  • RFC  4892 ข้อกำหนดสำหรับกลไก การระบุอินสแตนซ์เซิร์ฟเวอร์ชื่อ
  • RFC  5894ชื่อโดเมนสากลสำหรับแอปพลิเคชัน (IDNA): พื้นหลัง คำอธิบาย และเหตุผล
  • RFC  5895 , Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008
  • RFC  7626 ข้อควรพิจารณาเกี่ยวกับความเป็น ส่วนตัวDNS
  • RFC  7706 ลดเวลา ในการเข้าถึงรูทเซิร์ฟเวอร์ด้วยการรัน One บน Loopback
  • RFC  8499 , คำศัพท์ DNS

ไม่รู้จัก

RFCs เหล่านี้มีสถานะอย่างเป็นทางการของUnknownแต่เนื่องจากอายุของพวกมันไม่ได้ระบุไว้อย่างชัดเจน

  • RFC  920 , ข้อกำหนดของโดเมน – ระบุโดเมนระดับบนสุดดั้งเดิม
  • RFC  1032 , คู่มือผู้ดูแลระบบโดเมน
  • RFC  1033 , คู่มือการดำเนินการของผู้ดูแลระบบโดเมน
  • RFC  1101 , การเข้ารหัส DNS ของชื่อเครือข่ายและประเภทอื่นๆ

ดูเพิ่มเติม

อ้างอิง

  1. J. Dilley, B. Maggs, J. Parikh, H. Prokop, R. Sitaraman, and B. Weihl. "Globally Distributed Content Delivery, IEEE Internet Computing, กันยายน/ตุลาคม 2002, หน้า 50-58" (PDF )
  2. ^ Nygren., E.; สิตารามัน RK; ซัน เจ. (2010). "The Akamai Network: แพลตฟอร์มสำหรับแอปพลิเคชั่นอินเทอร์เน็ตประสิทธิภาพสูง" (PDF ) การตรวจสอบระบบ ปฏิบัติการACM SIGOPS 44 (3): 2–19. ดอย : 10.1145/1842733.1842736 . S2CID 207181702 . สืบค้นเมื่อ19 พฤศจิกายน 2555 .  
  3. ↑ a b c d e f Mockapetris , Paul (พฤศจิกายน 1987) ชื่อโดเมน - การนำไป ใช้และข้อกำหนด ไออีทีเอฟ ดอย : 10.17487/RFC1035 . อา ร์เอฟ ซี1035
  4. ↑ จำปิกา วิชัยทุง คะ (กุมภาพันธ์ 2558). "การจัดการการละเมิด DNS" (PDF ) แอพนิค สืบค้นเมื่อ18 ธันวาคม 2559 .
  5. ^ RFC 3467 "บทบาทของระบบชื่อโดเมน (DNS)" JC Klensin, J. Klensin (กุมภาพันธ์ 2546)
  6. ^ หลิว คริกเก็ต; อัลบิตซ์, พอล (2006). DNS และ BIND (ฉบับที่ 5) โอเรลลี่ มีเดีย. หน้า 3. ISBN 978-0-596-10057-5.
  7. ^ อีแวนส์ 2018 , p. 112.
  8. ^ อีแวนส์ 2018 , p. 113.
  9. ^ IEEE Annals [3B2-9] man2011030074.3d 29/7/011 11:54 หน้า 74
  10. อรรถa "ทำไมเน็ตถึงยังคงทำงานในวันคริสต์มาส Paul Mockapetris - Internet Hall of Fame " internethalloffame.org .
  11. อรรถเป็น อีแวนส์ 2018 , พี. 119.
  12. ^ อีแวนส์ 2018 , p. 120.
  13. ^ อีแวนส์ 2018 , p. 120–121.
  14. ^ "เอลิซาเบธ ไฟน์เลอร์" . อินเทอร์เน็ตฮอลล์ออฟเฟเก็บถาวรจากต้นฉบับเมื่อ 14 กันยายน 2018 . สืบค้นเมื่อ2018-11-25 .
  15. ^ "Paul Mockapetris | Internet Hall of Fame" . internethalloffame.org . สืบค้นเมื่อ2020-02-12 .
  16. อังเดร โรบาเชฟสกี (26 พฤศจิกายน 2556). "สุขสันต์วันเกิด 30 ปี DNS!" . สังคมอินเทอร์เน็ต. สืบค้นเมื่อ18 ธันวาคม 2558 .
  17. ^ Elizabeth Feinler, IEEE Annals, 3B2-9 man2011030074.3d 29/7/011 11:54 หน้า 74
  18. ^ เทอร์รี่ ดักลาส บี.; และคณะ (12-15 มิถุนายน 2527) "เซิร์ฟเวอร์โดเมนชื่ออินเทอร์เน็ตของเบิร์กลีย์ " การประชุมภาคฤดูร้อน ซอลท์เลคซิตี้ 1984: การดำเนินการ USENIX Association กลุ่มผู้ใช้เครื่องมือซอฟต์แวร์ น. 23–31.
  19. ^ สมาคมระบบอินเทอร์เน็ต "ประวัติความผูกพัน" . ประวัติของ BIND เก็บถาวรจากต้นฉบับเมื่อ 2019-06-30 . สืบค้นเมื่อ4 เมษายน 2022 .
  20. ↑ a b c d e Mockapetris , Paul (พฤศจิกายน 1987) ชื่อโดเมน - แนวคิดและสิ่งอำนวยความสะดวกของ โดเมน ไออีทีเอฟ ดอย : 10.17487/RFC1034 . อา ร์เอฟซี 1034 .
  21. ^ พอล ฮอฟฟ์แมน; แอนดรูว์ ซัลลิแวน; คาซูโนริ ฟูจิวาระ (ธันวาคม 2558) คำศัพท์ DNS ไออีทีเอฟ ดอย : 10.17487/RFC7719 . อา ร์เอฟซี 7719 . สืบค้นเมื่อ18 ธันวาคม 2558 .
  22. ^ Paul Mockapetris (พฤศจิกายน 1987) "ข้อกำหนดพื้นที่ชื่อและคำศัพท์" . ชื่อโดเมน - แนวคิดและสิ่งอำนวยความสะดวกของ โดเมน ไออีทีเอฟ วินาที 3.1. ดอย : 10.17487/RFC1034 . อา ร์เอฟซี 1034 . สืบค้นเมื่อ17 ธันวาคม 2558 .
  23. ↑ a b Paul Mockapetris (พฤศจิกายน 1987). "ฐานข้อมูลแบ่งเป็นโซนอย่างไร" . ชื่อโดเมน - แนวคิดและสิ่งอำนวยความสะดวกของ โดเมน ไออีทีเอฟ วินาที 4.2. ดอย : 10.17487/RFC1034 . อา ร์เอฟซี 1034 . สืบค้นเมื่อ17 ธันวาคม 2558 .
  24. ลินด์ซีย์, เดวิด (2007). กฎหมายชื่อโดเมนระหว่างประเทศ: ICANN และ UDRP สำนักพิมพ์บลูมส์เบอรี่ หน้า 8. ISBN 978-1-84113-584-7.
  25. ^ คณะทำงานเครือข่ายของ IETF มกราคม 2549 RFC 4343: Domain Name System (DNS) Case Insensitivity Clarification
  26. a b RFC 3696, Application Techniques for Checking and Transformation of Names , J. Klensin
  27. ฟุจิวาระ, คาซูโนริ; ซัลลิแวน, แอนดรูว์; ฮอฟแมน, พอล. "คำศัพท์ DNS " tools.ietf.org . สืบค้นเมื่อ2020-06-21 .
  28. ^ เนเมธ อีวี; สไนเดอร์, การ์ธ; ไฮน์, เทรนต์ อาร์. (2549-10-30). คู่มือการดูแลระบบ Linux แอดดิสัน-เวสลีย์ โปรเฟสชั่นแนล ISBN 978-0-13-700275-7.
  29. บิสแยนเด, เตกาเวนเด เอฟ.; เซีย, โอมาโร (2017-10-09). โครงสร้างพื้นฐานอิเล็กทรอนิกส์และ e-Services สำหรับประเทศกำลังพัฒนา: การประชุมนานาชาติครั้งที่ 8, AFRICOMM 2016, วากาดูกู, บูร์กินาฟาโซ, 6-7 ธันวาคม 2559, การดำเนินการ สปริงเกอร์. ISBN 978-3-319-66742-3.
  30. ^ "โซน DNS" . IONOS ดิจิตอลไกด์ สืบค้นเมื่อ2022-03-31 .
  31. ^ "การเผยแพร่ DNS คืออะไร" . IONOS ดิจิตอลไกด์ สืบค้นเมื่อ2022-04-22 .
  32. ^ "ผู้ให้บริการละเว้น DNS TTL หรือไม่" . ส แลชดอท 2548 . สืบค้นเมื่อ2012-04-07 .
  33. เบน แอนเดอร์สัน (7 กันยายน 2554). "เบ็น แอนเดอร์สัน: เหตุใดการแคช DNS ของเว็บเบราว์เซอร์จึงเป็นสิ่งที่ไม่ดี" สืบค้นเมื่อ20 ตุลาคม 2557 .
  34. ^ "วิธีที่ Internet Explorer ใช้แคชสำหรับรายการโฮสต์ DNS " ไมโครซอฟท์ คอร์ปอเรชั่น . 2547 . สืบค้นเมื่อ2010-07-25 .
  35. ^ "พารามิเตอร์ระบบชื่อโดเมน (DNS) " ไออาน่า. DNS RCODE สืบค้นเมื่อ14 มิถุนายน 2019 .
  36. เจมส์ เอฟ. คุโรเสะและคีธ ดับเบิลยู รอสส์, Computer Networking: A Top-Down Approach, 6th ed. เอสเซกซ์ ประเทศอังกฤษ: Pearson Educ Limited ปี 2012
  37. ^ RFC 2671 ,กลไกส่วนขยายสำหรับ DNS (EDNS0) , P. Vixie (สิงหาคม 2542) 
  38. อูเลวิช, เดวิด (6 ธันวาคม 2554). "DNSCrypt – สำคัญ พื้นฐาน และเกี่ยวกับเวลา " ซิสโก้ อัม เบรลล่า . เก็บจากต้นฉบับเมื่อ 1 กรกฎาคม 2020
  39. ^ "ข้อกำหนด DNSCrypt ที่ไม่ระบุชื่อ " GitHub . DNSCrypt เก็บจากต้นฉบับเมื่อ 25 ตุลาคม 2019
  40. ซีกอร์, เลเวนเต; Divakaran, Dinil Mon (กุมภาพันธ์ 2021) "ความเป็นส่วนตัวของ DNS-over-HTTPS: Requiem for a Dream?" (PDF) . มหาวิทยาลัยแห่งชาติสิงคโปร์. เราตรวจสอบว่าทราฟฟิก DoH แตกต่างจากทราฟฟิกเว็บที่เข้ารหัสหรือไม่ ด้วยเหตุนี้ เราจึงฝึกโมเดลการเรียนรู้ของเครื่องเพื่อจัดประเภทการรับส่งข้อมูล HTTPS เป็นเว็บหรือ DoH ด้วยโมเดลการระบุ DoH ของเรา เราแสดงให้เห็นว่า ISP เผด็จการสามารถระบุ ~97.4% ของแพ็กเก็ต DoH ได้อย่างถูกต้อง ในขณะที่จัดประเภทผิดเพียง 1 ใน 10,000 แพ็กเก็ตเว็บ
  41. ^ Posch, Maya (21 ตุลาคม 2019). "DNS-over-HTTPS เป็นโซลูชันที่ไม่ถูกต้องบางส่วน " แฮคคาเดย์DoH ลบตัวเลือกสำหรับผู้ให้บริการเครือข่าย (ส่วนตัวและองค์กร) เพื่อรักษาความปลอดภัยเครือข่ายของตนเองตามที่ Paul Vixie หนึ่งในสถาปนิกที่อยู่เบื้องหลัง DNS ชี้ให้เห็นบน Twitter เมื่อปีที่แล้ว DoH คือ DNS-over-HTTP-over-TLS เป็นหลัก ส่งผลให้มีสื่อประเภทแอปพลิเคชัน/ข้อความ DNS แบบ mime และความซับซ้อนที่เพิ่มขึ้นอย่างมาก การผสม DoH เข้ากับโปรโตคอลที่มีอยู่ หมายความว่าทุกคำขอและการตอบสนองของ DNS ต้องผ่านสแต็ก HTTPS สำหรับแอปพลิเคชันแบบฝังตัว นี่เป็นสถานการณ์ฝันร้าย แต่ก็เข้ากันไม่ได้กับฮาร์ดแวร์ความปลอดภัยที่มีอยู่เกือบทุกชิ้น เมื่อแอปปลอมอย่างเช่น Firefox หลีกเลี่ยง DNS ที่ใช้ DoT ของระบบ และใช้ตัวแก้ไข DNS ของตัวเองบน DoH แทน จะทำให้สถานการณ์ความปลอดภัยมีความทึบสูง การแก้ไข DNS นั้นจะย้ายไปอยู่ในแต่ละแอปพลิเคชันดังที่เราเห็นอยู่ในขณะนี้
  42. มัฟเฟตต์, อเล็ก (กุมภาพันธ์ 2021). ""ไม่มีพอร์ต 53 ใคร Dis?" ปีของ DNS ผ่าน HTTPS ผ่าน Tor" (PDF)การประชุมวิชาการด้านความปลอดภัยเครือข่ายและการกระจายDNS-over-HTTPS (DoH) ขจัดความเสี่ยงมากมายแต่ไม่ทั้งหมด และโปรโตคอลการขนส่ง (เช่น HTTPS) ทำให้เกิดความกังวลเรื่องความเป็นส่วนตัวเนื่องจาก ถึง (เช่น) 'คุกกี้' เครือข่าย Tor มีอยู่เพื่อให้วงจร TCP เป็นอิสระจากการติดตาม การเฝ้าระวัง และการบล็อก ดังนั้น: ร่วมกับ Tor, DoH และหลักการของ "Don't Do That, Then" (DDTT) เพื่อบรรเทาคำขอลายนิ้วมือ I อธิบาย DNS ผ่าน HTTPS ผ่าน Tor (DoHoT)
  43. ^ พอลลี, ทอมมี่ (2 กันยายน พ.ศ. 2564) "DNSที่ลืมเลือนผ่าน HTTPS" ไออีทีเอฟ
  44. ^ RFC 5395, Domain Name System (DNS) ข้อควรพิจารณาของ IANA , D. Eastlake 3rd (พฤศจิกายน 2008), ส่วนที่ 3
  45. ^ RFC 5395, Domain Name System (DNS) ข้อควรพิจารณาของ IANA , D. Eastlake 3rd (พฤศจิกายน 2008), p. 11
  46. a b RFC 4592 , The Role of Wildcards in the Domain Name System , E. Lewis (กรกฎาคม 2549) 
  47. ^ APWG. "แบบสำรวจฟิชชิ่งทั่วโลก: การใช้ชื่อโดเมนและแนวโน้มในครึ่งปีแรก 2553" 10/15/2010 apwg.org เก็บถาวร 2012-10-03 ที่ Wayback Machine
  48. a b Huston, Geoff (กรกฎาคม 2019). "ความเป็นส่วนตัวของ DNS และ IETF" (PDF ) วารสารอินเทอร์เน็ตโปรโตคอล
  49. ^ "โปรไฟล์การดำเนินงานโปรโตคอลการเข้าถึงข้อมูลการลงทะเบียน (RDAP) สำหรับการลงทะเบียนและผู้รับจดทะเบียน gTLD " ไอแคน 3 ธันวาคม 2558 เก็บถาวรจากต้นฉบับเมื่อ 22 ธันวาคม 2558 . สืบค้นเมื่อ18 ธันวาคม 2558 .
  50. ^ "ค้นหานายทะเบียน" . VeriSign, Inc. สืบค้นเมื่อ18 ธันวาคม 2558 .

ที่มา

ลิงค์ภายนอก