Hostoverrides not working unless setup with the domain part?

[ZPrime]

Yeah, this is blame that should rest on MS, the IE developers, and to some extent, other web browsers that have continued to perpetuate this fallacy.

You have an internal domain of some sort.  IE is being stupid and not showing it in the address bar.  Some of this is compounded by the fact that Windows will also do WINS/NetBIOS lookups for hosts and use those too.  Macs and *nix boxes won't.

storage.yourdomain.whatever is what should be in your override.  Assuming the clients are using DHCP and are being issued the internal domain name, they will then resolve "Storage" silently to "Storage.yourdomain.whatever" and it will Just Work.

you don't need the override at all if "storage" can be setup to use DHCP instead of a static IP and you have "Register DHCP leases in DNS forwarder" checked (and "Register DHCP static mappings in DNS forwarder" if you have static DHCP definitions, which is the "right" way to handle the situation with "storage").

[cmb]

It's not a Windows or IE thing really, it's just how DNS works. It's not a browser thing either, everything that resolves DNS in every widely used OS behaves that way. Macs, Linux and BSD all behave 100% the same as Windows in that regard. It's not a bad thing. I believe it's specified somewhere in DNS RFCs.

It does hide what's really happening unless you know, which leads to confusion like this thread (of which there is one similar to it at least a few times every year here).

[johnpoz]

"You can resolve a hostname without a domain with DNS no problem"

Not sure I agree with that statement, fw1. is fw1 domain off the root . domain which is a FQDN – its a domain off root "."  A FQDN is a full path to root "."

It is not possible to resolve a hostname without a domain in dns -- DNS (domain name system)

You doing a dig for fw1. is just looking in the root domain is all, for the domain fw1 in that context I would call it a domain over a hostname.  Which sure you can assign a IP address to with a A record - but I would still consider it a domain if directly off root "."

Either way yes, if I do a query to pfsense with the fqdn query of pfsense. it answers - same with any other host I have setup with a local domain in host overrides.

if you look in the host file of pfsense you can understand why that is.

[2.1-BETA0][root@pfsense.local.lan]/root(1): cat /etc/hosts
127.0.0.1       localhost localhost.local.lan
192.168.1.253   pfsense.local.lan pfsense
192.168.1.4     2k8r2.local.lan 2k8r2
192.168.1.220   current.local.lan current
192.168.1.97    dvr1.local.lan dvr1

etc..  when I ask pfsense for pfsense. it is looking in its host file and sees pfsense.local.lan pfsense, which is why it resolves pfsense. or fw1., etc.

C:\Windows\system32>dig localhost.

; <<>> DiG 9.9.2-P1 <<>> localhost.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65229
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;localhost.                     IN      A

;; ANSWER SECTION:
localhost.              1       IN      A       127.0.0.1

;; Query time: 24 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Tue Dec 18 08:05:02 2012
;; MSG SIZE  rcvd: 43

So in the above it resolve localhost, but localhost is not in my over rides.  But it is in my host file on pfsense.

[cmb]

What you can do with DNS in full-featured DNS servers, and what DNS is capable of doing and what you can do with dnsmasq (what we use), are a bit different. dnsmasq will resolve a single word hostname that's defined in /etc/hosts without any concept of a domain existing, and DNS resolvers can make such requests. With full-featured DNS servers, like the Windows DNS server example earlier in this thread, it's impossible to add hostnames without first having a domain to add the hostname in. So in those cases it's impossible to configure a non-qualified DNS entry.

In our case, the fact that the hostname and the FQDN are both in hosts is just to do it correctly. It doesn't have to be that way. Throw in a:
192.168.1.5  mytest

and you can resolve "mytest."

