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

    PfSense BIND and CNAME Quandry

    Scheduled Pinned Locked Moved DHCP and DNS
    3 Posts 2 Posters 1.6k 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.
    • C
      Craash
      last edited by

      I have a pfSense box that I'm going to migrate my LAN's primary DNS to.

      The current master is a ubunitu 16.04LTS box.  It will become a secondary once the migration is complete.

      So far I'm created a single zonefile on pfSense, manually.

      kc.corp.

      All A records resolve as one would expect.

      What gets weird is CNAME records.

      For example, I have a host named 'gateway' (FQDN gateway.kc.corp)

      I created a A record for 'gateway' of 192.168.0.254. (which is the pfsense box)

      I created a CNAME pointing of 'gw' pointing to gateway.kc.corp.

      gateway (or FQDN) resolves fine from a workstation

      gw fails on pfSense.

      NSLookup does not return a value for it unless I set the q=cname.

      C:\Users\Tech>ping gw
      Ping request could not find host gw. Please check the name and try again.

      C:\Users\Tech>nslookup
      Default Server:  UnKnown
      Address:  192.168.0.254 -> remember, this is the pfsense box.

      gw
      Server:  UnKnown
      Address:  192.168.0.254

      *** UnKnown can't find gw: Non-existent domain

      set q=cname
      gw
      Server:  UnKnown
      Address:  192.168.0.254

      gw.kc.corp  canonical name = 6BH3S52
      kc.corp    nameserver = 6BH3S52.kc.corp
      kc.corp    nameserver = X7DWE.kc.corp
      X7DWE.kc.corp      internet address = 192.168.0.1
      6BH3S52.kc.corp    internet address = 192.168.0.254

      Any ideas?

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

        "Server:  UnKnown
        Address:  192.168.0.254"

        You don't even PTR for your own networks.. Ie server unknown.. I would fix the basics before moving on ;)

        gw.kc.corp  canonical name = 6BH3S52

        Huh???  WTF is that?  Post up you zone file and bind config if you have questions on bind.

        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 24.11 | Lab VMs 2.8, 24.11

        1 Reply Last reply Reply Quote 0
        • C
          Craash
          last edited by

          I believe I've found my issue.

          I think it all boils down to the $ORIGIN option.

          In standard "master file format" files if you don't add the trailing '.' then the name is assumed to be relative to the current zone file's $ORIGIN (which is either specified in the zone file, or taken from the zone statement in named.conf otherwise).

          My pfsense Bind installation is appending a "." after my CNAMEs (in the file, not the web interface).  The . makes the name be relative to the root, without it, it the name will be relative to the current zone. The standard zone format is defined in rfc1035 and rfc1034.

          A workaround?  Use FQDN for the CNAME.

          In the very possible senerio I'm missing something, here is my named.conf:

          _**#Bind pfsense configuration
          #Do not edit this file!!!

          key "rndc-key" {
                  algorithm hmac-md5;
                  secret "U2pHDolr0KZStIQrFOVPTw==";
          };

          controls {
                  inet 127.0.0.1 port 953
                          allow { 127.0.0.1; } keys { "rndc-key"; };
          };

          options {
                  directory "/etc/namedb";
                  pid-file "/var/run/named/pid";
                  statistics-file "/var/log/named.stats";
                  max-cache-size 512M;
                  listen-on-v6 { ::1;  };
                  listen-on { 192.168.0.254; 127.0.0.1;  };
                  notify yes;
                  allow-query    { any; };^M
                  empty-zones-enable  yes;
          };

          logging {
                  channel custom {
                          syslog daemon;
                          print-time no;
                          print-severity yes;
                          print-category yes;
                          severity dynamic;
                          };
                  category default { custom; };
          };

          acl "kc.corp" {
                  192.168.0.0/24;
          };

          view "LAN" {
                  recursion yes;
                  match-clients { any; };
                  allow-recursion { any; };

          zone "kc.corp" {
                          type master;
                          file "/etc/namedb/master/LAN/kc.corp.DB";
                          allow-query { any; };
                          allow-transfer { kc.corp; };
                          allow-update { kc.corp; };
                  };

          zone "0.168.192.in-addr.arpa" {
                          type master;
                          file "/etc/namedb/master/LAN/0.168.192.DB";
                          allow-query { kc.corp; };
                          allow-transfer { kc.corp; };
                          allow-update { kc.corp; };
                  };

          zone "." {
                          type hint;
                          file "/etc/namedb/named.root";
                  };

          };**_

          My kc.corp zone file: In it, notice the trailing periods after the CNAME value.  By placing kc.corp after the gw CNAME, it worked as expected.

          _**$TTL 6h
          ;
          ; Database file kc.corp.DB for kc.corp zone.
          ; Do not edit this file!!!
          ; Zone version 2
          ;
          kc.corp. IN  SOA 6BH3S52.kc.corp. zonemaster.kc.corp. (
          2 ; serial
          1d ; refresh
          2h ; retry
          4w ; expire
          1h ; default_ttl
          )

          ;
          ; Zone Records
          ;
          @ IN NS 6BH3S52.kc.corp.
          @ IN NS  X7DWE.kc.corp.
          6BH3S52 IN A  192.168.0.254
          gateway IN CNAME  6BH3S52.
          gw IN CNAME  6BH3S52.kc.corp.
          X7DWE IN A  192.168.0.1
          SRXC606 IN A  192.168.0.69
          me IN CNAME  SRXC606.
          N5550 IN A  192.168.0.2
          ns1 IN CNAME  6BH3S52.
          ns2 IN CNAME  X7DWE.
          NextCloud IN CNAME  X7DWE.
          switch IN A  192.168.0.253
          p1 IN A  192.168.0.22
          p2 IN A  192.168.0.23
          HS1 IN A  192.168.1.1
          HS2 IN A  192.168.1.69
          AP1 IN A  192.168.0.50
          AP2 IN A  192.168.0.51
          pfsense IN CNAME  6BH3S52.
          VM-Sandbox IN A  192.168.0.110
          ns3 IN CNAME  N5550.**_

          I did try $ORIGIN kc.corp. in the zone custom options, but it threw and error on zone load of Unknown Option.

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