ระบบชื่อโดเมน ( DNS ) เป็นบริการชื่อ แบบลำดับชั้นและกระจาย ที่ให้บริการระบบการตั้งชื่อสำหรับคอมพิวเตอร์บริการ และทรัพยากรอื่นๆ บนอินเทอร์เน็ตหรือ เครือข่าย โปรโตคอลอินเทอร์เน็ต (IP) อื่นๆ โดยจะเชื่อมโยงข้อมูลต่างๆ กับชื่อโดเมน ( สตริงระบุตัวตน ) ที่กำหนดให้กับแต่ละเอนทิตีที่เกี่ยวข้อง ที่สำคัญที่สุดคือ การแปลงชื่อโดเมนที่จำได้ง่ายให้เป็นที่อยู่IP ตัวเลข ที่จำเป็นสำหรับการค้นหาและระบุบริการและอุปกรณ์คอมพิวเตอร์ด้วยโปรโตคอลเครือข่าย พื้นฐาน [ ^{1 ]}ระบบชื่อโดเมนเป็นส่วนประกอบที่สำคัญของการทำงานของอินเทอร์เน็ตมาตั้งแต่ปี ¹⁹⁸⁵

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

อินเทอร์เน็ตมีเนมสเปซ หลักสองอย่าง ได้แก่ ลำดับชั้นชื่อโดเมนและที่อยู่ IP ^{[ 2 ]}ระบบชื่อโดเมน (DNS) ทำหน้าที่รักษาลำดับชั้นชื่อโดเมนและให้บริการการแปลงระหว่างลำดับชั้นชื่อโดเมนกับที่อยู่ IP เซิร์ฟเวอร์ชื่ออินเทอร์เน็ตและโปรโตคอลการสื่อสารใช้ระบบชื่อโดเมน เซิร์ฟเวอร์ชื่อ DNS คือเซิร์ฟเวอร์ที่จัดเก็บระเบียน DNS สำหรับโดเมน เซิร์ฟเวอร์ชื่อ DNS จะตอบกลับด้วยคำตอบต่อการสอบถามไปยังฐานข้อมูลของตน

ประเภทของระเบียนที่จัดเก็บในฐานข้อมูล DNS ที่พบบ่อยที่สุด ได้แก่ ระเบียนเริ่มต้นของหน่วยงาน ( SOA ), ที่อยู่ IP ( AและAAAA ), ตัวแลกเปลี่ยนอีเมลSMTP (MX), เซิร์ฟเวอร์ชื่อ (NS), ตัวชี้สำหรับการค้นหา DNS ย้อนกลับ (PTR) และนามแฝงชื่อโดเมน (CNAME) แม้ว่า DNS จะไม่ได้มีจุดประสงค์เพื่อเป็นฐานข้อมูลอเนกประสงค์ แต่ก็มีการขยายขอบเขตการใช้งานไปเรื่อยๆ เพื่อจัดเก็บระเบียนสำหรับข้อมูลประเภทอื่นๆ ทั้งสำหรับการค้นหาอัตโนมัติ เช่น ระเบียน DNSSECหรือสำหรับการสอบถามโดยมนุษย์ เช่น ระเบียน บุคคลที่รับผิดชอบ (RP) ในฐานะฐานข้อมูลอเนกประสงค์ DNS ยังถูกนำมาใช้ในการต่อสู้กับอีเมลที่ไม่พึงประสงค์ (สแปม) โดยการจัดเก็บรายการบล็อก ฐานข้อมูล DNS โดยทั่วไปจะถูกจัดเก็บไว้ในไฟล์ข้อความที่มีโครงสร้าง ซึ่งก็คือไฟล์โซนแต่ระบบฐานข้อมูลอื่นๆ ก็เป็นที่นิยมเช่นกัน

เดิมทีระบบชื่อโดเมน (Domain Name System หรือ Domain Name System หรือ DNS) ใช้โปรโตคอล User Datagram Protocol (UDP) เป็นตัวนำในการส่งข้อมูลผ่าน IP แต่เนื่องจากความกังวลเกี่ยวกับความน่าเชื่อถือ ความปลอดภัย และความเป็นส่วนตัว จึงนำไปสู่การพัฒนาโปรโตคอล Transmission Control Protocol (TCP) รวมถึงโปรโตคอลอื่นๆ อีกมากมาย

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

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

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

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

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

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

คณะทำงานด้านวิศวกรรมอินเทอร์เน็ตได้เผยแพร่ข้อกำหนดดั้งเดิมใน RFC 882 และ RFC 883 ในเดือนพฤศจิกายน พ.ศ. 2526 ^{[ 18 ] [ 19 ]}ซึ่งได้รับการปรับปรุงใน RFC 973 ในเดือนมกราคม พ.ศ. 2529 ^{[ 20 ]}

