RFC ที่ต้องการเซิร์ฟเวอร์ DNS เพื่อตอบสนองต่อคำขอโดเมนที่ไม่รู้จัก

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

dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached

ในการสำรวจบริการชื่อโดเมนยอดนิยมอื่น ๆ ฉันเห็นว่าพฤติกรรมนี้ไม่เหมือนใครเนื่องจากผู้ให้บริการรายอื่นคืน RCODE เป็น 5 (อ้างอิง):

dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org
dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org
dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org

ทุกอย่างกลับมาเหมือนดังต่อไปนี้:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732

หรือ

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219

การส่งคืนREFUSEDหรือNXDOMAINทันทีคือ IMHO ที่เหมาะสมซึ่งตรงข้ามกับการส่งคำขอในชั้นห้องเซิร์ฟเวอร์

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

คำถาม :

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

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

ในRFC 1536และ2308ฉันเห็นข้อมูลจำนวนมากเกี่ยวกับการแคชเชิงลบด้วยเหตุผลด้านประสิทธิภาพและเพื่อหยุดการส่งสัญญาณซ้ำของแบบสอบถามเดียวกัน ใน4074ฉันเห็นข้อมูลเกี่ยวกับการส่งคืนคำตอบที่ว่างเปล่าด้วย RCODE เป็น 0 เพื่อให้ลูกค้ารู้ว่าไม่มีข้อมูล ipv6 ซึ่งควรทำให้ลูกค้าถามเกี่ยวกับ A RR ซึ่งเป็นอีกตัวอย่างหนึ่งของการตอบกลับที่ว่างเปล่า

แต่ฉันไม่พบ RFC ที่บอกว่าเซิร์ฟเวอร์ DNS ควรตอบคำขออาจเป็นเพราะมันบอกเป็นนัย

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

ขอบคุณสำหรับความช่วยเหลือ

แก้ไข:

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

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

ที่กล่าวมานี้ยังคงเป็นคำถามที่น่าสนใจที่จะตอบดังนั้นฉันจะเอามันไป

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

ก่อนที่เราจะดำเนินการต่อมีข้อผิดพลาดอย่างใหญ่หลวงที่อยู่นอกขอบเขตของ DNS ที่ต้องถูกเรียกออก: RFCs ทั้งสองนี้มีBCP 14 (1997) ลงวันที่ก่อนวันจริงเอกสารที่ชี้แจงภาษาของ MAY, MUST, SHOULD เป็นต้น

• มาตรฐานที่ถูกเขียนขึ้นก่อนที่ภาษานี้จะทำเป็นกรงอาจใช้ภาษาที่ชัดเจน แต่ในหลายกรณีไม่ได้ สิ่งนี้นำไปสู่การใช้งานซอฟต์แวร์ที่แตกต่างสับสนจำนวนมากและอื่น ๆ
• STD 13 น่าเสียดายที่มีความผิดในการตีความในหลาย ๆ ด้าน หากภาษาไม่มั่นคงในพื้นที่ของการดำเนินงานมันเป็นสิ่งจำเป็นบ่อยครั้งที่จะหา RFC ชี้แจง

ถ้าอย่างนั้นเรามาเริ่มกันที่RFC 1034 §4.3.1กันนะ:

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

...

หากไม่ได้ร้องขอบริการเรียกซ้ำหรือไม่พร้อมใช้งานการตอบกลับแบบเรียกซ้ำจะเป็นหนึ่งในสิ่งต่อไปนี้:

• ข้อผิดพลาดเกี่ยวกับชื่อที่เชื่อถือได้ซึ่งระบุว่าไม่มีชื่อ

• ข้อบ่งชี้ข้อผิดพลาดชั่วคราว

• การรวมกันของ:

  RR ที่ตอบคำถามพร้อมกับข้อบ่งชี้ว่าข้อมูลมาจากโซนหรือแคช

  การอ้างอิงไปยังเซิร์ฟเวอร์ชื่อที่มีโซนซึ่งอยู่ใกล้กับบรรพบุรุษมากกว่าชื่อเซิร์ฟเวอร์ที่ส่งการตอบกลับ

