I need to test an application's behavior when it can't resolve a hostname due to a timeout. Setting nameserver 127.0.0.1 in /etc/resolv.conf didn't work: the relevant functions return immediately with an exception. The test rig is a VM created with Vagrant that receives its IP address via DHCP.
Add a comment
|
4 Answers
nameserver 127.0.0.1 won't work as the default behaviour is already that. Instead, try using a non existing DNS. To make sure, you can do:
nslookup example.com 192.0.2.10
If you get no response, then you can use 192.0.2.10 as your DNS server.
-
This isn't guaranteed to produce a timeout, since 192.0.2.10 could (although its not likely) be a real host, and like 127.0.0.1, it could return "port unreachable" immediately upon querying. You don't need to pick a host that you're sure isn't running DNS (like your nslookup command checks) you need to pick a host you are sure won't respond at all. Commented May 11, 2016 at 12:58
-
nslookup example.com non_existent_dns_ipoutputs:;; connection timed out; trying next origin ;; connection timed out; no servers could be reached– sysfiendCommented May 11, 2016 at 13:00 -
4@JeffMeden You probably know, but the range 192.0.2.0/24 is reserved for documentation purposes, so it should not be used anywhere (and refused as a bogon by any self-respecting firewall).– DubuCommented May 11, 2016 at 13:59
-
2@Dubu that's actually a more interesting caveat; per the spec the traffic should be rejected at the router which will probably give back a "destination host unreachable" to the stack, which is again different from a timeout. Commented May 11, 2016 at 15:02
A connection time-out occurs when the DNS server doesn't respond at all, or does not respond in a timely fashion.
The first can be simulated by simply blocking al traffic to your DNS server, on a Linux system for instance with:
# iptables -I OUTPUT -p udp -d <iIP of DNS server> --dport 53 -j DROP
Using DROP as the target means you won't even get a connection refused error, it becomes just a black hole. (It's unlikely that you normally would be doing zone transfers, so blocking the TCP protocol in addition to UDP is not needed.)
Creating delays is slightly more involved. From the netem manual:
# 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
Which creates a 200ms delay with ± 10ms random variation.
What you need is a "black hole server". You can use blackhole.webpagetest.org (72.66.115.13) which will silently drop all requests.
Why I suggest this over the other answers, is because the aforementioned server has been established for this sole purpose.
Example:
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
-
2Just when I thought I'd seen it all; a dedicated server that specifically does... nothing. Brilliant! (probably just a network config thing and not an actual server with a filter-all firewall, but still) Commented May 12, 2016 at 15:19
-
1It's a Raspberry PI with a firewall set to drop everything so it still routes and responds to ARP (just to be sure traffic doesn't get ICMP unreachable responses).– pmeenanCommented May 18, 2017 at 17:31
-
@pmeenan that's interesting! Thanks for sharing! (Wow, can't believe you joined just to comment :D) Commented May 18, 2017 at 17:33
If you're not running a DNS server on your test system, you should be able to use it's IP address.
You could try using an unused rfc1918 address.
You could use your server's firewall to block outgoing packets with a destination port 53.
-
1Some firewalls can also return ICMP packets so that the timeout is instant. Commented May 11, 2016 at 16:00