Navigation

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

    Query DNS from NON LAN interface?? Not reporting the domain name of the firewall

    DHCP and DNS
    2
    8
    1396
    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.
    • S
      Supermule Banned last edited by

      Using nslookup from LAN will report the domainname of the firewall.

      Doing it from DMZ or any other physical interface will report unknown.

      Why??

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

        So I have multiple segments lan, wlan, dmz, etc..  And doing a query reports just fine.

        How exactly are you doing a query?

        user@uc:~$ nslookup pfsense.local.lan
        Server:        192.168.2.253
        Address:        192.168.2.253#53

        Name:  pfsense.local.lan
        Address: 192.168.9.253

        example this is query from my unifi controller box that is on 192.168.2.0/24 while my lan is on 192.168.9.253

        Are you doing a query without domain and just letting suffix search work?  What OSes are you doing the queries from?  Do you not have dns listening on the pfsense interface in that segment?

        1 Reply Last reply Reply Quote 0
        • S
          Supermule Banned last edited by

          Just the nslookup

          Nothing else.

          @Supermule:

          Using nslookup from LAN will report the domainname of the firewall.

          Doing it from DMZ or any other physical interface will report unknown.

          Why??

          @johnpoz:

          So I have multiple segments lan, wlan, dmz, etc..  And doing a query reports just fine.

          How exactly are you doing a query?

          user@uc:~$ nslookup pfsense.local.lan
          Server:        192.168.2.253
          Address:        192.168.2.253#53

          Name:  pfsense.local.lan
          Address: 192.168.9.253

          example this is query from my unifi controller box that is on 192.168.2.0/24 while my lan is on 192.168.9.253

          Are you doing a query without domain and just letting suffix search work?  What OSes are you doing the queries from?  Do you not have dns listening on the pfsense interface in that segment?

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

            what does just nslookup mean?

            I showed you just using nslookup..  So lets see example of when it works and when it doesn't work.  Because its the same database/files that records are pulled from - does not matter what interface you do the query too.  You sure your ones that are not working are doing query to pfsense, and not say for example google dns?

            1 Reply Last reply Reply Quote 0
            • S
              Supermule Banned last edited by

              2 interface pfsense with LAN and DMZ

              LAN is 172.16.1.1 and DMZ is 10.255.1.1

              It says unknown on DMZ to the nslookup command.

              Both interfaces are using the interface IP adress as DNS since pfsense uses DNS resolver and manages DNS internally.


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

                Now I understand what your talking about ;)  That is just because you have no ptr setup for that IP..

                But that really is not a big issue.. What I do that adds ptr record is create over rides for the other interfaces.

                So for example pfsense.local.lan is my normal lan 192.168.9.253 interface, then for the others say wlan segment I make pfsense.wlan.local.lan  so if I do a ptr on that

                C:>dig -x 192.168.2.253

                ; <<>> DiG 9.10.2-P2 <<>> -x 192.168.2.253
                ;; global options: +cmd
                ;; Got answer:
                ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60562
                ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

                ;; OPT PSEUDOSECTION:
                ; EDNS: version: 0, flags:; udp: 4096
                ;; QUESTION SECTION:
                ;253.2.168.192.in-addr.arpa.    IN      PTR

                ;; ANSWER SECTION:
                253.2.168.192.in-addr.arpa. 3600 IN    PTR    pfsense.wlan.local.lan.

                ;; Query time: 4 msec
                ;; SERVER: 192.168.9.253#53(192.168.9.253)
                ;; WHEN: Wed Jul 22 06:31:46 Central Daylight Time 2015
                ;; MSG SIZE  rcvd: 91

                This way windows clients that do a ptr query for your dns will resolve.

                1 Reply Last reply Reply Quote 0
                • S
                  Supermule Banned last edited by

                  You need to walk me through that since DNS resolves fine on the servers but the hostname reported on DMZ shows unknown instead of firewall name.

                  The reverse DNS works fine from LAN but not from DMZ.

                  In unbound I cant determine where to put the reverse record.

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

                    You could create an reverse.. But its just easier to create another record for your other interfaces IPs.

                    So for example I have this

                    lan - pfsense.local.lan 192.168.9.253
                    wlan - pfsense.wlan.local.lan 192.168.2.253
                    dmz - pfsense.dmz.local.lan 192.168.3.253

                    See attached over rides screenshot

                    When you query ptr of 192.168.9.253 I get lan, when I query any of the others I that forward name - tells me for example which segment I am on.

                    C:>dig -x 192.168.9.253 +short
                    pfSense.local.lan.

                    C:>dig -x 192.168.2.253 +short
                    pfsense.wlan.local.lan.

                    C:>dig -x 192.168.3.253 +short
                    pfsense.dmz.local.lan.

                    C:>dig -x 192.168.4.253 +short
                    pfsense.wlanguest.local.lan.

                    C:>dig -x 192.168.5.253 +short
                    pfsense.ps3.local.lan.

                    Different IPs should really have different names..  You wouldn't want all of pfsense interface IPs to return just pfsense.whatever.tld would you?  Isn't it better to give back a name that tells you what interface it is.

                    But if you really just want a PTR for the other IPs pointing to the same name.. Just create one in the advanced section - see 2nd pic

                    local-data-ptr: "1.2.3.4 pfsense.local.lan"




                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post

                    Products

                    • Platform Overview
                    • TNSR
                    • pfSense
                    • Appliances

                    Services

                    • Training
                    • Professional Services

                    Support

                    • Subscription Plans
                    • Contact Support
                    • Product Lifecycle
                    • Documentation

                    News

                    • Media Coverage
                    • Press
                    • Events

                    Resources

                    • Blog
                    • FAQ
                    • Find a Partner
                    • Resource Library
                    • Security Information

                    Company

                    • About Us
                    • Careers
                    • Partners
                    • Contact Us
                    • Legal
                    Our Mission

                    We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                    Subscribe to our Newsletter

                    Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                    © 2021 Rubicon Communications, LLC | Privacy Policy