ในปี พ.ศ. 2527 นักศึกษา จาก UC Berkeley จำนวน 4 คน ได้แก่Douglas Terry, Mark Painter, David Riggle และ Songnian Zhou ได้เขียน การใช้งาน เนมเซิร์ฟเวอร์Unix ครั้งแรก สำหรับ Berkeley Internet Name Domain ซึ่งเรียกกันทั่วไปว่าBIND ^{[ 21 ]}ในปี พ.ศ. 2528 Kevin Dunlap จากDECได้ปรับปรุงการใช้งาน DNS อย่างมาก จากนั้น Mike Karels , Phil Almquist และPaul Vixieก็รับช่วงต่อการบำรุงรักษา BIND Internet Systems Consortiumก่อตั้งขึ้นในปี พ.ศ. 2537 โดยRick Adams , Paul VixieและCarl Malamudโดยมีจุดประสงค์เพื่อเป็นศูนย์กลางในการพัฒนาและบำรุงรักษา BIND โดยเฉพาะ BIND เวอร์ชันตั้งแต่ 4.9.3 เป็นต้นไปได้รับการพัฒนาและบำรุงรักษาโดย ISC โดยได้รับการสนับสนุนจากผู้สนับสนุนของ ISC ในฐานะสถาปนิก/โปรแกรมเมอร์ร่วม Bob Halley และ Paul Vixie ได้ปล่อย BIND เวอร์ชัน 8 ที่พร้อมใช้งานจริงเป็นครั้งแรกในเดือนพฤษภาคม พ.ศ. 2540 นับตั้งแต่ปี พ.ศ. 2543 เป็นต้นมา มีนักพัฒนาหลักมากกว่า 43 คนที่ทำงานเกี่ยวกับ BIND ^{[ 22 ]}

ในเดือนพฤศจิกายน พ.ศ. 2530 RFC 1034 ^{[ 23 ]}และ RFC 1035 ^{[ 5 ]}ได้เข้ามาแทนที่ข้อกำหนด DNS ปี พ.ศ. 2526 คำขอความคิดเห็น เพิ่มเติมหลายรายการ ได้เสนอส่วนขยายให้กับโปรโตคอล DNS หลัก^{[ 24 ]}

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

ต้นไม้จะแบ่งย่อยออกเป็นโซนต่างๆโดยเริ่มจากโซนรากโซนDNSอาจประกอบด้วยโดเมนและซับโดเมนได้มากเท่าที่ผู้จัดการโซนเลือก นอกจากนี้ DNS ยังสามารถแบ่งตามคลาส ได้ โดย คลาสที่แยกจากกันสามารถคิดได้ว่าเป็นอาร์เรย์ของต้นไม้เนมสเปซแบบขนาน^{[ 23 ] : §4.2}

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

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

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

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

ป้ายกำกับอาจมีอักขระได้ตั้งแต่ศูนย์ถึง 63 ตัว เนื่องจากความยาวอนุญาตให้ใช้ได้เพียง 6 บิตเท่านั้น ป้ายกำกับว่างที่มีความยาวเป็นศูนย์สงวนไว้สำหรับโซนราก ชื่อโดเมนแบบเต็มต้องมีความยาวไม่เกิน 253 ตัวอักขระในรูปแบบข้อความ (หรือ 254 ตัวอักขระรวมจุดท้าย) ^{[ 23 ]}ในการแสดงไบนารีภายในของ DNS ความยาวสูงสุด 253 นี้ต้องการพื้นที่จัดเก็บ 255 ไบต์ เนื่องจากยังจัดเก็บความยาวของป้ายกำกับแรกจากหลายป้ายกำกับและเพิ่มไบต์ว่างสุดท้าย^{[ 5 ]}ความยาว 255 จะสำเร็จได้ก็ต่อเมื่อมีป้ายกำกับอย่างน้อย 6 ป้าย (นับรวมป้ายกำกับว่างสุดท้ายด้วย) ^{[ 5 ]}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ฝั่งไคลเอ็นต์ของ DNS เรียกว่า DNS resolver resolver มีหน้าที่ในการเริ่มต้นและจัดลำดับการสอบถามซึ่งในที่สุดจะนำไปสู่การแก้ไข (การแปล) ทรัพยากรที่ต้องการอย่างสมบูรณ์ เช่น การแปลชื่อโดเมนเป็นที่อยู่ IP DNS resolver ถูกจำแนกตามวิธีการสอบถามที่หลากหลาย เช่นแบบเรียกซ้ำ แบบไม่เรียกซ้ำและแบบวนซ้ำกระบวนการแก้ไขอาจใช้การผสมผสานของวิธีการเหล่านี้^{[ 23 ]}

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

