การที่ DNS สาธารณะของ Google แปลค่าโดเมนไม่ได้ มักจะเกิดจากปัญหาในโดเมนนั้นหรือเนมเซิร์ฟเวอร์ที่เชื่อถือได้ ขั้นตอนต่อไปนี้จะช่วยระบุสาเหตุของปัญหาได้ และผู้ดูแลระบบโดเมนจะสามารถแก้ปัญหาดังกล่าวด้วยตนเอง
ก่อนจะเริ่มขั้นตอนเหล่านี้ ให้ตรวจสอบโดเมนที่ dns.google ตามที่อธิบายไว้ในหน้าการแก้ปัญหาทั่วไป ซึ่งอาจนําคุณไปยังขั้นตอนการวินิจฉัยที่เฉพาะเจาะจงด้านล่าง หรือลองทําตามขั้นตอนต่อไปนี้ทั้งหมดจนกว่าจะพบสาเหตุ
ขั้นตอนที่ 1: ตรวจสอบปัญหาการตรวจสอบ DNSSEC
หากการค้นหาเว็บ dns.google สําหรับโดเมนแสดง "Status": 2 (SERVFAIL) และการค้นหาที่ไม่มี DNSSEC สําเร็จ อาจมีปัญหา DNSSSEC กับเนมเซิร์ฟเวอร์หรือรีจิสทรีของโดเมน (TLD) ของโดเมนนั้นๆ (ซึ่งเผยแพร่ระเบียน DS สําหรับการตรวจสอบ DNSSEC ของโดเมนที่ลงทะเบียน)
- การเปลี่ยนแปลงในผู้รับจดทะเบียนหรือบริการ DNS
ปัญหา DNSSEC อาจเกิดขึ้นได้หลังจากโดเมนเปลี่ยนจากผู้รับจดทะเบียนหรือบริการ DNS ที่รองรับ DNSSEC ไปใช้โดเมนที่ไม่รองรับ #39 หากบริการก่อนหน้านี้ไม่เก็บระเบียน
DSที่ไม่มีอัปเดตในรีจิสทรี TLD และบริการใหม่จะไม่สร้างระเบียนDNSKEYใหม่ที่มีระเบียนDSตรงกันในรีจิสทรี TLD การตรวจสอบความถูกต้องของรีโซลเวอร์ เช่น Google DNS สาธารณะจะไม่สามารถแปลค่าโดเมนได้หากเกิดปัญหานี้ โปรดขอให้ผู้รับจดทะเบียนโดเมนนําระเบียน DS เก่าออกจากรีจิสทรี TLD
- การตอบกลับ DNSSEC มีขนาดใหญ่เกินไป
อีกสาเหตุหนึ่งของปัญหา DNSSEC อาจเป็นการตอบสนอง DNSSEC ที่มีขนาดใหญ่เกินไปที่จะใส่ไว้ในแพ็กเก็ต IP หนึ่งแพ็กเก็ต ซึ่งทําให้เกิดการตอบกลับที่กระจัดกระจาย หาก DNSViz แสดง "ไม่ได้รับการตอบสนองจนกว่าขนาดเพย์โหลด UDP จะลดลง" ข้อผิดพลาด ความล้มเหลวของ DNSSEC อาจเกิดจากการตอบกลับขนาดใหญ่มาก คุณลดขนาดการตอบกลับได้โดยใช้การดําเนินการต่อไปนี้อย่างน้อย 1 รายการ
- กําหนดค่า "คําตอบที่สั้นที่สุด" สําหรับเนมเซิร์ฟเวอร์ที่เชื่อถือได้
- ลดจํานวนระเบียน
DNSKEYที่ใช้งานอยู่ให้เหลือ 2 หรือ 3 รายการ - ใช้ระเบียน
DNSKEY1280 หรือ 2048 บิต (RFC 6781, StackExchange) - เปลี่ยนจากลายเซ็น RSA เป็นลายเซ็น ECDSA ขนาดเล็ก (RFC 8624)
รวมทั้งตรวจสอบปัญหา DNSSEC อื่นๆ ที่เครื่องมือรายงานในขั้นตอนที่ 2 ด้วย ตัวอย่างเช่น ระเบียนการปฏิเสธการปฏิเสธ NSEC หรือ NSEC3 ที่พิสูจน์ว่าไม่มีโดเมนย่อย (PowerDNS ที่มีโซนที่จัดเก็บไว้ในฐานข้อมูลภายนอกอาจมีลายเซ็นเหล่านี้) หรือลายเซ็น RRSIG ที่หมดอายุ (โดยกระบวนการลงชื่อกําหนดค่าด้วยตนเอง)
ขั้นตอนที่ 2: ตรวจสอบเนมเซิร์ฟเวอร์ที่เชื่อถือได้
หาก DNS สาธารณะของ Google (หรือรีโซลเวอร์แบบเปิด) มีปัญหาเกี่ยวกับการแก้ไขโดเมน DNSViz จะแสดงปัญหาเกี่ยวกับโดเมนและเนมเซิร์ฟเวอร์ที่ก่อให้เกิดปัญหาดังกล่าว ไปที่หน้าเว็บ DNSViz แล้วป้อนชื่อโดเมนที่มีปัญหา หาก DNSViz ไม่มีข้อมูลย้อนหลังหรือมีเฉพาะข้อมูลที่เก่ากว่า 1 วัน (เช่น ที่แสดงในหน้านี้) ให้คลิกปุ่มวิเคราะห์ขนาดใหญ่เพื่อให้แสดงปุ่มวิเคราะห์เล็กๆ ด้านล่าง (หากไม่ปรากฏอยู่แล้ว) และคลิกข้อมูลนั้นด้วย เมื่อการวิเคราะห์เสร็จสมบูรณ์ ให้คลิก&การเสนอราคา{0}ต่อไป" เพื่อแสดงผลลัพธ์ คลิกข้อผิดพลาดสีแดงและคําเตือนสีเหลืองในแถบด้านซ้ายเพื่อแสดงรายละเอียด หรือกดปุ่มตัวชี้เหนือวัตถุในไดอะแกรมเพื่อแสดงข้อมูลนั้นในบริบท
หากการวินิจฉัยก่อนหน้านี้ระบุว่าอาจเกิดปัญหา DNSSEC กับโดเมน ให้ไปที่หน้าเว็บเครื่องมือวิเคราะห์ DNSSEC แล้วกรอกชื่อโดเมน หากเครื่องมือวิเคราะห์นี้รายงานข้อผิดพลาดหรือคําเตือน DNSSEC
ให้ชี้เมาส์ไปที่ไอคอน
หน้าเว็บ intoDNS จะรายงานปัญหาที่ไม่ใช่ของ DNSSEC กับโดเมนที่ป้อนไว้ในหน้าหลัก และจะแสดงคําแนะนําในการแก้ไขปัญหาดังกล่าว
ผู้ดูแลระบบโดเมนควรแก้ไขข้อผิดพลาดส่วนใหญ่ของเครื่องมือเหล่านี้ เนื่องจากอาจทําให้เกิดปัญหาที่ไม่เพียงสําหรับ DNS สาธารณะของ Google แต่ยังรวมถึงรีโซลเวอร์อื่นๆ ด้วย
ขั้นตอนที่ 3: ตรวจสอบปัญหาการมอบสิทธิ์
DNS สาธารณะของ Google เป็นรีโซลเวอร์ที่มีหลักพื้นฐาน "&;; ใช้เฉพาะเนมเซิร์ฟเวอร์ที่แสดงผลเมื่ออ้างอิงจากโดเมนระดับบนเท่านั้น หากชื่อเนมเซิร์ฟเวอร์และที่อยู่ Glue ใน TLD เก่าเกินไปหรือไม่ถูกต้อง อาจทําให้เกิดปัญหาในการมอบสิทธิ์ได้
หากรายงาน DNSViz หรือ DNS แสดงคําเตือนเกี่ยวกับความไม่สอดคล้องกันระหว่างเนมเซิร์ฟเวอร์ที่ได้รับมอบสิทธิ์ใน TLD และเนมเซิร์ฟเวอร์ที่อยู่ในโดเมนย่อยเอง คุณอาจต้องแก้ไข DNS ดังกล่าวก่อน DNS สาธารณะของ Google จึงจะแก้ปัญหาโดเมนได้ หากเครื่องมือเหล่านี้รายงานว่าไม่มีโดเมนที่จดทะเบียน (NXDOMAIN) ให้ตรวจสอบว่าโดเมนยังไม่หมดอายุหรือถูกระงับการจดทะเบียนไม่ว่าด้วยเหตุผลใดก็ตาม
ปัญหาการมอบสิทธิ์อาจเกิดจากการไม่แก้ไขชื่อเนมเซิร์ฟเวอร์สําหรับโดเมน ตรวจสอบระเบียน A และ AAAA สําหรับเนมเซิร์ฟเวอร์ใน dns.google เพื่อดูว่าเนมเซิร์ฟเวอร์มีโดเมน ##39 หรือไม่
ขั้นตอนที่ 4: ตรวจหาการตอบกลับขนาดใหญ่
DNS ต้องใช้ UDP ในการรับส่งข้อมูลส่วนใหญ่ แผนภูมิข้อมูล UDP ขนาดใหญ่ต้องกระจัดกระจายและทําให้ UDP กระจัดกระจายเนื่องจากมีการแสดงโฆษณาที่ไม่น่าเชื่อถือ จุดนี้เป็นจุดมุ่งเน้นของ DNS Flag Day 2020 ซึ่งเป็นความพยายามที่จะเพิ่มความน่าเชื่อถือของ DNS ทั่วโลก DNS สาธารณะของ Google มีส่วนร่วมในความพยายามนี้ และจํากัดขนาดของการตอบกลับ UDP ที่เซิร์ฟเวอร์ยอมรับผ่าน UDP ลองใช้คําค้นหาที่คล้ายกับตัวอย่างด้านล่างด้วยพรอมต์คําสั่งของคุณเองหรือ Google Cloud Shell
$ dig +short example.com NS ns1.example.com ns2.example.com $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY ...
ข้อความค้นหาสําหรับระเบียนประเภทต่างๆ เหล่านี้จะระบุสิ่งต่อไปนี้
+dnssec- เปิดใช้ DNSSEC โดยเฉพาะการส่งคืนระเบียนที่จําเป็นสําหรับการตรวจสอบ DNSSEC เมื่อพร้อมใช้งาน ซึ่งจะขยายขนาดของผลการค้นหาได้อย่างมาก การดําเนินการนี้จะจําลองพฤติกรรม DNS สาธารณะของ Google'
+bufsize=1400- จํากัดขนาดบัฟเฟอร์ UDP ที่อนุญาต สิ่งนี้เลียนแบบลักษณะการทํางานของ DNS สาธารณะของ Google' ซึ่งเป็นความพยายามของ DNS Flag Day 2020
+timeout=1- ตั้งค่าระยะหมดเวลาเป็น 1 วินาที การดําเนินการนี้จะจําลองพฤติกรรม DNS สาธารณะของ Google'
@ns1.example.com- เซิร์ฟเวอร์ที่เชื่อถือได้ที่จะค้นหา เก็บสัญลักษณ์
@ไว้ แต่ให้แทนที่ด้วยเซิร์ฟเวอร์ที่เชื่อถือได้ของคุณเอง ดังที่แสดงในคําสั่งแรก
สังเกตเอาต์พุต เห็นบรรทัดดังนี้
;; Truncated, retrying in TCP mode.- สิ่งนี้บ่งชี้ว่าการตอบสนองมีขนาดใหญ่กว่าขนาดบัฟเฟอร์ UDP ที่ขอ ระบบจึงตัดข้อความตอบกลับแล้ว และเพื่อตอบสนองต่อไคลเอ็นต์ที่เปลี่ยนไปใช้ TCP เซิร์ฟเวอร์ที่เชื่อถือได้ควรรองรับการรับส่งข้อมูล DNS ในพอร์ต 53 ของ TCP (ดู RFC 7766 ที่จําเป็น "การใช้งานต้องรองรับทั้งการรับส่งข้อมูล UDP และ TCP".)
;; MSG SIZE rcvd: 2198- หากมีหมายเลขมากกว่า 1,400 ซึ่งระบุอีกครั้งว่ามีการตอบกลับขนาดใหญ่
;; Query time: 727 msec- หากมีหมายเลขมากกว่า 500 Google Public DNS อาจทิ้งการตอบกลับที่ช้า (โดยเฉพาะการตอบกลับที่อยู่ใกล้หรือเกิน 1 วินาที) ซึ่งมักจะเป็นเช่นนี้หากมีผู้ใช้เวลา เพื่อพยายามเข้าถึง UDP และตามมาด้วยการพยายามใช้ TCP สถานที่ตั้งทางภูมิศาสตร์ของเซิร์ฟเวอร์และไคลเอ็นต์มีผลอย่างมากต่อเวลาในการตอบสนอง
;; connection timed out; no servers could be reached- โดยเฉพาะในกรณีที่มีคําถามบางรายการ กรณีนี้จะระบุปัญหาที่เซิร์ฟเวอร์ตอบคําถาม DNS ไม่ได้ทันท่วงที
คุณสามารถลองใช้รูปแบบต่างๆ ต่อไปนี้
- กําลังเพิ่มพารามิเตอร์
+tcp - การดําเนินการนี้จะบังคับให้
digใช้ TCP ทันที คุณตรวจสอบได้ว่าเซิร์ฟเวอร์ที่เชื่อถือได้จัดการคําค้นหา TCP โดยตรงด้วยวิธีนี้หรือไม่ - กําลังนําพารามิเตอร์
+bufsize=1400ออก - การดําเนินการนี้จะคืนค่าพฤติกรรมเริ่มต้นของ
dig' (ตัวย่อของ 4096) หากการค้นหาของคุณล้มเหลวกับการตั้งค่านี้ แต่ทํางานได้โดยไม่มีคําแนะนําดังกล่าว หมายความว่าเซิร์ฟเวอร์ของคุณไม่สามารถรองรับ TCP เฟลโอเวอร์ได้เป็นอย่างดี การพึ่งพา UDP เพื่อดําเนินการตอบกลับขนาดใหญ่อาจใช้งานได้ในบางครั้งเท่านั้น การดําเนินการที่ดีที่สุดคือการรองรับการส่งผ่าน TCP สําหรับ DNS - การทําซ้ําที่เนมเซิร์ฟเวอร์แต่ละรายการ
- ตัวอย่างข้างต้นมีเนมเซิร์ฟเวอร์ที่เชื่อถือได้ 2 รายการ (
ns1และns2) ปัญหาบางอย่างอาจเกิดจากเซิร์ฟเวอร์ที่ต่างกันแสดงคําตอบที่แตกต่างกัน ตรวจสอบว่าทุกคนตอบคําถามได้สอดคล้องกันโดยใช้คําค้นหาเดียวกันซ้ําในเซิร์ฟเวอร์ที่เชื่อถือได้ทั้งหมด
หากคําค้นหาทั้งหมดเป็นคําตอบเล็กๆ น้อยๆ (ไม่เกิน 1,400 ไบต์) เร็ว (ควรเป็น 500 มิลลิวินาทีขึ้นไป) และเชื่อถือได้ (ทํางานอย่างต่อเนื่องผ่าน TCP และ UDP) คุณไม่จําเป็นต้องกังวลเรื่องขนาดการตอบสนอง โปรดอ่านส่วนการแก้ปัญหาอื่นๆ ถึงแม้คําตอบจะเป็นไปอย่างรวดเร็ว แต่การค้นหาจากพื้นที่ทางภูมิศาสตร์ที่ห่างไกลก็อาจช้ากว่าปกติ
หากการตรวจสอบเหล่านี้ล้มเหลว (ขนาดใหญ่หรือช้าหรือไม่เสถียร) การดําเนินการหลักคือ ก) ตรวจสอบว่าเซิร์ฟเวอร์ของคุณตอบสนองด้วยการตัด UDP เมื่อการตอบสนองเกินขนาดบัฟเฟอร์ UDP ที่ขอ และ ข) เซิร์ฟเวอร์สามารถจัดการการสอบถาม TCP ใหม่ซึ่งจะเกิดขึ้นหลังจากนั้น เครื่องมือหลายรายการช่วยคุณวินิจฉัย ปัญหาความน่าเชื่อถือของ DNS ได้ดังนี้
- DNSViz
- โปรแกรมแก้ไขข้อบกพร่อง DNSSEC
- ผู้ทดสอบการปฏิบัติตามข้อกําหนดของ EDNS
- เครื่องมือตรวจสอบ DNS -- อย่าลืมยกเลิกการเลือกช่อง "CD" (ปิดใช้การตรวจสอบ DNSSEC)
หากเครื่องมือหรือเครื่องมือดังกล่าวแสดงข้อผิดพลาดหรือคําเตือนใดๆ โปรดแก้ไขปัญหาดังกล่าว โปรดอ่านคําแนะนําในการแก้ปัญหาอื่นๆ ทั้งหมดในเว็บไซต์นี้
ขั้นตอนที่ 5: ตรวจสอบว่ารีโซลเวอร์สาธารณะอื่นแก้ไขโดเมนหรือไม่
หากไม่พบสาเหตุของปัญหาหลังจากทําตามขั้นตอนข้างต้น ให้เรียกใช้คําสั่งต่อไปนี้ที่ Command Prompt โดยแทนที่ example.test. ด้วยโดเมนที่เป็นปัญหา (และเก็บจุดต่อท้ายไว้)
Windows
nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.
macOS หรือ Linux
dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'
คําสั่งเหล่านี้จะใช้รีโซลเวอร์ DNS ของ OpenDNS, Quad9 และ Cloudflare 1.1.1.1 ถ้าคุณได้รับความล้มเหลวจากทั้ง 2 อย่างนี้ รวมถึง DNS สาธารณะของ Google แสดงว่าปัญหาอาจเกิดจากโดเมนหรือเนมเซิร์ฟเวอร์
หากคุณได้รับผลลัพธ์ที่สําเร็จจากรีโซลเวอร์สาธารณะอื่นๆ มากกว่า 1 รายการ แสดงว่า DNS สาธารณะของ Google อาจมีปัญหา หากไม่มีการรายงานปัญหาที่คล้ายกันสําหรับโดเมน (หรือ TLD) ในเครื่องมือติดตามปัญหา คุณควรรายงานปัญหาให้เราทราบ รวมถึงเอาต์พุตคําสั่ง และข้อความในหน้าการวินิจฉัย หรือภาพหน้าจอในรายงาน