Hostoverrides not working unless setup with the domain part?

[Toasticuss]

@johnpoz:

How do you think dns would work without the domain part??  This is not WINS, what search domain are you machines setup for?  That would be the domain, then sure you can resolve with just host names.

So I tried to resolve billy – notice the actual query that went out the wire was for billy.local.lan, that is because local.lan is my machines domain and search list

C:\Windows\System32>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : i5-w7
   Primary Dns Suffix  . . . . . . . : local.lan
   Node Type . . . . . . . . . . . . : Broadcast
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : local.lan

So it would add local.lan to the dns request.  It is NOT possible to resolve storage via dns, that is not a FQDN (fully qualified domain name).  So what is the FQDN your actually searching for, and then it would work just fine.

If you want to resolve via just hostname, then put that in your host file on the machine your wanting to resolve it from.

So there is no way to set it up like a Windows Server DNS A records?

[SeventhSon]

@Toasticuss:

how can I make it so that just single words resolve to a local IP address?

Am I missing a really simple option that allows this?

I use the DHCP Server's entries to resolve internal IPs together with the "Register DHCP leases in DNS forwarder" and "Register DHCP static mappings in DNS forwarder" in the DNS Forwarder settings.

[johnpoz]

"So there is no way to set it up like a Windows Server DNS A records?"

Dudes its just like windows DNS, its just your putting all the A records into the Zone file.. Post your DNS setup on windows that is only a host name.

example - see my local zone just created in windows..  See the 2k8r2 host file, its part of gthe local.lan zone.  So if I create a new host, it auto adds the zone for you.  Depending what zone you put it in.

[Toasticuss]

@johnpoz:

"So there is no way to set it up like a Windows Server DNS A records?"

Dudes its just like windows DNS, its just your putting all the A records into the Zone file.. Post your DNS setup on windows that is only a host name.

example - see my local zone just created in windows..  See the 2k8r2 host file, its part of gthe local.lan zone.  So if I create a new host, it auto adds the zone for you.  Depending what zone you put it in.

That's not what I am going for….

I am looking to make a single word A record to be able to be resolved with client browsers like this -

Here I have an A record with just the word pfsense

If I now type in just the word pfsense into the browser it will take me to the IP address associated with it, like so -

If I attempt to do that same thing with the DNS override I have to have a root domain on it like this in order for it to work otherwise I get this -

However with the root domain part in it comes back fine.

Heres what the pfsense dns forwarder looks like -

Here is a ping prompt trying to resolve the two -

Windows Server can resolve the host name perfectly fine without a root domain in it unlike pfsense which will just give 404 pages.

[cmb]

@Toasticuss:

Here I have an A record with just the word pfsense

No you don't. You have an A record of pfsense.yippy.ath.cx. Your machine's domain has to be yippy.ath.cx to resolve just "pfsense" to what you have there.

When you put in a hostname in the DNS forwarder without a domain, it really is just a hostname with no domain. You can resolve a hostname without a domain with DNS no problem. For instance, my firewall's hostname is fw1.

$ ping fw1
PING fw1 (172.27.0.2): 56 data bytes

My Mac has no default domain on the network it's currently on, so it does a DNS lookup strictly for fw1. If it had a default domain of example.com, it'd do that DNS lookup for fw1.example.com.

Can confirm with dig what it's actually resolving:

$ dig fw1
<snip>;; ANSWER SECTION:
fw1. 1 IN A 172.27.0.2

On Windows, do a "nslookup pfsense." against the DNS forwarder and you'll get the correct response. The . at the end is required, that keeps it from appending its default domain.

Another example from within nslookup on Windows:

server 192.168.1.1
Default Server:  [192.168.1.1]
Address:  192.168.1.1

fw1
Server:  [192.168.1.1]
Address:  192.168.1.1

*** [192.168.1.1] can't find fw1: Non-existent domain

fw1.
Server:  [192.168.1.1]
Address:  192.168.1.1

Name:    fw1
Address:  192.168.1.1

It doesn't work without the . at the end because Windows appends the host's default domain (let's say it's example.com), which is different from the firewall's default domain. The first looks up fw1.example.com, which doesn't exist. The second looks up "fw1" only, and responds.</snip>

[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.