ในการค้นหาแบบเรียกซ้ำ (recursive query ) ตัวแก้ไข 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 ก่อน ซึ่งก่อให้เกิดการพึ่งพาแบบวนซ้ำ เพื่อทำลายการพึ่งพานี้ เนมเซิร์ฟเวอร์สำหรับโดเมนระดับบนสุด org จึงรวมเรคอร์ด glue ไว้พร้อมกับการมอบหมายสำหรับ example.org เรคอร์ด glue คือเรคอร์ดที่อยู่ซึ่งให้ที่อยู่ IP สำหรับ ns1.example.org ตัวแก้ไขจะใช้ที่อยู่ IP เหล่านี้อย่างน้อยหนึ่งรายการเพื่อสอบถามเซิร์เวอร์ที่ได้รับอนุญาตของโดเมน ซึ่งช่วยให้สามารถดำเนินการสอบถาม DNS ให้เสร็จสมบูรณ์ได้

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

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

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

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

เมื่อทำการค้นหาแบบย้อนกลับ (reverse lookup) ไคลเอนต์ DNS จะแปลงที่อยู่เป็นรูปแบบเหล่านี้ก่อนที่จะสอบถามชื่อสำหรับระเบียน PTR โดยทำตามขั้นตอนการมอบหมาย (delegation chain) เช่นเดียวกับการสอบถาม 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 ที่กำหนดไว้หนึ่งตัวหรือมากกว่านั้น ในกรณีของผู้ใช้ตามบ้านส่วนใหญ่ ผู้ให้บริการอินเทอร์เน็ต (ISP) ที่เครื่องเชื่อมต่ออยู่มักจะจัดหาเซิร์ฟเวอร์ DNS นี้ให้ ผู้ใช้ดังกล่าวอาจกำหนดค่าที่อยู่ของเซิร์ฟเวอร์นั้นด้วยตนเองหรืออนุญาตให้DHCPตั้งค่าให้ อย่างไรก็ตาม ในกรณีที่ผู้ดูแลระบบได้กำหนดค่าระบบให้ใช้เซิร์ฟเวอร์ DNS ของตนเอง ตัวแก้ไข DNS ของพวกเขาจะชี้ไปยังเนมเซิร์ฟเวอร์ที่ดูแลแยกต่างหากขององค์กร ไม่ว่าในกรณีใด เนมเซิร์ฟเวอร์ที่ถูกสอบถามจะดำเนินการตามกระบวนการที่อธิบายไว้ข้างต้นจนกว่าจะพบผลลัพธ์หรือไม่พบ จากนั้นจะส่งผลลัพธ์กลับไปยังตัวแก้ไข DNS สมมติว่าพบผลลัพธ์ ตัวแก้ไขจะแคชผลลัพธ์นั้นไว้เพื่อใช้ในอนาคต และส่งผลลัพธ์กลับไปยังซอฟต์แวร์ที่เริ่มต้นการร้องขอ

ISP ขนาดใหญ่บางแห่งได้กำหนดค่าเซิร์ฟเวอร์ DNS ของตนให้ละเมิดกฎ เช่น โดยการไม่ปฏิบัติตาม TTL หรือโดยการระบุว่าชื่อโดเมนไม่มีอยู่จริงเพียงเพราะเซิร์ฟเวอร์ชื่อหนึ่งไม่ตอบสนอง^{[ 33 ]}

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

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

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

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

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

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

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

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

• ที่อยู่203.0.113.5ถูกบล็อกไว้แล้ว โดยชี้ไปยัง5.113.0.203.blocklist.example ซึ่งแปลงเป็น127.0.0.1
• ที่อยู่203.0.113.6ไม่ได้อยู่ในรายการบล็อกและชี้ไปยัง6.113.0.203.blocklist.exampleโฮสต์เนมนี้อาจไม่ได้ถูกกำหนดค่าไว้ หรือแปลงเป็น127.0.0.2

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

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

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

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

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

รหัสธุรกรรม: 16 บิต

รหัสธุรกรรม

แฟล็ก: 16 บิต

ช่องข้อมูลธงประกอบด้วยช่องย่อยดังต่อไปนี้:

QR: 1 บิต

ระบุว่าข้อความนั้นเป็นคำถาม (0) หรือข้อความตอบกลับ (1)

รหัสปฏิบัติการ: 4 บิต

ประเภทสามารถเป็น QUERY (การสืบค้นมาตรฐาน, 0), IQUERY (การสืบค้นแบบย้อนกลับ, 1) หรือ STATUS (การร้องขอสถานะเซิร์ฟเวอร์, 2)

