vogelke(_at_)c17mis(_dot_)region2(_dot_)wpafb(_dot_)af(_dot_)mil writes:
On Sat, 19 Jun 1999 14:47:21 +0300 (EET DST),
era eriksson <era(_at_)iki(_dot_)fi> said:
E> I'd love for a portable method to get a host's FQDN.
For what it's worth, the qmail MTA (http://www.qmail.org) contains
several small DNS utilities, one of which is called "dnsfq". Pass in
the hostname, get the FQDN back on stdout. It's in C, so hopefully that
counts as portable.
Pushing an unqualified hostname forward and then backwards through
address queries will not necessarily return an FQDN refering to this
host -- the default domain in the resolv.conf may be different than the
host's domain. My memory says that in the past this was not uncommon
on firewall hosts. Doing reverse lookups on the host's IPs is more
reliable. Anyway, to quote the DNS FAQ:
-----------------------------------------------------------------------------
Question 5.10. Why are fully qualified domain names recommended ?
Date: Sun Nov 27 23:32:41 EST 1994
The documentation for BIND 4.9.2 says that the hostname should be set to
the full domain style name (i.e host.our.domain rather than host). What
advantages are there in this, and are there any adverse consequences if we
don't?
Paul Vixie likes to do it :-) He lists a few reasons -
* Sendmail can be configured to just use Dj$w rather than Dj$w.mumble
where "mumble" is something you have to edit in by hand. Granted, most
people use "mumble" elsewhere in their config files ("tack on local
domain", etc) but why should it be a requirement ?
* The real reason is that not doing it violates a very useful invariant:
gethostbyname(gethostname) == gethostbyaddr(primary_interface_address)
If you take an address and go "backwards" through the PTR's with it,
you'll get a FQDN, and if you push that back through the A RR's, you get
the same address. Or you should. Many multi-homed hosts violate this
uncaringly.
If you take a non-FQDN hostname and push it "forwards" through the A
RR's, you get an address which, if you push it through the PTR's, comes
back as a FQDN which is not the same as the hostname you started with.
Consider the fact that, absent NIS/YP, there is no "domainname" command
analogous to the "hostname" command. (NIS/YP's doesn't count, of
course, since it's sometimes-but-only-rarely the same as the Internet
domain or subdomain above a given host's name.) The "domain" keyword in
resolv.conf doesn't specify the parent domain of the current host; it
specifies the default domain of queries initiated on the current host,
which can be a very different thing. (As of RFC 1535 and BIND 4.9.2's
compliance with it, most people use "search" in resolv.conf, which
overrides "domain", anyway.)
What this means is that there is NO authoritative way to
programmatically discover your host's FQDN unless it is set in the
hostname, or unless every application is willing to grovel the "netstat
-in" tables, find what it hopes is the primary address, and do a PTR
query on it.
FQDN /bin/hostnames are, intuitively or not, the simplest way to go.
-----------------------------------------------------------------------------
Philip Guenther