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

    Unexplainable Issue with BIND!!!

    Scheduled Pinned Locked Moved pfSense Packages
    2 Posts 1 Posters 1.1k 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.
    • N
      n2n
      last edited by

      Hi All,

      This is a rather interesting situation.

      The setup:

      1.  Recently configured 2 pfsense standalone boxes (2.3.3-RELEASE (amd64)) in 2 virtual machine on hyper-v with only one interface (WAN) for each.

      2.  I intended to use them as Authoritative DNS servers for our organizaion. (and recursive from localnet).

      3.  Both the boxes are running just the BIND package and a couple of firewall rule to allow the traffic. One in master and another in slave role. (no HA is configured on pfsense itself).

      The fact:

      It was running flawlessly for couple of days. So smooth, as a matter of fact, i ditched my old ns servers running on ubuntu.

      The problem:

      The problem occurred when I changed one of the records in the master. I changed the record, changed the serial, saved the zone - it was immediately reflected in the slave (the zone had the new serial. Going inside, i could see the the new record as well). I was impressed that I didn't had to restart the the service  even. So everything seems to be working as it should be, right?

      I thought so as well. But unfortunately no. When I do a DNS lookup with dig or nslookup, the master replies with the new record but not the slave. I did everything I could, restarted both the servers, deleted the zones from slave and resynced, tried clearing dns cache from the pc i was issuing dig/ nslookup, I even used the DNS lookup from the pfsense diagnostic menu.

      Summary:

      So this is the situation folks. Even though the master and slave is syncing flawlessly, no matter what I do, the slave keeps replying me with old records (including old serial number when i do a dig for SOA). I feel dumb… what am I missing guys!!!?

      1 Reply Last reply Reply Quote 0
      • N
        n2n
        last edited by

        Hi Again,

        I narrowed down my findings. I logged in through the shell and notice that the actual zone files in the slave server are not being updated (though the GUI is synced with master). Deleting the zone files from the slave and resyncing solves the issue of replying of old records. It seems that the zone transfer works fine when there is no existing zone file in the slave. Sadly, it is unable to update if there is any existing file.

        I figure that the XMLRPC syncs the backend database of the GUI. To my understanding, it is then supposed to either generate the slave zone file based on that data, or it should initiate a transfer of the actual zone file of the master (like any other master-slave dns zone transfer).

        I am still unsure if there is configuration mistake or its happening because of a bug. I'll appreciate any help, opinion or suggestions. Thanks in advance.

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