AA: 1 บิต

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

TC: 1 บิต

TrunCation แสดงว่าข้อความนี้ถูกตัดทอนเนื่องจากมีความยาวมากเกินไป

RD: 1 บิต

Recursion Desired ระบุว่าไคลเอนต์ต้องการเรียกใช้คำสั่งค้นหาแบบเรียกซ้ำหรือไม่

RA: 1 บิต

ข้อความ "Recursion Available" ในการตอบกลับ บ่งชี้ว่าเซิร์ฟเวอร์ DNS ที่ตอบกลับรองรับการเรียกใช้ฟังก์ชันแบบเรียกซ้ำหรือไม่

Z: 1 บิต; (Z) == 0

ศูนย์ สงวนไว้สำหรับการใช้งานในอนาคต

AD: 1 บิต

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

ซีดี: 1 บิต

การเลือก "ปิดใช้งาน" ในการค้นหาข้อมูล หมายความว่าข้อมูลที่ยังไม่ได้รับการตรวจสอบนั้นสามารถนำมาใช้ในการตอบกลับได้

รหัส RCODE: 4 บิต

รหัสการตอบสนองอาจเป็น NOERROR (0), FORMERR (1, ข้อผิดพลาดรูปแบบ), SERVFAIL (2), NXDOMAIN (3, โดเมนไม่มีอยู่จริง) เป็นต้น^{[ 36 ]}

จำนวนคำถาม: 16 ข้อ

จำนวนคำถาม

จำนวนคำตอบ: 16 บิต

จำนวนคำตอบ

จำนวน RR ของหน่วยงาน: 16 บิต

จำนวนระเบียนทรัพยากรผู้มีอำนาจ

จำนวน RR เพิ่มเติม: 16 บิต

จำนวนระเบียนทรัพยากรเพิ่มเติม

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

ชื่อโดเมนถูกแบ่งออกเป็นป้ายกำกับแยกกันซึ่งนำมาต่อกัน โดยแต่ละป้ายกำกับจะมีคำนำหน้าตามความยาวของป้ายกำกับนั้น^{[ 37 ]}

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

เมื่อส่งผ่าน เครือข่าย โปรโตคอลอินเทอร์เน็ตบันทึกทั้งหมด (คำตอบ อำนาจ และส่วนเพิ่มเติม) จะใช้รูปแบบทั่วไปที่ระบุไว้ใน RFC 1035: ^{[ 38 ] : §3}

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

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

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

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

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

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

x.example. MX 10 a.x.example. *.x.example. MX 10 a.x.example. axexample. MX 10 a.x.example. *.axexample. MX 10 a.x.example. axexample. AAAA 2001:db8::1

บทบาทของเรคอร์ดไวด์การ์ดได้รับการปรับปรุงในRFC 4592เนื่องจากคำจำกัดความเดิมในRFC 1034ไม่สมบูรณ์และส่งผลให้ผู้ใช้งานตีความผิด^{[ 39 ]}  

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

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

นับตั้งแต่เริ่มก่อตั้งในปี 1983 ระบบ DNS ได้ใช้โปรโตคอล User Datagram Protocol (UDP) สำหรับการส่งข้อมูลผ่าน IP ข้อจำกัดของโปรโตคอลนี้ได้กระตุ้นให้เกิดการพัฒนาโปรโตคอลต่างๆ มากมายเพื่อความน่าเชื่อถือ ความปลอดภัย ความเป็นส่วนตัว และเกณฑ์อื่นๆ ในช่วงหลายทศวรรษต่อมา

UDP สงวนหมายเลขพอร์ต 53 ไว้สำหรับเซิร์ฟเวอร์ที่รับฟังการสอบถาม^{[ 5 ]}การสอบถามดังกล่าวประกอบด้วยคำขอข้อความธรรมดาที่ส่งในแพ็กเก็ต UDP เดียวจากไคลเอนต์ และตอบกลับด้วยข้อความธรรมดาที่ส่งในแพ็กเก็ต UDP เดียวจากเซิร์ฟเวอร์ เมื่อความยาวของคำตอบเกิน 512 ไบต์ และทั้งไคลเอนต์และเซิร์ฟเวอร์รองรับกลไกส่วนขยายสำหรับ DNS (EDNS) อาจใช้แพ็กเก็ต UDP ขนาดใหญ่ขึ้นได้^{[ 41 ]}การใช้ DNS ผ่าน UDP มีข้อจำกัดหลายประการ เช่น การขาดการเข้ารหัสระดับการขนส่ง การตรวจสอบสิทธิ์ การส่งมอบที่เชื่อถือได้ และความยาวของข้อความ ในปี 1989 RFC 1123 ได้ระบุ การขนส่ง Transmission Control Protocol (TCP) ที่เป็นทางเลือกสำหรับการสอบถาม DNS การตอบกลับ และโดยเฉพาะอย่างยิ่งการถ่ายโอนโซน TCP อนุญาตให้ตอบกลับได้นานขึ้น ส่งมอบได้อย่างน่าเชื่อถือ และใช้การเชื่อมต่อที่มีอายุการใช้งานยาวนานระหว่างไคลเอนต์และเซิร์ฟเวอร์ซ้ำได้ ผ่านการแบ่งส่วนการตอบกลับที่ยาว สำหรับการตอบสนองที่ใหญ่กว่า เซิร์ฟเวอร์จะแนะนำไคลเอนต์ให้ใช้การขนส่ง TCP

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

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

