• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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 Apr 30, 2011, 10:33 AM

    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
    1 out of 1
    • First post
      1/1
      Last post
    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
      This community forum collects and processes your personal information.
      consent.not_received