Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login
    Introducing Netgate Nexus: Multi-Instance Management at Your Fingertips.

    DNS 127.0.0.1 resolve speed

    Scheduled Pinned Locked Moved DHCP and DNS
    4 Posts 3 Posters 138 Views 4 Watching
    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 Offline
      cjbujold
      last edited by

      Trying to understand why when doing a lookup that the 127.0.0.1 is always slower than using the pfSense server assigned IP.

      Here is a sample for addresses that are not cached. Once cached 127.0.0.1 is always 0ms and the others 1ms. Are the 1ms response not real and only a placeholder? If I add an external DNS they resolve with somewhat similar speed and the local address for pfSense are still 1ms.

      497b2b62-0bfd-4760-a4d7-115107991b88-image.png

      a7b01a4a-1ae0-431b-b1f3-fb4f2302721d-image.png

      GertjanG 1 Reply Last reply Reply Quote 0
      • GertjanG Offline
        Gertjan @cjbujold
        last edited by

        @cjbujold said in DNS 127.0.0.1 resolve speed:

        Trying to understand why when doing a lookup that the 127.0.0.1 is always slower than using the pfSense server assigned IP.

        I'm seeing the same thing :

        10c2695f-4138-4e4e-a72a-ae828de70983-image.png

        Extra info :
        My Resolver resolves, it isn't set up as a forwarder. Something that doesn't matter in this case.
        I also presume that the host name "ford.com" wasn't present in my Resolver's local (pfSense) cache, so it had to resolve the host name.
        For some reason, IPv4 was tried first : 127.0.0.1, an it took a while, 120 msec the answer came back : 19.12.97.37 (the default request was : get me a A record, or IPv4 address).
        Then the same request was done over IPv6, so ::1 was used.
        But this time, the answer was already known buy the resolver- and you know why ^^ - so it could answer right away to the requester without doing a full resolve lookup. So it could answer within 1 msec.
        That why IPv6 seems faster.
        Now you 😊

        If you want to know the true IPv6 delay, execute this :

        dig -6 @::1 ford.com AAAA +trace +nodnssec
        

        [ this commands asks for the AAAA record, that's the IPv6 address, using only IPv6 as the transport protocol, and give us all de trace = details, and don't show dnssec info as it clutters the answer with useless info ]
        It's a .... mess.
        I presume ford.com isn't really IPv6 compatible yet. It's probably an American company, so IPv6 is still optional for them.

        Btw ford.com is messy. Another example and here.

        No "help me" PM's please. Use the forum, the community will thank you.

        1 Reply Last reply Reply Quote 0
        • C Offline
          cjbujold
          last edited by

          My unbound is not set up as a forwarder, and the Ford.com was not cached in unbound; therefore, I understand the time required to resolve, but I don't understand the 1ms shown. You are correct that IP6 is much faster, but unfortunately in Canada my ISP only provides IP4 service.

          johnpozJ 1 Reply Last reply Reply Quote 0
          • johnpozJ Online
            johnpoz LAYER 8 Global Moderator @cjbujold
            last edited by

            @cjbujold said in DNS 127.0.0.1 resolve speed:

            but I don't understand the 1ms shown

            because asked it after it was cached. example

            firstask.jpg

            It took it 150ms to resolve it the first time, ask it again and pretty much instant.

            An intelligent man is sometimes forced to be drunk to spend time with his fools
            If you get confused: Listen to the Music Play
            Please don't Chat/PM me for help, unless mod related
            SG-4860 26.07 | Lab VMs 2.9.0, 26.07

            1 Reply Last reply Reply Quote 1
            • First post
              Last post
            Copyright 2026 Rubicon Communications LLC (Netgate). All rights reserved.
            Privacy Policy · Cookie Policy