RFC 9250 ซึ่งเผยแพร่ในปี 2022 โดยInternet Engineering Task Forceอธิบายถึง DNS over QUICโดยมี "คุณสมบัติความเป็นส่วนตัวที่คล้ายกับ DNS over TLS (DoT) [...] และลักษณะความหน่วงที่คล้ายกับ DNS over UDP แบบคลาสสิก" วิธีนี้ไม่เหมือน DNS over HTTP/ 3 ^{[ 43 ]}

RFC 9953 ซึ่งเผยแพร่ในปี 2026 โดยInternet Engineering Task Forceอธิบายถึง DNS over CoAP “กรณีการใช้งานแอปพลิเคชันของ DoC ได้รับแรงบันดาลใจจาก DNS over HTTPS (DoH) (RFC 8484) อย่างไรก็ตาม DoC มุ่งเป้าไปที่การใช้งานใน Internet of Things (IoT) ที่มีข้อจำกัด ซึ่งมักจะขัดแย้งกับข้อกำหนดที่ HTTPS กำหนด” ^{[ ​​44 ]} DoC มีประสิทธิภาพเหนือกว่ากลไกการแก้ไข DNS อื่นๆ ในสถานการณ์ที่มีข้อจำกัด^{[ 45 ]}

Oblivious DNS (ODNS) ถูกคิดค้นและนำไปใช้โดยนักวิจัยที่มหาวิทยาลัยพรินซ์ตันและมหาวิทยาลัยชิคาโกในฐานะส่วนขยายของ DNS ที่ไม่ได้เข้ารหัส^{[ 46 ]}ก่อนที่ DoH จะได้รับการกำหนดมาตรฐานและใช้งานอย่างแพร่หลาย ต่อมา Apple และ Cloudflare ได้นำเทคโนโลยีนี้ไปใช้ในบริบทของ DoH ในชื่อOblivious DoH (ODoH) ^{[ 47 ]} ODoH ผสานการแยกขาเข้า/ขาออก (คิดค้นใน ODNS) เข้ากับการสร้างอุโมงค์ HTTPS ของ DoH และการเข้ารหัสเลเยอร์การขนส่ง TLS ในโปรโตคอลเดียว^{[ 48 ]}

DNS อาจทำงานผ่านเครือข่ายส่วนตัวเสมือน (VPN) และโปรโตคอลการสร้างอุโมงค์ผลประโยชน์ด้านความเป็นส่วนตัวของ Oblivious DNS สามารถได้รับจากการใช้ เครือข่าย Tor ที่มีอยู่แล้ว ของโหนดขาเข้าและขาออก ควบคู่กับการเข้ารหัสเลเยอร์การขนส่งที่จัดให้โดย TLS ^{[ 49 ]}

