Dns cache not working as bind, can be fixit?



  • Hi people.

    I was working with my box running freebsd 7.2 and bind as dns cache, went I run a test example:

    host -a yahoo.com or any other site.

    The result was about 80ms or less, running  again the same query it took 1ms because bind was doing caching very well.

    Now I install pfsense, enable dnsforward, it suppose that this enable the cache server by default, but the answer times are not the same as bind.

    host -a yahoo.com (127.0.0.1) or what ever name I chose the time in ms is never closes as the one give me by bind.

    Sometimes I receive the "server timeout"

    I know that bind is a big program compare with pfsense dnsforward.

    Exist a way to give more speed to the pfsense internal cache server or we have to build our one internal cache server?

    This is my home box, but suppose that we need to setup a pfsense in a business where we have more than 10 clients, I ask this because I have plans to install a pfsense in my job, there we have about 30 machines accessing the Internet, this can be a neck bottle.

    How we can fix this inside pfsense? can be use tinydns or this feature is still not enable inside this package?
      Do we need to setup other machine just for this?

    Thanks for your time  ;D



  • The DNS forwarder does exactly what you want and is much lighter weight than BIND. As an example, my first queries take around 35 ms, subsequent queries for cached records always take 1 ms.

    $ dig yahoo.com @10.0.69.1

    ; <<>> DiG 9.4.2-P2 <<>> yahoo.com @10.0.69.1
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28730
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;yahoo.com.                    IN      A

    ;; ANSWER SECTION:
    yahoo.com.              21349  IN      A      69.147.114.224
    yahoo.com.              21349  IN      A      209.131.36.159
    yahoo.com.              21349  IN      A      209.191.93.53

    ;; Query time: 35 msec
    ;; SERVER: 10.0.69.1#53(10.0.69.1)
    ;; WHEN: Fri Aug  7 23:12:23 2009
    ;; MSG SIZE  rcvd: 75

    $ dig yahoo.com @10.0.69.1

    ; <<>> DiG 9.4.2-P2 <<>> yahoo.com @10.0.69.1
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22396
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;yahoo.com.                    IN      A

    ;; ANSWER SECTION:
    yahoo.com.              21348  IN      A      209.191.93.53
    yahoo.com.              21348  IN      A      209.131.36.159
    yahoo.com.              21348  IN      A      69.147.114.224

    ;; Query time: 1 msec
    ;; SERVER: 10.0.69.1#53(10.0.69.1)
    ;; WHEN: Fri Aug  7 23:12:24 2009
    ;; MSG SIZE  rcvd: 75



  • @cmb:

    The DNS forwarder does exactly what you want and is much lighter weight than BIND. As an example, my first queries take around 35 ms, subsequent queries for cached records always take 1 ms.

    it works like that for me, if you execute the "dig" one right after the another .. but if for instance i run dig google.com, and then run it again 5mins later .. the response time is no longer 1msec.

    i can feel this while browsing … with firefox you can actually notice the "Looking up google.com" in the status bar.

    perhaps im doing something wrong or is there any setting to make dns forwarder remember ips for longer periods of time ?



  • Hi my friends.

    U got a point here lboregard. I have seen the behavior u say, sometimes I receive answer of 5ms and most of the time 30ms, running the same test.

    With bind once u run run the first query latter u get 1ms to 5ms answer. I will make more tests, I want to test bind vs dnsforwarder went I get the 30ms of pfsense cache server, I have a computer running BSD 7.2 with bind as cache dns.

    I will let u know the results, I just a little time to sit at home and the test.

    See u soon with the info.



  • @lboregard:

    it works like that for me, if you execute the "dig" one right after the another .. but if for instance i run dig google.com, and then run it again 5mins later .. the response time is no longer 1msec.

    And that's the way it should work. Google's TTL is 5 minutes. Caching it longer than the TTL is a violation of networking standards, and no reputable name server will do this (unless you change the source and recompile, and risk breaking things - you should never do this).

    @lboregard:

    i can feel this while browsing …

    It's in your head, or your browser has issues. 35 ms is 0.035 seconds. You aren't going to be able to differentiate an additional 3.5 hundredths of a second delay.



  • Hi my friends, check this info and hope u understand what I try to tell:

    host -a yahoo.com with pfsense internal dns:

    First query with my pfsense box:

    host -a osnews.com

    Trying "osnews.com"
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53621
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2 

    Received 151 bytes from 127.0.0.1#53 in 21 ms

    Second query:

    host -a osnews.com

    Trying "osnews.com"
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55689
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2
    ...
    Received 151 bytes from 127.0.0.1#53 in 15 ms

    Now with my bind acting as cache server only(freebsd):

    First query:

    gwbsd# host -a osnews.com
    Trying "osnews.com"
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50940
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2
    ...
    Received 151 bytes from 127.0.0.1#53 in 19 ms

    Second query:

    gwbsd# host -a osnews.com
    Trying "osnews.com"
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64005
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2
    ...
    Received 151 bytes from 127.0.0.1#53 in 0 ms

    Now lets go to other search, against a unix site:

    First with pfsense.

    host -a freebsd.org

    Trying "freebsd.org"
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42059
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 3, ADDITIONAL: 3
    ...
    Received 436 bytes from 200.23.249.1#53 in 2037 ms

    Second

    host -a freebsd.org

    Trying "freebsd.org"
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61222
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 3, ADDITIONAL: 3
    ...
    Received 436 bytes from 127.0.0.1#53 in 19 ms

    Now first with BSD running bind as cache server:

    gwbsd# host -a freebsd.org
    Trying "freebsd.org"
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62990
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 3, ADDITIONAL: 3
    ...
    Received 436 bytes from 127.0.0.1#53 in 822 ms

    Second:

    gwbsd# host -a freebsd.org
    Trying "freebsd.org"
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49592
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 3, ADDITIONAL: 3
    ...
    Received 436 bytes from 127.0.0.1#53 in 1 ms

    I had been running this queries as I answer this post.

    U can see the difference in time, is ms but if we want to go to the big league I think this could cause as problems.

    I have never seen pfsense times as small as bind acting as cache server in my case.

    This is just a small issue that took my attention.

    Thanks for your time!!!



  • @periko:

    Hi my friends, check this info and hope u understand what I try to tell:

    host -a yahoo.com with pfsense internal dns:

    This isn't a valid test, host isn't doing lookups the same way normal DNS lookups are done. It sends ANY queries, rather than A queries. dnsmasq doesn't answer ANY queries from cache, I'm not sure if that's a glitch or it's by design for some reason, but it's irrelevant because no host will ever send queries that way. Use dig, it uses A queries and you'll get accurate response times and see the difference from cached records, the same as a real DNS query from hosts will see.

    @periko:

    U can see the difference in time, is ms but if we want to go to the big league I think this could cause as problems.

    If this was really a problem with cached records not being returned instantaneously, I would agree this is a problem. But that's not the case.



  • Hi cmb.

    Good to know new things, I will do some test tonight to confirm what u answer, thanks again!!!



  • My friends.

    cmb u are right, the results are the same, i was doing the wrong test.

    The results are the same using dig.

    Thanks cmb for clarifying this, I appreciated  :)


Log in to reply