การค้นหา DNS บางครั้งใช้เวลา 5 วินาที

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

ฉันได้เปลี่ยนไปใช้เครื่องมือแก้ปัญหาของ Google เพื่อไม่รวมความเป็นไปได้ที่คนในท้องถิ่นจะเสียดังนั้น/etc/resolv.confลักษณะของฉัน:

search my-domain.com
nameserver 8.8.4.4
nameserver 8.8.8.8

ฉันnsswitch.confมีสาย:

hosts: files dns

และฉัน/etc/hostsไม่มีสิ่งผิดปกติ

ถ้าฉันลองtelnet webserver 80มันแฮงค์หลายวินาทีก่อนที่จะได้รับการแก้ไขชื่อ ltraceส่งออก [1] แสดงให้เห็นว่าการแขวนอยู่ในgetaddrinfo()โทร:

getaddrinfo("ifconfig.me", "telnet", { AI_CANONNAME, 0, SOCK_STREAM, 0, 0, NULL, '\000', NULL }, 0x7fffb4ffc160) = 0 <5.020621>

อย่างไรก็ตามtcpdumpพบว่าเนมเซิร์ฟเวอร์ตอบกลับทันทีและเป็นเพียงการตอบกลับครั้งที่สองที่ไม่ถูกtelnetบล็อก คำตอบมีลักษณะเหมือนกัน:

05:52:58.609731 IP 192.168.1.75.43017 > 8.8.4.4.53: 54755+ A? ifconfig.me. (29)
05:52:58.609786 IP 192.168.1.75.43017 > 8.8.4.4.53: 26090+ AAAA? ifconfig.me. (29)
05:52:58.612188 IP 8.8.4.4.53 > 192.168.1.75.43017: 54755 4/0/0 A 219.94.235.40, A 133.242.129.236, A 49.212.149.105, A 49.212.202.172 (93)

[...five second pause...]

05:53:03.613811 IP 192.168.1.75.43017 > 8.8.4.4.53: 54755+ A? ifconfig.me. (29)
05:53:03.616424 IP 8.8.4.4.53 > 192.168.1.75.43017: 54755 4/0/0 A 219.94.235.40, A 133.242.129.236, A 49.212.149.105, A 49.212.202.172 (93)
05:53:03.616547 IP 192.168.1.75.43017 > 8.8.4.4.53: 26090+ AAAA? ifconfig.me. (29)
05:53:03.618907 IP 8.8.4.4.53 > 192.168.1.75.43017: 26090 0/1/0 (76)

ฉันได้ตรวจสอบบันทึกไฟร์วอลล์ของโฮสต์และไม่มีการปิดกั้นพอร์ต 53

สาเหตุใดที่การเพิกเฉยการตอบ DNS ครั้งแรก

[1] ฉันได้เพิ่มคู่สายให้ฉันltrace.confเพื่อให้ฉันสามารถมองเห็นภายในaddrinfostruct

การตอบกลับ DNS แรกไม่ได้ถูกละเว้น getaddrinfo()ไม่ได้ส่งคืนจนกว่าจะได้รับการตอบกลับไปยังคิวรี AAAA แรก (ID: 26090) ดังนั้นปัญหาที่แท้จริงที่นี่คือสาเหตุที่เครื่องของคุณไม่ได้รับการตอบสนองการสืบค้น AAAA ทันทีในขณะที่ได้รับการตอบกลับสำหรับการสอบถาม A (ID: 54755)

หนึ่งในความแตกต่างระหว่างgetaddrinfo()และgethostbyname()คืออดีตรองรับทั้ง IPv4 และ IPv6 ในขณะที่หลังรองรับเฉพาะ IPv4 ดังนั้นเมื่อคุณโทรgetaddrinfo()โดยai_familyตั้งค่าเป็น 0 ( AF_UNSPEC) จะไม่ส่งคืนจนกว่าจะได้รับการตอบกลับ (หรือหยุดพักหมดเวลา) สำหรับทั้งการสอบถาม A และ AAAA สำหรับชื่อโดเมนที่ระบุ gethostbyname()เฉพาะแบบสอบถามสำหรับระเบียน A

มันยากที่จะได้จากระยะไกลตรวจสอบสิ่งที่อาจก่อให้เกิดปัญหาของคุณได้โดยเฉพาะอย่างยิ่งที่คุณได้ตัดออกบางส่วนtcpdumpเอาท์พุท มีบางอย่างที่เลือกกรอง / วางทราฟฟิก DNS ระหว่าง VM และ DNS สาธารณะของคุณ ฉันได้ลองทำซ้ำปัญหาของคุณโดยใช้ KVM Debian Wheezy VM แต่telnet ifconfig.meเกือบจะทันทีพิมพ์Trying <IP_address_here>...บรรทัด (หมายถึงมันได้แก้ไขชื่อแล้ว)

สิ่งนี้เกิดจากชุดกฎที่เข้มงวดมากเกินไปบนไฟร์วอลล์ Juniper ที่อยู่หน้าโครงสร้างพื้นฐาน VMware

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

เพื่อนร่วมงานของฉันที่ดูแลเครือข่ายตั้งข้อสังเกตว่า

พฤติกรรมเริ่มต้นของไฟร์วอลล์จูนิเปอร์คือการปิดเซสชันที่เกี่ยวข้องกับ DNS ทันทีที่ได้รับการตอบกลับ DNS ที่ตรงกับเซสชันนั้น

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

นี่คือสารสกัดที่เกี่ยวข้องจากจูนิเปอร์ KB:

นี่เป็นสถานการณ์ที่แพ็กเก็ต DNS ตอบถูกทิ้ง:

1. เซสชันสำหรับทราฟฟิก DNS จะถูกสร้างขึ้นเมื่อแพ็กเก็ตการสืบค้น DNS แรกพบไฟร์วอลล์และมีนโยบายการอนุญาตที่กำหนดค่าไว้ การหมดเวลาเริ่มต้นคือ 60 วินาที
2. ทันทีก่อนที่เซสชั่นจะถูกปิดแบบสอบถาม DNS ใหม่จะถูกส่งและเนื่องจากตรงกับเซสชั่นที่มีอยู่ (เนื่องจากคู่ต้นทางและปลายทางพอร์ต / IP เสมอเหมือนกัน) จึงถูกส่งต่อโดยไฟร์วอลล์ โปรดทราบว่าการหมดเวลาเซสชันจะไม่รีเฟรชตามแพ็คเก็ตที่มาถึงใหม่
3. เซสชัน DNS ที่สร้างขึ้นจะล้าสมัยเมื่อการตอบสนองการค้นหา DNS ครั้งแรก (ตอบกลับ) กระทบกับอุปกรณ์ไม่ว่าจะมีการหมดเวลาเท่าใด
4. เมื่อการตอบกลับ DNS ถูกส่งผ่านไฟร์วอลล์เซสชันจะหมดอายุ
5. การตอบกลับ DNS ต่อมาทั้งหมดจะถูกทิ้งโดยไฟร์วอลล์เนื่องจากไม่มีเซสชัน

หากคุณกำลังคิดที่จะถอนคำตอบนี้โปรดตอบคำถามของ Kempniu ด้วย ถ้าไม่มีมันฉันก็ยังคงตื่นเต้นที่จะพยายามค้นหาปัญหาการกำหนดค่าบางอย่างบน VM