โปรโตคอลDNSCryptซึ่งพัฒนาขึ้นในปี 2011 นอก กรอบมาตรฐาน IETFได้นำเสนอการเข้ารหัส DNS ในฝั่งดาวน์สตรีมของตัวแก้ไขแบบเรียกซ้ำ โดยที่ไคลเอ็นต์จะเข้ารหัสเพย์โหลดการสอบถามโดยใช้คีย์สาธารณะของเซิร์ฟเวอร์ ซึ่งเผยแพร่ใน DNS (แทนที่จะพึ่งพาหน่วยงานออกใบรับรองของบุคคลที่สาม) และอาจได้รับการปกป้องโดยลายเซ็นDNSSEC ^{[ 50 ]} DNSCrypt ใช้พอร์ต TCP 443 ซึ่งเป็นพอร์ตเดียวกับ ทราฟฟิกเว็บที่เข้ารหัส HTTPSหรือพอร์ต UDP 443 สิ่งนี้ไม่เพียงแต่นำเสนอความเป็นส่วนตัวเกี่ยวกับเนื้อหาของการสอบถามเท่านั้น แต่ยังรวมถึงความสามารถในการทะลุผ่านไฟร์วอลล์อย่างมีนัยสำคัญอีกด้วย ในปี 2019 DNSCrypt ได้รับการขยายเพิ่มเติมเพื่อรองรับโหมด "ไม่ระบุตัวตน" คล้ายกับ "Oblivious DNS" ที่เสนอ ซึ่งโหนดขาเข้าจะได้รับการสอบถามที่เข้ารหัสด้วยคีย์สาธารณะของเซิร์ฟเวอร์อื่น และส่งต่อไปยังเซิร์ฟเวอร์นั้น ซึ่งทำหน้าที่เป็นโหนดขาออก ทำการแก้ไขแบบเรียกซ้ำ^{[ 51 ]}ความเป็นส่วนตัวของคู่ผู้ใช้/คำถามถูกสร้างขึ้น เนื่องจากโหนดขาเข้าไม่ทราบเนื้อหาของคำถาม ในขณะที่โหนดขาออกไม่ทราบตัวตนของไคลเอนต์ DNSCrypt ถูกนำไปใช้งานจริงครั้งแรกโดยOpenDNSในเดือนธันวาคม 2011 มีซอฟต์แวร์โอเพนซอร์สฟรีหลายตัวที่รวม ODoH เข้าไปด้วย^{[ 52 ]}สามารถใช้งานได้กับระบบปฏิบัติการที่หลากหลาย รวมถึง Unix, Apple iOS, Linux, Android และ Windows

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

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

โดยทั่วไปแล้ว การตอบสนองของ DNS จะไม่มีลายเซ็นเข้ารหัสลับทำให้เกิดความเป็นไปได้ในการโจมตีมากมาย ส่วนขยายความปลอดภัยของระบบชื่อโดเมน (DNSSEC) ปรับเปลี่ยน DNS เพื่อเพิ่มการสนับสนุนสำหรับการตอบสนองที่มีลายเซ็นเข้ารหัสลับ^{[ 53 ]} DNSCurveได้รับการเสนอให้เป็นทางเลือกแทน DNSSEC ส่วนขยายอื่นๆ เช่นTSIGเพิ่มการสนับสนุนสำหรับการตรวจสอบความถูกต้องทางเข้ารหัสลับระหว่างคู่ค้าที่เชื่อถือได้ และมักใช้เพื่ออนุญาตการถ่ายโอนโซนหรือการดำเนินการอัปเดตแบบไดนามิก

