วิธีจำลองการหมดเวลาตอบกลับของเซิร์ฟเวอร์ DNS

19

ฉันต้องทดสอบการทำงานของแอปพลิเคชันเมื่อไม่สามารถแก้ไขชื่อโฮสต์ได้เนื่องจากหมดเวลา การตั้งค่าnameserver 127.0.0.1ใน/etc/resolv.confไม่ได้ทำงาน: การทำงานที่เกี่ยวข้องกลับทันทีที่มีข้อยกเว้น อุปกรณ์ทดสอบคือ VM ที่สร้างด้วย Vagrant ที่รับที่อยู่ IP ของตนผ่าน DHCP

linux domain-name-system linux-networking

— ไซแนปส์
แหล่งที่มา

11

nameserver 127.0.0.1จะไม่ทำงานเนื่องจากพฤติกรรมเริ่มต้นนั้นอยู่แล้ว ให้ลองใช้ DNS ที่ไม่มีอยู่แทน เพื่อให้แน่ใจว่าคุณสามารถทำได้:

nslookup example.com 192.0.2.10

หากคุณไม่ได้รับการตอบกลับคุณสามารถใช้192.0.2.10เป็นเซิร์ฟเวอร์ DNS ของคุณได้

— sysfiend
แหล่งที่มา

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

— Jeff Meden

nslookup example.com non_existent_dns_ipผลลัพธ์: ;; connection timed out; trying next origin ;; connection timed out; no servers could be reached

— sysfiend

4

@JeffMeden คุณอาจรู้ แต่ช่วง 192.0.2.0/24 ถูกสงวนไว้สำหรับวัตถุประสงค์ในการทำเอกสารดังนั้นจึงไม่ควรใช้ที่ใดก็ได้ (และถูกปฏิเสธว่าเป็นไฟร์วอลล์ที่น่าเคารพจากตัวเอง)

— Dubu

2

@Dubu ที่จริง caveat น่าสนใจมากขึ้น ตามสเปคการรับส่งข้อมูลควรถูกปฏิเสธที่เราเตอร์ซึ่งอาจจะให้ "โฮสต์ปลายทางที่เข้าถึงไม่ได้" กับสแต็กซึ่งแตกต่างจากไทม์เอาต์อีกครั้ง

— Jeff Meden

26

การหมดเวลาการเชื่อมต่อเกิดขึ้นเมื่อเซิร์ฟเวอร์ DNS ไม่ตอบสนองเลยหรือไม่ตอบสนองในเวลาที่เหมาะสม

สิ่งแรกที่สามารถจำลองได้โดยเพียงแค่บล็อกการรับส่งข้อมูลไปยังเซิร์ฟเวอร์ DNS ของคุณบนระบบ Linux เช่น:

# iptables -I OUTPUT -p udp -d <iIP of DNS server> --dport 53 -j DROP

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

การสร้างความล่าช้านั้นเกี่ยวข้องกับอีกเล็กน้อย จากnetemคู่มือ :

# tc qdisc add dev eth0 root handle 1: prio
# tc qdisc add dev eth0 parent 1:3 handle 30: tbf rate 20kbit buffer 1600 limit  3000
# tc qdisc add dev eth0 parent 30:1 handle 31: netem  delay 200ms 10ms distribution normal
# tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32  match ip dst <IP_of_DNS_server>/32 flowid 1:3

ซึ่งสร้างความล่าช้า 200ms ด้วยการเปลี่ยนแปลงแบบสุ่ม± 10ms

— HBruijn
แหล่งที่มา

18

สิ่งที่คุณต้องการคือ "เซิร์ฟเวอร์หลุมดำ" คุณสามารถใช้blackhole.webpagetest.org( 72.66.115.13) ซึ่งจะส่งคำขอทั้งหมดอย่างเงียบ ๆ

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

ตัวอย่าง:

barend@shells:~$ dig example.com @72.66.115.13

; <<>> DiG 9.10.3-P4-Debian <<>> example.com @72.66.115.13
;; global options: +cmd
;; connection timed out; no servers could be reached

— grooveplex
แหล่งที่มา

2

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

— เจฟฟ์ Meden

1

เป็น Raspberry PI ที่มีการตั้งค่าไฟร์วอลล์ให้วางทุกอย่างดังนั้นจึงยังคงเส้นทางและตอบสนองต่อ ARP (เพียงเพื่อให้แน่ใจว่าปริมาณการใช้งานไม่ได้รับการตอบกลับ ICMP ที่ไม่สามารถเข้าถึงได้)

— pmeenan

@pmeenan ที่น่าสนใจ! ขอบคุณสำหรับการแบ่งปัน! (ว้าวไม่น่าเชื่อว่าคุณจะเข้าร่วมเพื่อแสดงความคิดเห็น: D)

— grooveplex

3

หากคุณไม่ได้ใช้เซิร์ฟเวอร์ DNS ในระบบทดสอบของคุณคุณควรจะใช้ที่อยู่ IP นั้นได้

คุณสามารถลองใช้ที่อยู่rfc1918 ที่ไม่ได้ใช้

คุณสามารถใช้ไฟร์วอลล์ของเซิร์ฟเวอร์เพื่อบล็อกแพ็กเก็ตขาออกด้วยพอร์ตปลายทาง 53

— user9517 รองรับ GoFundMonica
แหล่งที่มา

1

ไฟร์วอลล์บางตัวยังสามารถส่งคืนแพ็คเก็ต ICMP เพื่อให้หมดเวลาทันที

— Nathan Goings