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

    Bind pull DNS info from pfSense

    Scheduled Pinned Locked Moved DHCP and DNS
    7 Posts 3 Posters 7.9k 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.
    • X
      xibalba
      last edited by

      Hey everyone,
        I'm using lots of pfSense machines at my clients' offices, which are all connected back to a pfSense machine at my colocation center. So they're all on the networks 192.168/16. I'd like to setup the "Register DHCP leases in DNS forwarder" on each client site so that way I can resolve client computer names on each individual site. I'd like to be able to use a central BIND server in my colo, and was thinking about having the BIND server pull the zone file(s) from each pfSense machine. This would make it easier to work on their computers remotely so I can just type
      computerName.clientName.mydomain.local

      any suggestions on how to complete this, or if my plan is flawed some how?
      thanks

      1 Reply Last reply Reply Quote 0
      • M
        mkomar
        last edited by

        I am looking to do something similar, but the approach I am taking is to have a central DNS server act as a slave to the other zones. During the initial setup, I ran into no error messages, but the zone did not get transfered.

        I manually tried a zone xfer and got this:

        [root@station8 ~]# /usr/libexec/named-xfer -z compound. -f /tmp/dnstest.db -s 1 192.168.10.1
        named-xfer[1014]: [192.168.10.1] not authoritative for compound, SOA query got rcode 0, aa 0, ancount 0, aucount 13

        As evidenced below, everything works perfectly with the exception of the pfSense box believing it is authoritative for the compound. zone.

        [digital@pirate ~]$ cat /etc/resolv.conf
        search compound
        nameserver 192.168.10.1

        [digital@pirate ~]$ ping -c 3 ninja
        PING ninja.compound (192.168.10.86): 56 data bytes
        64 bytes from 192.168.10.86: icmp_seq=0 ttl=64 time=0.231 ms
        64 bytes from 192.168.10.86: icmp_seq=1 ttl=64 time=0.210 ms
        64 bytes from 192.168.10.86: icmp_seq=2 ttl=64 time=0.236 ms

        –- ninja.compound ping statistics ---
        3 packets transmitted, 3 packets received, 0% packet loss
        round-trip min/avg/max/stddev = 0.210/0.226/0.236/0.011 ms

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

          @mkomar:

          I am looking to do something similar, but the approach I am taking is to have a central DNS server act as a slave to the other zones. During the initial setup, I ran into no error messages, but the zone did not get transfered.

          I manually tried a zone xfer and got this:

          [root@station8 ~]# /usr/libexec/named-xfer -z compound. -f /tmp/dnstest.db -s 1 192.168.10.1
          named-xfer[1014]: [192.168.10.1] not authoritative for compound, SOA query got rcode 0, aa 0, ancount 0, aucount 13

          As evidenced below, everything works perfectly with the exception of the pfSense box believing it is authoritative for the compound. zone.

          [digital@pirate ~]$ cat /etc/resolv.conf
          search compound
          nameserver 192.168.10.1

          [digital@pirate ~]$ ping -c 3 ninja
          PING ninja.compound (192.168.10.86): 56 data bytes
          64 bytes from 192.168.10.86: icmp_seq=0 ttl=64 time=0.231 ms
          64 bytes from 192.168.10.86: icmp_seq=1 ttl=64 time=0.210 ms
          64 bytes from 192.168.10.86: icmp_seq=2 ttl=64 time=0.236 ms

          –- ninja.compound ping statistics ---
          3 packets transmitted, 3 packets received, 0% packet loss
          round-trip min/avg/max/stddev = 0.210/0.226/0.236/0.011 ms

          DNS Forwarder running?  Try disabling it.

          1 Reply Last reply Reply Quote 0
          • M
            mkomar
            last edited by

            I disabled DNS Forwarder and got this:

            [root@station8 ~]# /usr/libexec/named-xfer -z compound -f /tmp/dnstest.db -s 1 192.168.10.1
            named-xfer[59333]: connect(192.168.10.1) for zone compound failed: Operation timed out

            re-enabled it and I'm back to:

            [root@station8 ~]# /usr/libexec/named-xfer -z compound -f /tmp/dnstest.db -s 1 192.168.10.1
            named-xfer[67188]: [192.168.10.1] not authoritative for compound, SOA query got rcode 5, aa 0, ancount 0, aucount 0

            I appreciate your prompt reply!

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

              You might want to check into http://cr.yp.to/djbdns/axfrdns.html

              1 Reply Last reply Reply Quote 0
              • M
                mkomar
                last edited by

                If I am reading that correctly, it seems I would need to run that as a daemon on the pfSense box? (In my current setup)

                Perhaps there is a better way to go about this.

                The skinny is I've got a number of private networks. In the past I've used full blown FreeBSD machines running natd, ipfw and bind. I then have them master/slave to each other as needed in order to keep DNS information up to date with the dynamic hosts in each enviroment.

                I would LOVE replacing all the natd boxes with pfSense. One of the big reasons for that is the ease of maintaining them. Just backup the configs and if there is a problem, recreating them is quick and easy. I feel like adding additional custom daemons to them would defeat the purpose to a large degree.

                Anybody have any ideas on a better way to go?

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

                  That is the way DJBDNS works.  You need another daemon.

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