เทคนิคต่างๆ เช่นการยืนยันย้อนกลับ DNS แบบส่งต่อ (forward-confirmed reverse DNS)สามารถนำมาใช้เพื่อช่วยตรวจสอบความถูกต้องของผลลัพธ์ DNS ได้เช่นกัน

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• RFC  1034 – " ชื่อโดเมน - แนวคิดและสิ่งอำนวยความสะดวก " มาตรฐานอินเทอร์เน็ต 13
• RFC  1035 – " ชื่อโดเมน - การใช้งานและข้อกำหนด " มาตรฐานอินเทอร์เน็ต 13
• RFC  1123 – " ข้อกำหนดสำหรับโฮสต์อินเทอร์เน็ต -- การใช้งานและการสนับสนุน " มาตรฐานอินเทอร์เน็ต 3
• RFC  1995 – " การถ่ายโอนโซนแบบเพิ่มทีละส่วนใน DNS " มาตรฐานที่เสนอ
• RFC  1996 – " กลไกสำหรับการแจ้งเตือนการเปลี่ยนแปลงโซนอย่างรวดเร็ว (DNS NOTIFY) " มาตรฐานที่เสนอ
• RFC  2136 – " การอัปเดตแบบไดนามิกในระบบชื่อโดเมน (DNS UPDATE) " มาตรฐานที่เสนอ
• RFC  2181 – " คำชี้แจงเพิ่มเติมเกี่ยวกับข้อกำหนด DNS " มาตรฐานที่เสนอ
• RFC  2308 – " การแคชเชิงลบของการสอบถาม DNS (DNS NCACHE) " มาตรฐานที่เสนอ
• RFC  3225 – " การระบุการสนับสนุน DNSSEC ของตัวแก้ไข DNS " มาตรฐานที่เสนอ
• RFC  3226 – " ข้อกำหนดขนาดข้อความของเซิร์ฟเวอร์/ตัวแก้ไขที่รองรับ DNSSEC และ IPv6 A6 " มาตรฐานที่เสนอ
• RFC  3596 – " ส่วนขยาย DNS เพื่อรองรับ IP เวอร์ชัน 6 " มาตรฐานอินเทอร์เน็ต 88
• RFC  3597 – " การจัดการกับประเภทระเบียนทรัพยากร DNS (RR) ที่ไม่รู้จัก " มาตรฐานที่เสนอ
• RFC  4343 – " การชี้แจงเกี่ยวกับการไม่คำนึงถึงตัวพิมพ์ใหญ่เล็กของระบบชื่อโดเมน (DNS) " มาตรฐานที่เสนอ
• RFC  4592 – " บทบาทของไวลด์การ์ดในระบบชื่อโดเมน " มาตรฐานที่เสนอ
• RFC  5001 – " ตัวเลือกตัวระบุชื่อเซิร์ฟเวอร์ DNS (NSID) " มาตรฐานที่เสนอ
• RFC  5011 – " การอัปเดตอัตโนมัติของจุดยึดความเชื่อถือด้านความปลอดภัยของ DNS (DNSSEC) " มาตรฐานอินเทอร์เน็ต 74
• RFC  5452 – " มาตรการเพื่อทำให้ DNS มีความยืดหยุ่นมากขึ้นต่อคำตอบปลอม " มาตรฐานที่เสนอ
• RFC  5890 – " ชื่อโดเมนสากลสำหรับแอปพลิเคชัน (IDNA): คำจำกัดความและกรอบเอกสาร " มาตรฐานที่เสนอ
• RFC  5891 – " ชื่อโดเมนสากลในแอปพลิเคชัน (IDNA): โปรโตคอล " มาตรฐานที่เสนอ
• RFC  5892 – " มาตรฐานที่เสนอสำหรับรหัสยูนิโคดและชื่อโดเมนสากลสำหรับแอปพลิเคชัน (IDNA) "
• RFC  5893 – " สคริปต์จากขวาไปซ้ายสำหรับชื่อโดเมนสากลสำหรับแอปพลิเคชัน (IDNA) " มาตรฐานที่เสนอ
• RFC  6672 – " การเปลี่ยนเส้นทาง DNAME ใน DNS " มาตรฐานที่เสนอ
• RFC  6891 – " กลไกส่วนขยายสำหรับ DNS (EDNS(0)) " มาตรฐานอินเทอร์เน็ต 75
• RFC  7766 – " การส่งข้อมูล DNS ผ่าน TCP - ข้อกำหนดการใช้งาน " มาตรฐานที่เสนอ
• RFC  8490 – " การดำเนินการที่มีสถานะของ DNS " มาตรฐานที่เสนอ
• RFC  8945 – " การตรวจสอบความถูกต้องของธุรกรรมด้วยคีย์ลับสำหรับ DNS (TSIG) " มาตรฐานอินเทอร์เน็ต 93
• RFC  9103 – " การถ่ายโอนโซน DNS ผ่าน TLS " มาตรฐานที่เสนอ
• RFC  9156 – " การลดขนาดชื่อการสืบค้น DNS เพื่อปรับปรุงความเป็นส่วนตัว " มาตรฐานที่เสนอ

• RFC  4033 – " บทนำและข้อกำหนดด้านความปลอดภัยของ DNS " มาตรฐานที่เสนอ
• RFC  4034 – " ระเบียนทรัพยากรสำหรับส่วนขยายความปลอดภัยของ DNS " มาตรฐานที่เสนอ
• RFC  4035 – " การปรับเปลี่ยนโปรโตคอลสำหรับส่วนขยายความปลอดภัยของ DNS " มาตรฐานที่เสนอ
• RFC  4470 – " การครอบคลุมขั้นต่ำของระเบียน NSEC และการลงนามออนไลน์ DNSSEC " มาตรฐานที่เสนอ
• RFC  4509 – " การใช้ SHA-256 ในระเบียนทรัพยากรผู้ลงนามการมอบหมาย (DS) ของ DNSSEC " มาตรฐานที่เสนอ
• RFC  5155 – " การปฏิเสธการมีอยู่แบบแฮชที่ตรวจสอบความถูกต้องแล้วของ DNS Security (DNSSEC) " มาตรฐานที่เสนอ
• RFC  5702 – " การใช้อัลกอริธึม SHA-2 ร่วมกับ RSA ในระเบียนทรัพยากร DNSKEY และ RRSIG สำหรับ DNSSEC " มาตรฐานที่เสนอ
• RFC  5910 – " การแมปส่วนขยายความปลอดภัยของระบบชื่อโดเมน (DNS) สำหรับโปรโตคอลการจัดเตรียมที่ขยายได้ (EPP) " มาตรฐานที่เสนอ
• RFC  5933 – " การใช้อัลกอริธึมลายเซ็น GOST ในระเบียนทรัพยากร DNSKEY และ RRSIG สำหรับ DNSSEC " สถานะ เดิมถูกเปลี่ยนเป็นสถานะเดิมในปี 2024 โดยRFC  9558และได้รับการปรับปรุงโดยRFC  6944 (ดูในหัวข้อ RFC เชิงข้อมูล)
• RFC  7830 – " ตัวเลือกการเติม EDNS(0) " มาตรฐานที่เสนอ
• RFC  7858 – " ข้อกำหนดสำหรับ DNS ผ่านการรักษาความปลอดภัยระดับชั้นการขนส่ง (TLS) " มาตรฐานที่เสนอ
• RFC  8310 – " รูปแบบการใช้งานสำหรับ DNS ผ่าน TLS และ DNS ผ่าน DTLS " มาตรฐานที่เสนอ
• RFC  8484 – " การสอบถาม DNS ผ่าน HTTPS (DoH) " มาตรฐานที่เสนอ