mytest.example.com (where example.com is your firewall's domain) will not resolve with that hosts line. That creates a strictly non-qualified A record with only the hostname and no domain at all. dnsmasq can do that, DNS supports that. Many other DNS servers can't do that, but that's just the nature of the implementation rather than a limitation of DNS itself.

[Toasticuss]

So, without appending a '.' at the end of the names to allow the names to be resolvable, is there any way I can get hosts to resolve by custom names like Server 2008? I am not interested in editing host files on clients…

If I've understood correctly reading the previous posts, MS isn't following DNS standards and the single host names are not supposed to be resolvable in browsers unless they have the root '.' ending the word?

I have in my domain name overrides the hostname and then the domain name of pfsense but it cannot resolve the name. The computer has the router as the DNS server.

I apologize for my complete lack of understanding this, I'm just trying to get the entire picture…

[cmb]

There's nothing wrong with what your Microsoft DNS server is doing, you're just misunderstanding what it's doing. When you resolve just "pfsense" on the A record you have a screenshot above from Windows, your client machines are actually resolving pfsense.yippy.ath.cx. Their default domain name has to be yippy.ath.cx. The default domain name is usually assigned via DHCP, though it can be statically defined in Windows, it probably isn't. If hosts are in an AD domain, they'll use that domain as their DNS suffix (or should be).

So to resolve names the way you want them to resolve, you either need to:

1. change the firewall's domain to yippy.ath.cx
2. change the clients' domains (usually just by changing your DHCP server's default domain) to whatever the firewall's domain is configured as under System>General Setup.

Either of those two will make the names resolve the way you want them to.

[johnpoz]

Also in a windows network your going to be able to resolve names via broadcast and netbios names (hostname).  This will even work for linux boxes running samba, etc. Or other devices that support netbios

https://support.microsoft.com/kb/172218
Microsoft TCP/IP Host Name Resolution Order

1) The client checks to see if the name queried is its own.
   2) The client then searches a local Hosts file, a list of IP address and names stored on the local computer.
   3) Domain Name System (DNS) servers are queried.
   4) If the name is still not resolved, NetBIOS name resolution sequence is used as a backup.

So for example - I turned off my local dns, If flushed both my local dns cache and my netbios cache.  Now sniffing the traffic while pinging just the hostname you get

You really need to understand how names are resolved in your network.  If your use to just using hostname vs a fqdn, then quite possible in a windows network you were using wins or just broadcasting for the netbios name..

Notice how my printer website came up, even when my dns was off - no response to the query for its fqdn samsung.local.lan - but it did resolve via broadcast.  And yes browser pulls it up with that even.

With dns back on just pinging my printer hostname comes back fully qualified

C:\Windows\system32>ping samsung

Pinging samsung.local.lan [192.168.1.50] with 32 bytes of data:
Reply from 192.168.1.50: bytes=32 time<1ms TTL=255
Reply from 192.168.1.50: bytes=32 time<1ms TTL=255

Because as mentioned multiple times your machine will auto attach its domain to the query.  If you do a nslookup with debug on you will see this.

[Toasticuss]

Hey guys,

Thank you very much for all of your help, I was finally able to get it working right by setting the hostname of pfsense along with the domain name for the host override while making sure that the DHCP server gives out the hostname.domain of pfsense.

[johnpoz]

Your setup is still not correct ;)

You are telling pfsense its in a domain called skynet, but then in dhcp your handing out a domain called pfsense.skynet

If your domain is pfsense.skynet, then the FQDN of pfsense would be pfsense.pfsense.skynet via your dhcp server, but you told it in system that it was pfsense.skynet

So if you boxes use their domain in the search order and you did a query for just pfsense, the client would look for pfsense.pfsense.skynet - which wouldn't be a valid query, unless you created a specific host over ride entry for that.

Not very common that you use a tld only for your domain – use something like skynet.lan as your domain..  So pfsense domain section wuld be skynet.lan

and your dhcp server would hand out skynet.lan

now all your hosts would be in host.skynet.lan

sss.skynet.lan
pfsense.skynet.lan
etc..

[jimp]

Not directly related to the OP in this thread but it's quite similar:

If your upstream DNS does not return NXDOMAIN on failure, but rather returns an IP for its oh-so-helpful (not) search page instead, you can see similar failures to resolve DNS in the expected order.

If you resolve host "www.google.com" (no trailing .) and it tacks on the domain, "www.google.com.example.com" and your upstream DNS returns a response record for that, it will use that IP. OpenDNS does this, so their landing page IP 67.215.65.132 may turn up in your DNS responses.

DNS needs to see the NXDOMAIN to continue the search, so if you can switch off that option in your upstream DNS that's best, failing that, change to an upstream DNS server that does return proper NXDOMAIN records.

Another similar failure can happen if you use wildcard DNS for your domain.