DNS Forwarder headache



  • I'm having trouble with having DNS Forwarder working properly. Internal Web-server nameresolving is giving me a big fat headache ???

    Okay my config;

    Firewall: NAT: Port Forward (just mentioning webserver)

    WAN 	TCP 	80 (HTTP) 	CentOSServerVirtual
    (ext.: any) 	80 (HTTP) 	WAN --> LAN CentOSServerVirtual TCP http
    
    
    • System: General Setup –> Manual to DNS-servers (OpenDNS), local domain myradon.net and "Allow overrride by wan-dhcp..." ticked disable

    • Services: DNS forwarder –> tried enable/ disable "Register DHCP leases in DNS forwarder" and "Register DHCP static mappings in DNS forwarder". currently all hosts "by You may enter records that override the results from the forwarders below." So hostname, domain, IP and description

    When i want to connect to internal webserver first time it resolves internal-IP and voila server serves website. Do a "Reload current page" and can't find webserver anymore.
    I flushed local DNS-cache and ping the webserver;

    
    ping centosservervirtual.myradon.net
    PING centosservervirtual.myradon.net (192.168.1.136): 56 data bytes
    64 bytes from 192.168.1.136: icmp_seq=0 ttl=64 time=0.444 ms
    
    

    Then I reload the page in the webbrowser several times and ping webserver again. This is what happens

    
    ping centosservervirtual.myradon.net
    PING pfsense.myradon.net (192.168.1.129): 56 data bytes
    64 bytes from 192.168.1.129: icmp_seq=0 ttl=64 time=0.298 ms
    
    

    The LAN-interface of pfSense is replying :P!!!!!

    I looked into the "pfSense - The Definitive Guide" and followed some steps concerning DNS Forwarder, which already where provisioned right. When I thick-off "Disable NAT Reflection" so Disable is Disabled I can reach the webserver without a problem. But servers on "The Internets ;)" are gone, just as stated in some topics on this forum.

    Can anybody explain me what is causing this odd behavior?!

    I'm trying to replicate this problem by doing the same steps on my Ubuntu Laptop. Guess what happens; nothing it works like it supposed to. Going back to my Hack OSX and …. same problem. It's getting stranger;

    This is my Services: DNS forwarder

    
    centosservervirtual  	myradon.net  	192.168.1.136  	CentOS Server virtualGuest on hackintosh  	
    debianmobile  	myradon.net  	192.168.1.145  	Debian Lenny Server i386 virtualGuest on laptop Haley  	
    ftp  	myradon.net  	192.168.1.136  	CentOS Server virtualGuest on hackintosh  	
    haley  	myradon.net  	192.168.1.131  	Ubuntu Laptop  	
    mercury  	myradon.net  	192.168.1.130  	Mercury Hackintosh  	
    www  	myradon.net  	192.168.1.136  	CentOS Server virtualGuest on hackintosh  
    
    

    I flushed local DNS before following steps
    1. Reload webpage, server is responding. Then couple of times reload…........... no response from webserver.
    2. Pinging centosservervirtual in OSX-terminal and pfsense LAN-address 192.168.1.129 replies
    3. Pinging www and 192.168.1.136 replies as supposed to



  • I suggest you use a tool like nslookup or dig on your system with the erratic behaviour to see if its asking (sometimes?) the wrong nameserver.



  • Okay.. I did a dig and nslookup for host www, ftp, centosservervirtual these actually are 1 internal ip. IP is resolved correctly.

    1. Initially ping centosservervirtual host is also is ok; IP 192.168.1.136. BUT when I do several reloads in Firefox webserver isn't responding. Okay do a ping to centosservervirtual and pfsense LAN-interface is responding. A dig or nslookup in Terminal or using Network utility resolves Host to IP correctly.

    2. ping www host is and FQDN www.myradon.net are also ok; IP 192.168.1.136. Several reloads fired in Safari. then a ping to www and pfsense LAN-interface is responding. nslookup still gives the proper IP-address.

    So it doesn't seem to be a Name resolution thing. For some strange reason pfSense is responding as host. It seems to be Mac OSX-system, because restart of dnsmasq service doens't influence strange behavior. Only clearing (by sudo dscacheutil -flushcache ) local DNS-cache will solve the problem. How could a client get a wrong entry in it's DNS-cache?

    I trying to pinpoint problem but it doesn't become clear. DNS-queries also slowdown. Refreshing this topic got screen from OpenDNS because can't find domain. internal FQDN-query will forwarded to OpenDNS-server but is is an internal host :P :P



  • What's the server(s) do you give the clients, just pfSense, or maybe an external dns as well?



  • I checked OSX (network preferences) and Ubuntu (etc/resolve.conf) both get pfsense's LAN-interface as DNS-server. Switched OpenDNS-server for Google's. Same trouble Asking for www.myradon.net and Google responds in webbrowser "Can't find…........"

    Okay Seems to be a DNSmasq problem. I Installed Firefox Show-IP addon. When stuff goes wrong browser tries to connect to IP of LAN-interface pfSense (192.168.1.129). When I restart service DNSmasq the correct IP pops up in Firefox (192.168.1.136), but webserver still can't be approached because DNS-cache locally is still having the wrong entry. So clearing DNS-cache does the trick.

    so the 1 million-dollar-question to you skilled guys; What's happening?



  • @jambek2003:

    Okay Seems to be a DNSmasq problem. I Installed Firefox Show-IP addon.

    Given your earlier report that you don't see the quirky behaviour on Ubuntu, it would seem more likely to me to be something quirky on the Mac.



  • nslookup centosservervirtual.myradon.net
    Server:	192.168.1.129
    Address:	192.168.1.129#53
    
    Name:	centosservervirtual.myradon.net
    Address:   192.168.1.136
    
    dscacheutil -q host -a name centosservervirtual.myradon.net
    name: pfsense.myradon.net
    alias: centosservervirtual.myradon.net 
    ip_address: 192.168.1.129
    
    

    It's an OSX-thing! http://discussions.apple.com/thread.jspa?threadID=2140119&start=45&tstart=0 Is a discussion about DNS and internal name resolution. I'm going to dive into that and hopefully post the sollution here.


Log in to reply