• RFC  1183 – " คำจำกัดความ RR ของ DNS ใหม่ " ทดลองใช้งาน

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

RFC เหล่านี้มีลักษณะเป็นคำแนะนำ แต่อาจให้ข้อมูลที่เป็นประโยชน์แม้ว่าจะไม่ได้กำหนดมาตรฐานหรือ BCP ก็ตาม^{[ 1 ]}

• RFC  1178 – " การเลือกชื่อสำหรับคอมพิวเตอร์ของคุณ " ข้อมูลทั่วไป สำหรับข้อมูลของคุณ 5.
• RFC  1591 – " โครงสร้างและการมอบหมายระบบชื่อโดเมน " ข้อมูลทั่วไป
• RFC  1912 – " ข้อผิดพลาดทั่วไปในการใช้งานและการกำหนดค่า DNS " ข้อมูลทั่วไป
• RFC  2100 – " การตั้งชื่อโฮสต์ " ข้อมูลทั่วไป
• RFC  3696 – " เทคนิคการประยุกต์ใช้สำหรับการตรวจสอบและการแปลงชื่อ " ข้อมูลทั่วไป
• RFC  3833 – " การวิเคราะห์ภัยคุกคามของระบบชื่อโดเมน (DNS) " ข้อมูลทั่วไป
• RFC  4892 – " การตรวจสอบความถูกต้องทางเข้ารหัสลับ RIPv2 " ข้อมูลทั่วไป
• RFC  5894 – " ชื่อโดเมนสากลสำหรับแอปพลิเคชัน (IDNA): ข้อมูลเบื้องต้น คำอธิบาย และเหตุผล " ข้อมูลทั่วไป
• RFC  5895 – " การแมปอักขระสำหรับชื่อโดเมนสากลในแอปพลิเคชัน (IDNA) 2008 " ข้อมูลทั่วไป
• RFC  8806 – " การเรียกใช้ Root Server ในพื้นที่เดียวกับ Resolver " ข้อมูลทั่วไป
• RFC  9076 – " ข้อควรพิจารณาด้านความเป็นส่วนตัวของ DNS " ข้อมูลทั่วไป
• RFC  9558 – " การใช้อัลกอริธึมลายเซ็น GOST 2012 ในระเบียนทรัพยากร DNSKEY และ RRSIG สำหรับ DNSSEC " ข้อมูลทั่วไป

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

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

Wikiversity มีแหล่งข้อมูลการเรียนรู้เกี่ยวกับระบบชื่อโดเมน

• Vixie, Paul (4 พฤษภาคม 2007). "ความซับซ้อนของ DNS" . ACM Queue . เก็บถาวรจากต้นฉบับเมื่อ 29 มีนาคม 2023.
• บอลล์, เจมส์ (28 กุมภาพันธ์ 2014). "พบกับเจ็ดบุคคลผู้กุมกุญแจสำคัญสู่ความปลอดภัยทางอินเทอร์เน็ตทั่วโลก"เดอะการ์เดียน . การ์เดียน นิวส์ แอนด์ มีเดีย จำกัด. สืบค้นเมื่อ28 กุมภาพันธ์ 2014 .
• Kruger, Lennard G. (18 พฤศจิกายน 2016). "การกำกับดูแลอินเทอร์เน็ตและระบบชื่อโดเมน: ประเด็นสำหรับรัฐสภา" (PDF) . สำนักงานวิจัยรัฐสภา. สืบค้นเมื่อ27 กรกฎาคม 2024 .
• Zytrax.comคู่มือโอเพนซอร์ส – DNS สำหรับนักวิทยาศาสตร์จรวด
• ลองปรับแต่ง DNS – เว็บไซต์ที่คุณสามารถทดลองกับการตั้งค่า DNS ได้