Bogus lookups return external IP

freakalad

I've sat with this issue for a while, but because it's been more annoying than critical, I not had much reason to rock the boat.
If I'm unable to resolve this issue, I may be forced to rebuild my pfSense host, which I'd like to avoid if possible (as you can imagine; the box has been serving me fairly-well otherwise for a stretch now).

If I lookup an external DNS value, i.e. ping/nslookup/host foo.bar, it returns my external IP, so effectively bogus/incorrect DNS values never fail.
My pfSense box (1.2.3-RELEASE) is effectively the DNS for my LAN (as well as serving up DHCP), in the [General Setup] section I've provided my ISP & Google's DNS (8.8.8.8) as upstream servers for my pfSense host (firewall/gateway/proxy/etc) to resolve against.

I am able to telnet into my DSL modem (running a BusyBox variant) & SSH into my pfSense host.
When I ping/lookup foo.bar from my firewall, it returns my external IP, but if I do the same from the modem the resolution fails (as it should).

For the various lookups, I get the following:
(1.2.3.4 being a proxy for my external IP)
(I.S.P being a proxy for my ISP)
(F.Q.D.N being my own domain on the LAN & from outside so that I can access services)
(10.0.0.1 is the real LAN IP of my pfSense box - LAN runs on 10.0.0.0/24)

nslookup foo.bar


Server:	10.0.0.1
Address:	10.0.0.1#53

Non-authoritative answer:
Name:	foo.bar.F.Q.D.N
Address:   1.2.3.4

ping foo.bar


PING foo.bar.F.Q.D.N (1.2.3.4) 56(84) bytes of data.
64 bytes from ip-1-2-3-4.static-xdsl.I.S.P (1.2.3.4): icmp_req=1 ttl=63 time=2.34 ms
..etc....

host -v foo.bar


Trying "foo.bar"
Received 25 bytes from 10.0.0.1#53 in 2 ms
Trying "foo.bar.F.Q.D.N"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41356
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;foo.bar.F.Q.D.N.		IN	A

;; ANSWER SECTION:
foo.bar.F.Q.D.N.	480	IN	A	1.2.3.4

Received 51 bytes from 10.0.0.1#53 in 2 ms
Trying "foo.bar.F.Q.D.N"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61348
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;foo.bar.F.Q.D.N.		IN	AAAA

;; AUTHORITY SECTION:
F.Q.D.N.		300	IN	SOA	ns1.nameserver.net.nz. soa.nameserver.net.nz. 2011052646 10800 1800 1209600 300

Received 94 bytes from 10.0.0.1#53 in 440 ms
Trying "foo.bar.F.Q.D.N"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30924
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;foo.bar.F.Q.D.N.		IN	MX

;; AUTHORITY SECTION:
F.Q.D.N.		300	IN	SOA	ns1.nameserver.net.nz. soa.nameserver.net.nz. 2011052646 10800 1800 1209600 300

Received 94 bytes from 10.0.0.1#53 in 391 ms

jimp

Do you have your domain set to your dyndns domain?
Does your dyndns domain have wildcard enabled?

I've seen this happen in that specific circumstance.

Try ending hostnames with a period when you use tools like host/dig.

like:

host foo.bar.

freakalad

Thanks for the tip, jimp

I'm not making use of a DynamicDNS service, but have a few domains registered with a registrar pointing to my static-IP.

As for your suggestion re ending lookups with a period, it seems to have the effect I wish (which is the result I want even if I don't terminate with a period).

So ping **foo.bar** (or nslookup or host) still returns my external IP, but ping **foo.bar.** comes back null.

This would lead me to believe there may be something hinky in my pfSense's DNS service/daemon; as best I'm aware I'm not making use of any additional DNS services (beyond the default installation) that could've caused this.

My current crop of packages are:

Dashboard
Proxy Server with mod_security (experimenting with a WAF; it's the OWASP-thing to do)
bandwidthd
darkstat
phpSysInfo
rate

Does this information provide any additional insight?

jimp

Well it may not be a Dynamic DNS service, but just regular wildcard DNS. If your provider is returning everything requested with your domain to your IP, it would have the same effect.

With the dot, try:

host thisdoesnotexist.mydomain.com.

If that also returns your WAN IP, it's whoever is hosting the mydomain.com zone that is to blame for using wildcard DNS.

What you are seeing is proper DNS behavior. A FQDN ends with a dot when used like that. With no trailing dot, it first tries to append your domain when looking up the host, assuming it's a hostname and not a FQDN. In this case, the hostname looking using the search domain returns an answer, so that is given.

It may be unexpected, but it's normal in that case.

freakalad

Thanks or the clarification, jimp.
I'll try to use it in this correct manner in future, thanks.

As for:
host -v thisdoesnotexist.mydomain.com. ,
it actually does exists & the name resolution returns 216.34.94.184 (pop the address in a browser & it returns the MyDomain registrar's landing-page)
That's why I've been using foo.bar as a bogus DNS value.

As best I can tell, when I do a host -v lookup on my own (primary) domain, everything looks in order.

I'm also running a reverse-proxy on my network, so that I can redirect HTTP(s) requests for multiple domains & sub-domains fairly easily to different hosts.
I'm not sure that that could cause such issues, but I'm just throwing it in there for reference-sake.