Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Unbound Much Slower than dnsmasq

    Scheduled Pinned Locked Moved DHCP and DNS
    4 Posts 3 Posters 5.2k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • C
      CiscoKid85
      last edited by

      I'm trying to understand why the DNS Resolver is much slower than the DNS Forwarder. Is there anything I can do to troubleshoot?

      It would seem to me that dnsmasq is is significantly better than unbound.. Can anyone shed some light on this?

      Thanks in advance!

      DNS Resolver:

      Google.com
      127.0.0.1                 56 msec
      75.75.75.75         11 msec
      8.8.8.8                 31 msec
      2001:558:FEED::1 15 msec
      208.67.222.222 37 msec

      Amazon.com
      127.0.0.1                 46 msec
      75.75.75.75         15 msec
      8.8.8.8                 17 msec
      2001:558:FEED::1 13 msec
      208.67.222.222 16 msec

      DNS Forwarder:

      google.com
      127.0.0.1                 1 msec
      75.75.75.75         11 msec
      8.8.8.8                 17 msec
      2001:558:FEED::1 9 msec
      208.67.222.222 16 msec

      amazon.com
      127.0.0.1                 11 msec
      75.75.75.75         14 msec
      8.8.8.8                 16 msec
      2001:558:FEED::1 18 msec
      208.67.222.222 18 msec

      1 Reply Last reply Reply Quote 0
      • K
        kejianshi
        last edited by

        DNS resolver is slower because you have yet to use DNS resolver…

        $ drill google.com
        ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 52529
        ;; flags: qr rd ra ; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
        ;; QUESTION SECTION:
        ;; google.com. IN A

        ;; ANSWER SECTION:
        google.com. 257 IN A 65.199.32.150
        google.com. 257 IN A 65.199.32.152
        google.com. 257 IN A 65.199.32.151
        google.com. 257 IN A 65.199.32.154
        google.com. 257 IN A 65.199.32.155
        google.com. 257 IN A 65.199.32.153
        google.com. 257 IN A 65.199.32.148
        google.com. 257 IN A 65.199.32.149

        ;; AUTHORITY SECTION:

        ;; ADDITIONAL SECTION:

        ;; Query time: 0 msec
        ;; SERVER: 127.0.0.1
        ;; WHEN: Thu Feb 19 20:35:36 2015
        ;; MSG SIZE  rcvd: 156

        $ drill amazon.com
        ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 156
        ;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 6, ADDITIONAL: 0
        ;; QUESTION SECTION:
        ;; amazon.com. IN A

        ;; ANSWER SECTION:
        amazon.com. 60 IN A 72.21.215.232
        amazon.com. 60 IN A 205.251.242.54
        amazon.com. 60 IN A 176.32.98.166

        ;; AUTHORITY SECTION:
        amazon.com. 3600 IN NS pdns1.ultradns.net.
        amazon.com. 3600 IN NS ns4.p31.dynect.net.
        amazon.com. 3600 IN NS ns3.p31.dynect.net.
        amazon.com. 3600 IN NS ns1.p31.dynect.net.
        amazon.com. 3600 IN NS ns2.p31.dynect.net.
        amazon.com. 3600 IN NS pdns6.ultradns.co.uk.

        ;; ADDITIONAL SECTION:

        ;; Query time: 245 msec
        ;; SERVER: 127.0.0.1
        ;; WHEN: Thu Feb 19 20:37:07 2015
        ;; MSG SIZE  rcvd: 225

        Now - lets check the last one again...

        $ drill amazon.com
        ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 54477
        ;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 6, ADDITIONAL: 0
        ;; QUESTION SECTION:
        ;; amazon.com. IN A

        ;; ANSWER SECTION:
        amazon.com. 14 IN A 72.21.215.232
        amazon.com. 14 IN A 205.251.242.54
        amazon.com. 14 IN A 176.32.98.166

        ;; AUTHORITY SECTION:
        amazon.com. 3554 IN NS pdns1.ultradns.net.
        amazon.com. 3554 IN NS ns4.p31.dynect.net.
        amazon.com. 3554 IN NS ns3.p31.dynect.net.
        amazon.com. 3554 IN NS ns1.p31.dynect.net.
        amazon.com. 3554 IN NS ns2.p31.dynect.net.
        amazon.com. 3554 IN NS pdns6.ultradns.co.uk.

        ;; ADDITIONAL SECTION:

        ;; Query time: 0 msec
        ;; SERVER: 127.0.0.1
        ;; WHEN: Thu Feb 19 20:37:53 2015
        ;; MSG SIZE  rcvd: 225

        So, once its cached (and with my settings, if its a frequent site, it will get auto-cached often) its about 0ms lookup time.

        You are using forwarder(s).  Not really using DNS resolver as a resolver.

        1 Reply Last reply Reply Quote 0
        • K
          kejianshi
          last edited by

          Also, how fast a resolver works (difference measured in imperceptible milliseconds) is less important than how accurately and reliably is resolves.

          Using DNS resolver as it should be will probably always take longer on the very 1st lookup because the nearest root DNS server is further away than my ISPs DNS server.

          However, given the number of lookups happening in a day, the difference in speed of the very first lookup is not a good metric to use to decide which DNS server is "better".

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            You're not comparing the same thing.

            The 127.0.0.1 replies are the only thing that actually uses unbound or dnsmasq, the others are querying those servers directly. The variance on the ones other than 127.0.0.1 is just variance in your Internet connection and/or the response time of whichever server you hit when going to those anycasted DNS IPs.

            With Unbound in its default configuration, it does its own recursion. That's going to require additional queries if your cache is completely empty, so the initial query for a domain will be slower than where you forward queries to a public DNS resolver that's already going to have every popular domain cached. You can enable forwarder mode if you want the same behavior as dnsmasq in that regard.

            Your dnsmasq results for google.com is 1 ms because it was already in the cache, it had to do nothing but reply from its local cache. Unbound would come back the same if it was replying from cache. The Amazon results are atypical given the way dnsmasq resolved that is by sending the same query that took 14-18 ms sending separately, just happened to have less jitter at the time that query was issued (more along the lines of the response times for google.com).

            There isn't a measurable performance difference between them where you're measuring the same thing.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.