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

    Reverse DNS works for windows clients, not linux clients.

    Scheduled Pinned Locked Moved DHCP and DNS
    1 Posts 1 Posters 2.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
      Criggie
      last edited by

      I've got pfsense 1.2.3 running fine at home.  However this DNS problem has been bugging me for ages, and I finally got down to working on it.

      1. All clients can do DNS forward lookups of LAN clients without a problem
      2. A windows client can do a reverse DNS lookup of a LAN or internet IPs okay.
      3. But a linux box can't do a reverse DNS lookup of LAN or internet IPs

      I'm using a hostname of xppropv which resolves to 10.28.1.5 fine, for all clients.

      Here's a tcpdump from the firewall of a windows client doing a lookup of 10.28.1.5 (using nslookup with server set to firewall)

      # tcpdump -i fxp0 port 53 and udp and host xppropv
      listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
      21:45:49.212060 IP xppropv.criggie.dyndns.org.cadsi-lm > pfsense.criggie.dyndns.org.domain: 2+ A? xppropv.criggie.dyndns.org. (44)
      21:45:49.213498 IP pfsense.criggie.dyndns.org.domain > xppropv.criggie.dyndns.org.cadsi-lm: 2* 1/0/0 (60)
      21:45:58.796600 IP xppropv.criggie.dyndns.org.objective-dbc > pfsense.criggie.dyndns.org.domain: 3+ PTR? 5.1.28.10.in-addr.arpa. (40)
      21:45:58.797844 IP pfsense.criggie.dyndns.org.domain > xppropv.criggie.dyndns.org.objective-dbc: 3* 1/0/0 PTR[|domain]
      
      

      Here's a linux box doing the same thing using the dig command

      # tcpdump -i fxp0 port 53 and udp and host thionite
      listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
      21:46:12.548521 IP thionite.criggie.dyndns.org.52028 > pfsense.criggie.dyndns.org.domain: 59925+ A? fw.criggie.dyndns.org. (39)
      21:46:12.548874 IP thionite.criggie.dyndns.org.52028 > pfsense.criggie.dyndns.org.domain: 33806+ AAAA? fw.criggie.dyndns.org. (39)
      21:46:12.549765 IP pfsense.criggie.dyndns.org.domain > thionite.criggie.dyndns.org.52028: 59925* 1/0/0 A[|domain]
      21:46:12.550127 IP pfsense.criggie.dyndns.org.domain > thionite.criggie.dyndns.org.52028: 33806 0/0/0 (39)
      21:46:12.551512 IP thionite.criggie.dyndns.org.35333 > pfsense.criggie.dyndns.org.domain: 36816+ A? 10.28.1.5\. (27)
      21:46:12.552307 IP pfsense.criggie.dyndns.org.domain > thionite.criggie.dyndns.org.35333: 36816* 1/0/0 A xppropv.criggie.dyndns.org (43)
      
      

      Notice the linux box is asking for an A record for an IP address, and that it IS being given the right answer.

      Finally, the firewall itself ignores the correct answer from itself when doing a dig to localhost.  Huh?!

      # tcpdump -i lo0 port 53 and udp
      listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes
      22:24:14.099187 IP localhost.56059 > localhost.domain: 50652+ A? 10.28.1.5\. (27)
      22:24:14.100443 IP localhost.domain > localhost.56059: 50652* 1/0/0 A xppropv.criggie.dyndns.org (43)
      
      

      Here's what that command looks like in another session:

      # dig 10.28.1.5 @localhost
      
      ; <<>> DiG 9.4.3-P2 <<>> 10.28.1.5 @localhost
      ;; global options:  printcmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50652
      ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
      
      ;; QUESTION SECTION:
      ;10.28.1.5.                     IN      A
      
      ;; ANSWER SECTION:
      10.28.1.5.              0       IN      A       10.28.1.5
      
      ;; Query time: 3 msec
      ;; SERVER: 127.0.0.1#53(127.0.0.1)
      ;; WHEN: Sat Apr 30 22:24:14 2011
      ;; MSG SIZE  rcvd: 43
      
      # 
      

      To clarify - this affects reverse lookups of internet IPs too
      So my question is - why are hosts ignoring the answers given out by pfsense?

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