Re: Beth Frank: Question about Host

Beth Frank writes:
> Roy said:
> > 
> > On the other hand, it seems that the WG has reached rough consensus
> > on defining the 
> > 
> >     Host: fully.qualified.domain.name
> > 
...
> Support for Host: will be included in the next release of NCSA HTTPd (Release
> 1.5B6 which is not yet available).  Our current implementation mirrors that of
> the virtual server (using multiple IP addresses).  We've talked with the client
> people and they are open to supporting but we ran into a problem in the
> implementation.
> 
> The clients often get URLs without fully quailified domain names.  They
> do a DNS lookup and get an IP address.  If they then do an IP to name
> lookup, for an IP address with multiple names, it's not clear what
> they get back.  So what should they be putting in the Host: field?
> 
> 	1) the non-fully qualified name (eg. sdg, instead of sdg.ncsa.uiuc.edu)
> 	2) or the IP address,
> 	3) or whatever is returned from the DNS name lookup of the IP address?
> 
> If we go with 2 or 3, we're no better off than before.
> If we go with 1, a non-fully qualified address, that's more overhead for
> 	the server to recognize a non-fully qualified names.
> 
> We (server & client side) prefer 1.  That provides the most information, but
> will make server processing harder.
> 
> The client people strongly oppose 3, because no additional information is
> provided and you're making the client pay the penalty of 2 DNS lookups.
This is an important point.
Really we have 2 choices:
a. allow non-fqdn hostnames
b. require fqdn, as proposed
[analisys]
a. the resolver at the client and at the server can have different
configuration. (And probably will be different.)
If I have DNS search path set to a.aa b.a.aa, while the server has
b.a.aa a.aa
lookup for www will result www.a.aa on the client and www.b.a.aa on the server
(assuming www.a.aa and www.b.a.aa both exists)
If www.a.aa and www.b.a.aa both point to the same IP address - to our virtual
multihome server - we are in trouble.
Not too good.
b. When the client does gethostbyname, gets all registered names of the 
requested host. Knowing the DNS search path, the client can find the
fqdn, which resulted the match by duplicating the search without any additional
DNS lookup - cycling through the search path.
There is my 'first hack' perl code for this:

# the subroutine
sub getfqdn {
  ($name,$aliases,$addrtype,$len,@addrs)=gethostbyname(@_[0]);
  foreach $i (@search)
  {
    $k=@_[0];
    $k.='.'.$i unless $i eq ''; # the first time this is true
    foreach $j ($name,$aliases)
    {
      printf STDERR "%s %s\n",$k,$j if $debug;
      return $k if $k eq $j;
    }
  }
}
# initialisation
open(RESOLV,"/etc/resolv.conf");
$dnspath='';
while(<RESOLV>)
{
  if(m/^search (.*)$/oi)
  {
    $dnspath .= ' '.$1;
  }
}
close(RESOLV);
# ugly, this needs a more general handling
$dnspath=' bne.ind.eunet.hu ind.eunet.hu eunet.hu' if $dnspath eq '';
# note, the 0th element will be a null string
@search=split(/\s+/,$dnspath,9999);
# the test
printf "%s %s\n",$ARGV[0],&getfqdn($ARGV[0]); 

*nix* users will see, that this works.
Likely we have no problem at all.

Unfortunately, the problem still exists:
There may be problems, if the client not knows, where to get the DNS
search path. Under Linux I have the necessary man pages, and on all *nix*
systems there is a standard place and file format documented.
Writers of WINDOWS clients have less comfort, because in windows there is
no standard place and format defined for resolver configuration file.

And now I don't know, what to say. (Only if I dont want to blame MicroSoft.)
(But blaming MicroSoft will not help.)

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

Received on Friday, 29 September 1995 19:11:58 UTC