เป็นความจริงหรือไม่ที่เนมเซิร์ฟเวอร์จำเป็นต้องตอบแบบสอบถามผ่าน TCP

ฉันกำลังดำเนินการตั้งค่าการตรวจสอบเซิร์ฟเวอร์ DNS ของโฮสต์เว็บขนาดใหญ่หลายแห่ง เป้าหมายของฉันคือการเปรียบเทียบเวลาตอบสนองของเซิร์ฟเวอร์ dns ด้วยการติดตามการตอบสนองต่อ ping

ในกระบวนการฉันพบว่าเซิร์ฟเวอร์ชื่อ Bluehost ไม่ตอบสนองต่อการ ping ฉันพยายามรับข้อมูลเพิ่มเติมโดยเรียกใช้Pingdom DNS Check บน bluehost.comและทำให้เกิดข้อผิดพลาดต่อไปนี้:

เซิร์ฟเวอร์ชื่อ ns1.bluehost.com (74.220.195.31) ไม่ตอบแบบสอบถามผ่าน TCP

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

ฉันต้องการทราบสิ่งต่อไปนี้:

• ข้อความข้างต้นเป็นจริงในระดับใด?
• อะไรคือความหมายของเนมเซิร์ฟเวอร์ที่ไม่ตอบแบบสอบถามผ่าน TCP?

ข้อความวินิจฉัยจาก Pingdom นั้นถูกต้องอย่างแน่นอน TCP ไม่ได้มีไว้สำหรับถ่ายโอนโซนเท่านั้น

การใช้งานเซิร์ฟเวอร์ DNS ที่กำลังตอนนี้ "ต้อง" (ในให้มากที่สุดเท่า RFC ใด ๆ ต้องมีอะไร) เพื่อสนับสนุน TCP ต่อRFC 5966 "DNS ขนส่งผ่าน TCP - ต้องการการใช้งาน"

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

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

ข้อจำกัดความรับผิดชอบ ob: ฉันเขียน RFC นั้น

EDIT RFC 5966 ได้ถูกแทนที่ด้วยRFC 7766

ควรสนับสนุน TCP และ UDP - TCP สำหรับการตอบสนองขนาด> 512 ไบต์ (ซึ่งจะรวมถึงการถ่ายโอนโซน) (ตามสิ่งที่ฉันได้อ่านต่อไปฉันมักจะเปิดใช้งาน TCP และ UDP สำหรับ NS ที่ฉันเรียกใช้ ...

เป็นการดีที่จะทราบว่า RFCs พูดอะไรเกี่ยวกับเรื่องนี้และเรามีคำตอบที่มีสิทธิ์ดีอยู่แล้ว แต่สำหรับวัตถุประสงค์ในทางปฏิบัติฉันพบคำแนะนำจากศาสตราจารย์ Daniel J. Bernstein ปริญญาเอกผู้เขียน DJBDNS ค่อนข้างสนุกสนาน

http://cr.yp.to/djbdns/tcp.html#why (2003-01-16)

คิวรี TCP จะถูกส่งเมื่อใด

หากคุณอยู่ในสถานการณ์ใดสถานการณ์หนึ่งต่อไปนี้คุณต้องกำหนดค่าเซิร์ฟเวอร์ DNS ของคุณเพื่อตอบแบบสอบถาม TCP:

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

หากคุณไม่ได้อยู่ในสถานการณ์เหล่านั้นคุณไม่จำเป็นต้องให้บริการ TCP และคุณไม่ควรตั้งค่า DNS-over-TCP ช้ากว่า DNS-over-UDP มากและมีความเสี่ยงที่จะถูกปฏิเสธการให้บริการ (สิ่งนี้ใช้กับ BIND ด้วย)

โปรดทราบว่าเขาไม่กล่าวถึง DNSSEC อย่างชัดเจน สาเหตุที่เป็นเช่นนั้นตามที่ DJB ระบุว่า DNSSEC อยู่ในหมวด "ความผิดพลาดเสมอ" ดูhttps://cr.yp.to/djbdns/forgery.htmlสำหรับรายละเอียดเพิ่มเติม DJB มีมาตรฐานทางเลือกที่เรียกว่า DNSCurve - http://dnscurve.org/ - ซึ่งได้รับการรับรองจากผู้ให้บริการบางรายแล้ว (เช่น OpenDNS) ที่น่าสนใจ: /security/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption

โปรดทราบว่าหากเอกสารข้างต้นเกี่ยวกับการตั้งค่า DJBDNS เป็นการบ่งชี้ถึงคุณลักษณะใด ๆ ของมันปรากฏว่ารองรับเฉพาะ AXFR สำหรับ TCP เนื่องจากผู้ให้บริการหลายรายยังคงใช้ DJBDNS จึงไม่น่าสนับสนุน DNS ผ่าน TCP โดยไม่ต้องใช้ความพยายามเป็นพิเศษ

PS Note ที่จริง ๆ แล้ว DJB ทำสิ่งที่เขาสอน เซิร์ฟเวอร์ของเขา (1) รัน DNSCurve (2) ไม่ตอบรับ TCP อย่างถูกต้อง +notcpจะประสบความสำเร็จเท่านั้น(ซึ่งเป็นค่าเริ่มต้น):

% dig +trace @ordns.he.net +notcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to.
yp.to.                  86400   IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 151 ms

cr.yp.to.               600     IN      A       131.155.70.11
cr.yp.to.               600     IN      A       131.155.70.13
yp.to.                  3600    IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
yp.to.                  3600    IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.yp.to.
;; Received 244 bytes from 131.155.70.13#53(uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to) in 14 ms

ในขณะที่ a +tcpจะล้มเหลว (เห็นได้ชัดว่ามีข้อผิดพลาดที่แตกต่างกันขึ้นอยู่กับเซิร์ฟเวอร์ที่เขาเลือก):

% dig +trace @ordns.he.net +tcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 150 ms

;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.193.32.147#53: end of file
;; connection timed out; no servers could be reached

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

ด้วยการแนะนำคำตอบ DNS ที่ลงชื่อแล้วมีข้อกำหนดสำหรับการคลายข้อ จำกัด 512 ไบต์สำหรับคำตอบ UPD EDNS0 จัดเตรียมกลไกสำหรับการตอบสนอง UDP ที่ยาวนานขึ้น ความล้มเหลวในการอนุญาต DNS ผ่าน TCP มีแนวโน้มสูงที่จะทำลายการใช้งาน DNS ที่ปลอดภัย

เป็นไปได้อย่างสมบูรณ์ในการใช้งานเซิร์ฟเวอร์ DNS ซึ่งเปิดพอร์ต UDP 53 ไว้บนอินเทอร์เน็ตเท่านั้น จำเป็นต้องมีการเข้าถึง TCP กับ DNS เพียร์ แต่นี่เป็นรายการโฮสต์ขนาดเล็ก

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

มีการพูดคุยกันถึงการใช้ TCP เพื่อป้องกันการโจมตีของ DNS TCP มีการปฏิเสธความเสี่ยงในการให้บริการของตนเอง แต่การกระจายนั้นยาก