• RR ที่เนมเซิร์ฟเวอร์คิดว่าจะพิสูจน์ได้ว่าเป็นประโยชน์ต่อผู้ร้องขอ

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

เมื่อพิจารณาถึงบทบาทของ DNS ในสถานการณ์ที่ไม่เหมาะสมของเครือข่ายอย่าบอกว่าซอฟต์แวร์เซิร์ฟเวอร์ DNS ไม่ได้ให้ปุ่มเลือกที่จะลดทราฟฟิกลงบนพื้นซึ่งในทางเทคนิคแล้วจะเป็นการละเมิดนี้ ที่กล่าวว่าสิ่งเหล่านี้ไม่ใช่พฤติกรรมเริ่มต้นหรือด้วยค่าเริ่มต้นที่เข้มงวดมาก ตัวอย่างของทั้งคู่จะเป็นผู้ใช้ที่ต้องการให้ซอฟต์แวร์วางชื่อเฉพาะ ( rpz-drop.) หรือเกินขีด จำกัด ตัวเลขบางอย่าง (BIND's max-clients-per-query) เป็นเรื่องที่แทบจะไม่เคยได้ยินมาก่อนในประสบการณ์ของฉันสำหรับซอฟต์แวร์ที่จะเปลี่ยนพฤติกรรมเริ่มต้นสำหรับแพ็กเก็ตทั้งหมดในลักษณะที่เป็นการละเมิดมาตรฐานยกเว้นว่าตัวเลือกนั้นเป็นสิ่งที่เพิ่มความทนทานต่อผลิตภัณฑ์รุ่นเก่าที่ละเมิดมาตรฐาน นั่นไม่ใช่กรณีที่นี่

ในระยะสั้น RFC นี้สามารถและไม่ได้รับการละเมิดตามดุลยพินิจของผู้ประกอบการ แต่โดยปกติจะทำด้วยความแม่นยำในลักษณะบางอย่าง มันเป็นเรื่องแปลกมากที่จะสมบูรณ์ไม่สนใจในส่วนของมาตรฐานที่เป็นอยู่ที่สะดวกสบายโดยเฉพาะอย่างยิ่งเมื่อมีการลงมติเป็นเอกฉันท์มืออาชีพ (ตัวอย่าง: BCP 16 §3.3 ) errs ในความโปรดปรานของมันเป็นที่ไม่พึงประสงค์ในการสร้างภาระที่ไม่จำเป็นในระบบ DNS โดยรวม การลองที่ไม่จำเป็นจากการปล่อยคำขอทั้งหมดที่ไม่มีข้อมูลที่เชื่อถือได้มีอยู่น้อยกว่าที่ต้องการในใจ

ปรับปรุง:

เนื่องจากไม่สามารถวางแบบสอบถามบนพื้นได้อย่างแน่นอน @Alnitak ได้แชร์กับเราว่าขณะนี้มีBCP แบบร่างที่ครอบคลุมหัวข้อนี้โดยละเอียด มันค่อนข้างเร็วเกินไปที่จะใช้สิ่งนี้เป็นการอ้างอิง แต่มันช่วยเสริมแรงว่าฉันทามติของชุมชนนั้นสอดคล้องกับสิ่งที่แสดงออกมาที่นี่ โดยเฉพาะอย่างยิ่ง:

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

คำตอบนี้จะได้รับการอัพเดตเมื่อสถานะของเอกสารนี้เปลี่ยนแปลง

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

ขั้นตอนที่คุณต้องทำ:

1. ตั้งค่าทุกอย่างในผู้ให้บริการ DNS ใหม่ คุณควรสร้างและเติมทุกโซน

2. ตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ที่เชื่อถือได้ใหม่ทำงานอย่างถูกต้อง ค้นหาอย่างชัดเจน:

   dig @new-ns.example.com mydomain.com
   

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

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

3. สลับเซิร์ฟเวอร์ชื่อที่มีสิทธิ์กับผู้รับจดทะเบียนโดเมนของคุณ (whois) ทำให้ผู้ให้บริการ DNS เก่าเริ่มทำงานจนกว่าการรับส่งข้อมูลจะไม่ส่งผลกระทบต่ออีกต่อไป (ให้เวลาอย่างน้อย 24 ชั่วโมง)

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