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

    Dns cache

    DHCP and DNS
    3
    6
    5.0k
    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.
    • R
      rexster
      last edited by

      where can i change the default dns cache time out?

      how about squid? does squid also use same dns cache?
      or does it have its own dns cache? where it's set?

      tnx&rgds
      rex

      http://www.GoBlogLah.com

      1 Reply Last reply Reply Quote 0
      • L
        Leoandru
        last edited by

        @rexster:

        where can i change the default dns cache time out?

        how about squid? does squid also use same dns cache?
        or does it have its own dns cache? where it's set?

        tnx&rgds
        rex

        you can't change the default ttl on dns records in dnsmasq. I have checked. as for squid it reads resolve.conf for name servers so its uses the same upstream server as dnsmasq. it also creates up to five processes for dnslookup (so yes it has its own cache). In transparent mode a dns lookup is twice as expensive, since its done once by the browser and once again by squid. If you want squid to use dns on the firewall you need to specify that in the squid config with the dns_nameservers option. That way since dnsmasq caches lookups, squid will hit that cache on the next lookup. I verified this by the way and modified my squid_ng.inc to include the option. I should be able to make this an option in the gui provided I get the time this weekend, work has been really demanding of late, don't even have time for myself.

        1 Reply Last reply Reply Quote 0
        • R
          rexster
          last edited by

          imho,
          a better way using dns cache is telling pfsense that localhost will serve all dns request.
          including request by squid and its own use.

          right now, if you ssh into pfsense and type (say,) ping yahoo.com
          pfsense will use /etc/resolv.conf to resolve the ip address.
          that mean it goes directly to assigned dns server.

          so, imho, /etc/resolve should have this entry instead:
          nameserver 127.0.0.1

          this way, instead of go directly to dns server, it try to resolve through dnsmasq cache.

          then when it's not in cache, dnsmasq should try to go directly to dns server.
          so, we should have entry in dnsmasq.conf something like this:
          resolv-file=/etc/realdnsservers

          and the /etc/realdnsservers file should contain the dns server obtain from dhcp.

          rgds,
          dny.

          refs:
          http://thekelleys.org.uk/dnsmasq/docs/setup.html

          http://www.GoBlogLah.com

          1 Reply Last reply Reply Quote 0
          • S
            sullrich
            last edited by

            Setting 127.0.0.1 in the general screen has the same effect.

            1 Reply Last reply Reply Quote 0
            • L
              Leoandru
              last edited by

              @sullrich:

              Setting 127.0.0.1 in the general screen has the same effect.

              would that make dnsmasq use 127.0.0.1 as the name server seeing that it reads /etc/resolv.conf for the upstream servers?. I think what he is suggesting is that an alternate file be used to tell dnsmasq the name server(s) to use, while telling all other processes on the firewall (except dnsmasq) to use 127.0.0.1 via  /etc/resolv.conf. In other words change dnsmasq resolve file to something else other than the default.

              1 Reply Last reply Reply Quote 0
              • S
                sullrich
                last edited by

                Yeah, that is true.  Kinda a catch-22 in that regard, I guess.

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