I need to test an application's behavior when it can't resolve a hostname due to a timeout. Setting nameserver 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.

4 Answers 4


nameserver 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

If you get no response, then you can use as your DNS server.

  • This isn't guaranteed to produce a timeout, since could (although its not likely) be a real host, and like, 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.
    – Jeff Meden
    May 11, 2016 at 12:58
  • nslookup example.com non_existent_dns_ip outputs: ;; connection timed out; trying next origin ;; connection timed out; no servers could be reached
    – sysfiend
    May 11, 2016 at 13:00
  • 4
    @JeffMeden You probably know, but the range is reserved for documentation purposes, so it should not be used anywhere (and refused as a bogon by any self-respecting firewall).
    – Dubu
    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.
    – Jeff Meden
    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 ( 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.


barend@shells:~$ dig example.com @

; <<>> DiG 9.10.3-P4-Debian <<>> example.com @
;; global options: +cmd
;; connection timed out; no servers could be reached
  • 2
    Just 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)
    – Jeff Meden
    May 12, 2016 at 15:19
  • 1
    It'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).
    – pmeenan
    May 18, 2017 at 17:31
  • @pmeenan that's interesting! Thanks for sharing! (Wow, can't believe you joined just to comment :D)
    – grooveplex
    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.

  • 1
    Some firewalls can also return ICMP packets so that the timeout is instant. May 11, 2016 at 16:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .