Home / server / Questions / 476000
In Process
sourcejedi
Asked: 2013-02-07 03:38:27 +0800 CST

What could this extra 50ms latency be on my unbound DNS resolving server (Fedora)?

  • 772

I have a discrepancy in query latency. It's not a problem, it's just strange enough to worry me.

  • Client machine (Fedora 18) runs unbound-1.4.19-1.fc18.x86_64.
  • Server machine (Debian 7 testing) runs unbound 1.4.17-2.

Both are connected to the same home router. However the server can resolve uncached queries almost twice as fast. This wasn't what I expected at all! The server is a 1Ghz ARM (sheevaplug), and the client machine is a 2.1Ghz Intel Core Duo.

Both instances validate DNSSEC. They return SERVFAIL for www.dnssec-failed.org. Both are configured to use the same upstream DNS caches from my ISP.

All I can think of so far is some issue with NAT. The router is configured with the server as "default DMZ", i.e. it gets any packets no-one else is claiming, which is how I run public services like SSH and bittorrent :). Or... maybe minor-version-19 is validating more strictly than minor-version-17, in some way?

Test methodology: resolution of 10 non-existent sub-domains of .de. (Should cause ISP cache misses). The .de. TLD is pre-loaded by querying yahoo.

From client side

$ for i in 1 2 3 4 5 6 7 8 9; do sudo unbound-control reload; (dig yahoo.de.; dig twitter$i.de.) | grep Query; done

Result - mean 120ms, stddev 60ms

From server side

$ for i in 1 2 3 4 5 6 7 8 9; do sudo unbound-control reload; (dig yahoo.de.; dig aldi$i.de. ) | grep Query; done

Result - mean 70ms, stddev 50ms

I know, the test doesn't look great, and my statistics may not be overwhelming evidence. But I tried it a few more times, and it's not looking any different.

domain-name-system

1 Answers

  1. Ah! I just diffed the unbound.conf between the two computers. It seems that Fedora turns on the option below. Turning it off gets rid of the additional latency on the Fedora machine.

        # Harden the referral path by performing additional queries for
    # infrastructure data.  Validates the replies (if possible).
    # Default off, because the lookups burden the server.  Experimental
    # implementation of draft-wijngaards-dnsext-resolver-side-mitigation.
    harden-referral-path: yes

    I'll have to look this up and decide whether I want to use it :).

    Link: https://datatracker.ietf.org/doc/draft-wijngaards-dnsext-resolver-side-mitigation/

    • 3