-1

What is the proper way to configure a BIND9 zone file to allow ping/dig/nslookup/web browsers to query a host using its hostname or a shortened CNAME record that points to this hostname instead of the entire fqdn of the host.

Example: This works.

dnsadmin@tre-lfs4:~$ dig fs.domain.org
; <<>> DiG 9.10.3-P4-Ubuntu <<>> fs.domain.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3925
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;fs.domain.org.           IN      A
;; ANSWER SECTION:
fs.domain.org.    38400   IN      CNAME   tre-lfs1.domain.org.
tre-lfs1.domain.org. 38400 IN     A       10.30.0.31

From this zone file entry:

tre-lfs1.domain.org.    IN  A   10.30.0.31
fs.domain.org.  IN  CNAME   tre-lfs1.domain.org.

I want to be able to do this:

nslookup/ping/dig fs

With a zone file entry that looks more like this:

tre-lfs1.   IN  A   10.30.0.31
fs. IN  CNAME   tre-lfs1.

So that I can both use the entire FQDN OR just the shortened hostname/cname.

The reason is that I may have the same machine hosting web and other services for different domains, but when locally administering I want to just use the short names.

Anyone know how to achieve this or a resource to look to in order to do so?

RtmY
  • 277
  • 2
  • 9
thursDave
  • 55
  • 1
  • 1
  • 5

1 Answers1

2

The ability to use a short name for a host rather than it’s FQDN is a ”trick” performed on the client side and that is not something that can be configured or managed on a name server.

In the client one or more search domains can be configured that will get appended to unqualified hostnames (hostnames without a dot .)

When you configure the search domains example.com and example.org and try to resolve the host fs and if that fails the dns client will then try to see if by appending the search domain it does get a result, I.e. the client will then try if the FQDN fs.example.com. resolves and if that fails it will try to resolve fs.example.org.

HBruijn
  • 72,524
  • 21
  • 127
  • 192
  • 2
    Warning: Relying on search domains is not recommended as it can result in [unexpected behavior](https://serverfault.com/q/626612/126632) if you are connected to the Internet and for some reason the search domains change or become unconfigured. It's best practice to always use FQDNs everywhere. – Michael Hampton Mar 20 '19 at 01:02
  • @HBruijn so the search domain that my DHCP server is assigning to my clients is what is determining the resolution of shortnames to fqdn? that kind of makes sense, because i seem to have had this issue where i was able to resolve to some search domains but not others, likely because DHCP was assigning one search domain and if i were to search for hostname 'mail' that through CNAME points to another search domain not assigned through DHCP but through the BIND9 server, then the client wouldn't know that mail was pointing to example.org and not the example.com domain DHCP was assigning. – thursDave Mar 20 '19 at 13:07
  • @MichaelHampton, you are correct it seems. since i am really going for a pure-BIND9 environment, i just need to get used to using FQDN to navigate my network. – thursDave Mar 20 '19 at 13:07
  • 1
    @dnsdave : *"so the search domain that my DHCP server is assigning to my clients is what is determining the resolution of shortnames to FQDN's?"* - Yes indeed. – HBruijn Mar 20 '19 at 13:12
  • 1
    This ICANN report gives a lot of details about dotless domains: https://www.icann.org/en/system/files/files/sac-053-en.pdf – Patrick Mevzek Mar 21 '19 at 00:38