procmail
[Top] [All Lists]

Re: Finding FQDN

1999-06-21 15:54:36
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

<Prev in Thread] Current Thread [Next in Thread>