88217 - default domain (domain suffix appended to non-FQDN hostnames)

Status: RESOLVED WONTFIX

(Core :: Networking, enhancement)

Description

[benc]

The default domain (domain suffix appended to non-FQDN hostnames) should be
configurable. This would be much more useful than the existing
www.<HOSTNAME>.com and requested www.<HOSTNAME>.[org|net|edu] features.

DCHP does support configuring this:

3.17. Domain Name

http://www.faqs.org/rfcs/rfc2132.html

   This option specifies the domain name that client should use when
   resolving hostnames via the Domain Name System.

   The code for this option is 15.  Its minimum length is 1.

    Code   Len        Domain Name
   +-----+-----+-----+-----+-----+-----+--
   |  15 |  n  |  d1 |  d2 |  d3 |  d4 |  ...
   +-----+-----+-----+-----+-----+-----+--

However, many DHCP servers do not seem to use this, and often I want to override
 it.

Comment 1

[Boris Zbarsky [:bzbarsky]]

there's already a bug filed to make this configurable, but I can't find it at
the moment (it may well be WONTFIX).

Comment 2

[Darin Fisher]

benc: i'm not sure i understand what you are proposing.  DHCP is not always
available, and when it is, how does it help us choose a hostname domain suffix?

are you suggesting that if the DHCP server specifies a domain name with a 
suffix of XYZ that we should assume a suffix of XYZ when a user enters a hostname
without a domain suffix?

i agree that it would be nice to have a preference someplace for users to tell
mozilla what the default hostname domain suffix should be, but i'm not sure i 
like the idea of some auto detection method based on DHCP.

Comment 3

[Chris Schanck]

The DHCP discussion is a bit of a red-herring. If I work at foo.com, and I type
in a URL http:/web/, I expect it to let the os resolve it to web.foo.com.
Currently, Moz tries to be clever and turns http://web/ into http://www.web.com/
-- emphatically NOT the same thing. This breaks the corporate intranet at both
my current and previous jobs. Essentially disallows me from using Moz at all.

I know the www.<HOSTNAME>.com stuff is clever and all, but it needs to be
configurable so that Moz at least tries the default domain at some point!

Comment 4

[Todd Knarr]

I think what the original requestor is asking for is to
have hostnames resolved per the standard resolver configuration,
eg. if I have my resolver configured to a default domain of 'xyz.bar'
and enter hostname 'foo', Mozilla should simply give 'foo' to the
resolver and let it resolve it to 'foo.xyz.bar', not try to get cute
and equate 'foo' to 'www.foo.com'.

Short form: the URL http://foo/ should go to the same host as would
be pinged by 'ping foo' at a command/shell prompt in the OS in question.

Comment 5

[Chris Hiner]

At least on Linux, it appears to work as requested, using the domain info in
/etc/resolv.conf.  If I enter "intranethost", it goes to the right place.  If
I'm directly connected to the internet, then it can't go there, so it tries to
go to "www.intranethost.com".

Comment 6

[benc]

I'm saying that I (the user) should be able to set default domain in a profile.

Despite the fact that the OS, the shell, and DHCP being able to provide this
information, it often isn't the default domain I want to use for URL's with
hostnames.

I think some of the comments that I made in bug 88218 are relevant here. Please
look at those, because this RFE fits in with a larger change in networking
philosophy of Mozilla I am proposing.

DHCP can provide a default domain, but I often see that DHCP administrators did
NOT configure this (for example, our corporate dialup at Netscape neglected to
do this).

chris:

I belive the actual behavior is that your hostname is sent to the resolver, so
if your resolver has a default domain or search domains, they are checked. THEN,
if that fails, mozilla autoamatically uses that "www.<hostname>.com" query that
I dislike so much.

My point is that a user should be able to override the system system whether
that is resolv.conf, DHCP, or an environment variable (in UNIX, rarely used, but
its there).

Comment 7

[Chris Schanck]

benc, you're right about the usefulness of being able to direct Moz with what
domain to use -- but I see that as a true RFE. 

At least on Solaris 2.8 and Debian testing, with a properly configured
/etc/resolv.conf (domain foo.com,search foo.com), http://web/ does NOT resolve
to web.foo.com as it does when I ping it. This is using 9.1, pulling the
binaries off of the website. This seems to me to be a bug, more than an RFE. But
I'd rather wait a bit before opening another bug. 

Comment 8

[benc]

I'm starting to feel like I don't even know what mozilla is "supposed" to do
anymore... does anyony know where the existing docs are?

Comment 9

[Jeremy M. Dolan]

This is the job of the resolver. Any sane OS (and Windows) provides a way to do
this, and if they don't you should take up with them rather then bloat Mozilla
by trying to make it a resolver library.

Since I'm only familiar with UNIX, I'll explain how this works on that platform.
An application ("Mozilla") passes any input it needs to resolve to a function
like gethostbyname(). It doesn't matter whether it's "foo" or "www.yahoo.com".
The resolver checks one of it's configuration files (commonly /etc/resolv.conf)
for the search path (there can be multiple). It then talks to the DNS server
it's configured to use, and asks for the IP of foo.search1. Then foo.search2.
Then just foo. If a user doesn't like the system defaults, they set the
enviroment variable "LOCALDOMAIN" to whatever they want their search path to be.
If you want "yahoo" in the URL bar to go to a particular famous website, set
LOCALDOMAIN to "com". It's not the applications place to be fiddling with any of
that.

There IS an open bug about making some key combination change 'foo' to
www.foo.com in the URL bar (shift+enter maybe), but to do it automatically sends
kids looking for information on the whitehouse to a porn site.

If multiple search engines were implemented (bug 84908), you could use Google's
"Feeling Lucky" or Netscape's "Keyword" systems to find a site based on input,
but just slaping on .com is NOT the way to try and locate relevant content.

Comment 10

[benc]

No. The job of the resolver is to do name resolution. Resolvers always have (and
always will) support the use of a literal, "." terminated string in the request.

What your are talking about is the search domain and default domain completion
routines that are typical in most resolvers.

Asa said not to hurt your feelings, but history will.

What you are describing is the current "standard" resolver behavior for doing
searches. This has changed over time, I can think of changes in the way MacOS
and Solaris did this for a fact. Most of the information I have on these changes
has to do with the fact that these search methods are really mindless and
wasteful on DNS servers. As the usage paterns of the network change, we can
expect resolver behavior to continue to evolve.

My point is that authors are lazy, and create unclear pointers when they do not
use FQDNs. (This is the same horrible problem we have with serving file: URLs,
and I have a component full of those problems). The point is that the user is
probably aware of and should have the power to set this context. 

Since it is clear that various context changes for default domain do not work
reliabily in many cases, we should certainly offer this feature.

If you don't like it, you won't need to use it.

Comment 11

[Jeremy M. Dolan]

The DHCP example cited in Ben's original report is just a way for DHCP to
control a DHCP client's resolver domain/search variables, and as such is
completly irrelevant. Resummarizing, as 'default domain' already is
configurable, though the resovler.

Is
  foo -> www.foo.com
  foo.com -> www.foo.com
documented anywhere? Are there any other substitutions the current
implementation does?

Comment 12

[benc]

I think you are missing the point of this RFE. You should at least check with an
active contributor of a bug before changing the summary. If the bug is stale,
that's a different story.

Your questions about hostname expansion are covered in other bugs.

The point is that people move from network to network, either by dialing
different ISPs, switching buildings, or connecting to VPN's.

When they do, the desired default domain changes. In many cases, users remain
"stuck" with their old resolver configuration. It would be prudent to solve this
problem at the mozilla level. 

I've given other supporting examples in other dns bugs I've filed, so I think
most people know where I'm coming from. Here's an example for the record, in
this bug:

I share a laptop at home with someone. The laptop was originally conigured for
pacbell.net (DSL service). So the default domain is "pacbell.net".

Currently, we use Mindspring DSL service for most connections. When we connect,
their DHCP server does not chnage the default domain to "mindspring.com". 

(Here you see a dialup service that does not successfully modify the resolver
configuration).

For our telecommuting, both of use make VPN connections. In my case, I connect
to the Netscape campus via a VPN (called SERA), and it does not change my
default domain to "mcom.com".

There are certain individuals who persist in sending out daily emails to us,
which often contain a single, unqualified hostname. Because they mean
hostname.mcom.com, what I want is a profile-level pref that lets me fully
qualify hostnames with the default domain of my choice. 

Because I do not have this feature, clicking on this link results in a failure
to connect to hostname.pacbell.net. I have to cut the link into a location
field, and then hack in the mcom.com link by hand.

Changing the default domain on the computer is not a solution, because I have to
restart in windows.

The basic design principle here is that a user should be able to disambiguate a
hostname reference at the application level. The LOCALDOMAIN example is the UNIX
way (because utilties run from a shell inherit the variables), but it does not
solve user level problems (like a UNIX user switching proxies) or non-UNIX users.

A more subtle design aspect is in play here as well: URLs are basically scripted
interfaces to network objects (a principle suggested in RFC 1630 and RFC 1738).
As such the user interaction is different from interactive services, like UNIX
utilities. If you click on "http://hostname" in an email, if it does not work,
you cannot easily correct it (what if it's inline images in an email, you are
going to save the file to disk, open it in composer, hack in the
domainnames...?). If you are using telnet, or ping, or anything in a UNIX
environment, you can just say "oh, duh, TELNET hostname.mcom.com" and type it again.

I think this explaination is sufficiently bulletproof.

All of the hostname -> www.hostname.com stuff is in other bugs, and the problem
descriptions are current, so lets stick to the topic here. 

NOTE: I am not suggesting we remove the other features.

Comment 13

[Jeremy M. Dolan]

> The point is that people move from network to network, either by dialing
> different ISPs, switching buildings, or connecting to VPN's.

You *DO* realize that's an argument to ***USE*** the resolver for expantion,
don't you? Or do you intend to go into prefs every time you switch between those
networks and reset your domain? The DHCP example you originally mentioned
interacts with the RESOLVER. Mozilla can't/won't/shouldn't get at that information.

> The basic design principle here is that a user should be able to disambiguate
> a hostname reference at the application level.

I so incredibly disagree Mozilla is the place for any such thing.

> NOTE: I am not suggesting we remove the other features.

I am. But that's another issue.

> I think this explaination is sufficiently bulletproof.

Bullet... "resistant".

-------

Why don't you just set your search path to "mcom.com". That sounds like the
behaviour you want. Or do you really need to be able to type just 'www' to
access your ISPs web server? If so, you can have multiple search paths. Even
Windows does this. Where's the problem? Do you really think EVERY network
application should have to implement this so you can set EACH one to something
differant? Hell, why not rewrite all of TCP/IP inside Mozilla. I mean, we're a
platform right?! :)

Please explain exactly how UNIX/W2k+ doesn't already give you the behaviour you
want. How familiar are you with DNS?

Comment 14

[benc]

re:  "use the resolver"

I think I have provided many examples of how the system level setting should be
used, but the lack of robustness means a user-preference is a desirable feature.

re: "so incredibly disagree"

Don't use the feature. I promise not to set the default to "mcom.com",
"packetgram.com" or "mozilla.org" :)

re: "change the default domain"
In windows that means rebooting. Also, I shouldn't have to edit a system level
preference when I'm trying to change the prefered behavior within an
application. That should be an application-level preference. 

re: "If so, you can have multiple search paths"
You mean "why not configure your laptop to search "pacbell.net, mcom.com,
mindspring.com, and othercompany.com"?

What horrible pile of mindless DNS queries for every hostname.

re: "all of TCP/IP"
I'm not one of those "we are a platform" people.

re: "How familiar are you with DNS?"

I've never been a hostmaster for a living, if that is what you mean.

I've been a DNS hostmaster off and on in the last 10 years, including being a
delegated adminstrator for some apple.com subnets. I've configured BIND more
often than I'd like to admit, and have read a couple editions of DNS & BIND
cover to cover. I also re-wrote parts othe resolver documentation for two
resolvers (MacTCP and OT-TCP/IP). 

Here's what I recollect that is most relevant to the point you are making:

In the mid 90's, resolvers qualified hostnames with the default domain
differently than they do now. Subdomains were much more heavily used, and
resolvers would send out numerous extraneous queries if a request was not "."
terminated when sent to the resolver (almost no programs did this).

The behavior of searching "UP" the DNS tree (a machine called
host.subdomain.domain.com was presumed to have users that were looking for other
hosts at subdomian.domain.com) as well as the search domain feature (a list of
abritrary domains to be scanned for hostnames), were both user-convenince
features, based on a line-command, typed hostname, local subdomain, single
physical connection based world. 

Most current resolver technology is a bit smarter (for example I think they
assume that any two-label domain should be sent as a FQDN first (try
hostname.com, before it tried hostname.com.defaultdomain.com, then hostname.com). 

Today's nework continue to evolve, networks have disparate performance (at least
a dozen bugs have been filed asking for things like caching to deal with slow
DNS servers), connectivity to multiple-networks, multi-user usage of a single
machine. This feature would address browing problems that occur with URLs that
have ambiguous DNS information. It would allow users across any platform to have
a simple solution to the problem.

Lets not forget that the resolver search domain behavior was added because extra
searches were assumed to be better than returning a lot of "hostname not found"
errors. This feature is presumed to be useful when the user is uncertain of the
FQDN that is needed for the foward lookup. 

My argument is that a user KNOWS what the FQDN is, but that our software forces
them to tell the resolver that they don't. The resolver should never be sent on
a wild goose chase through DNS when the user already knows the desired FQDN. The
best case scenario is that the resolver might hit the right fqdn on the first
query. The likely scenario is that the resolver will make several spurious
queries before the using the correct fqdn. An undesriable result would be
completion to the wrong hostname, because most end users do not understand the
exact behavior of the domain search sequence.

Many people take the attitude that extraneous DNS queries are okay because:
1- They are UDP
2- They take up a low % of network traffic.

This is wrong for two reasons: 
1- You should never do a search for something when you know what you are looking
for already. That is inelegant.
2- Any extraneous network traffic is potentially bad, because it is like
littering. Most of the time it is annoying, but if everyone does it, the effects
are disproprotionate to the inconvenince of an individual simply not littering.
For example, even a 1% increase of data transmission on a congested ethernet
wire can result in very large slow-downs in end-user performance. 
3- With the advent of negative DNS caching on servers, extraneous DNS queries
consume real memory resources on key network systems.

This is more detail than I thought was necessary to explain this RFE, but I
would say, "yes", I'm familar with the problem.

Comment 15

[Jeremy M. Dolan]

> Don't use the feature.

I certainly wouldn't. Just trying to prevent a Bad, bloaty feature from being
checked in for others.

> In windows that means rebooting.

Not in any recent version, and how often are you changing this? You set it to
mcom.com...if you get fired, and you use windows 95, yes, you'll have to reboot
for your new jobs domain. I don't see why you when you switch ISPs you need/want
mindspring/etc in your search path. For domains where it is desirable, DHCP
updates it automatically.

> Also, I shouldn't have to edit a system level preference when I'm trying to
> change the prefered behavior within an application. That should be an
> application-level preference.

See, the great thing about DNS being done outside the application is it's
consistant. Add mcom.com to your search path... You want neon.mcom.com to load
in Moz? Type in 'neon'. You want to ping neon.mcom.com? "ping neon". You want to
telnet to neon.mcom.com? "telnet neon". You want to FTP to neon.mcom.com? "ftp
neon".

Should ftp, ping, telnet, ssh, and thousands of other programs implement their
own DNS domain searching? (oh, wait, they do! it's in the resolver) I don't see
how Moz doing it would be superior.

> You mean "why not configure your laptop to search "pacbell.net, mcom.com,
> mindspring.com, and othercompany.com"

See above. I don't understand why you need and want to search pacbell.net and
mindspring.com. Just because they're your ISPs doesn't mean they need to be your
DNS domain/search path. And if they are already set, as you seem to say, then
you're already doing queries on them. And if you add seperate searching to Moz,
you're going to end up looking up stuff like
'what-i-typed-in.mcom.com.mindspring.com'.

> I've never been a hostmaster for a living, if that is what you mean.

Just making sure you had a good grasp of DNS theory and practice, so I didn't
have to overly explain certain technical things.

> It would allow users across any platform to have a simple solution to
> the problem.

I'll concede it does provide cross platform, slightly easier access to the
search path. As mentioned above though, it will end up working WITH the search
path, resulting in (1+x)*(1+y) lookups rather then 1+x. 2 items in your search
path, 2 in some new mozilla pref, you're doing NINE lookups if you type in
'misspelted'.

> Lets not forget that the resolver search domain behavior was added because
> extra searches were assumed to be better than

Good point, although I've always though resolvers should have a host alias
database, where I could manually add entries, say, 'neon' -> 'neon.mcom.com', so
I could just ping and telnet neon. I have a lot of machines in a lot of
differant domains I have to access, way too many to add to a search path. (Note
this is differant from a 'hosts' file, in that I don't control the DNS for those
machines... I want to associate neon to neon.mcom.com, not it's IP address).
There were at least two occasions I was almost bored enough to patch libresolv
to use /etc/host-aliases for that.

> My argument is that a user KNOWS what the FQDN is, but that our software
> forces them to tell the resolver that they don't.

I don't understand this whole paragraph. Seems contradictory. As you already
mentioned, if a host with at least two parts is entered, it's tried without the
search path first.

If I'm still missing something, and there is user benefit from this, I'm not
religiously against it. But even for your complex setup (two companies, two
ISPs), I still don't see how it wouldn't be better to not let the resolver
search on the two companies paths. What type of users in what type of situation
would care or benefit from this?

Comment 16

[benc]

The extra query problem is worth looking at in a performance context. I've been
meaning to look at that more (as well as write a bug that suggests we make
explicit queries to resolver to reduce the number of outbound DNS queries for
certain situations.

Comment 17

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 18

[benc]

nsbeta1 anyhow, I seem to see more and more sites that would benefit from this
feature inside our corporate network everyday.

Comment 19

[Doug Turner (:dougt)]

moving neeti's futured bugs for triaging.

Comment 20

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 21

[Samir Gehani]

adt: nsbeta1-

Comment 22

[thomas.fuerle]

dear sirs, I just would like DNS resolve to work, i.e

if I enter http://xxx, firefox should ask nslookup on my w2k box for the ip of xxx, which resolves on my box to e.g xxx.domain.co.at. this is the main reason, we cannot spread firefox, because IE supports that and firefox does not.

strange, for file:////xxx/somepath/somefile it works.

If you afraid of security with, make it an option and leave it us, if we force fqdn or accept local host + domain suffix.

Comment 23

[taomyn]

Is this behaviour ever going to be sorted?

As far as I'm concerned the OS should resolve the web, so if I enter http://servername and servername would resolve as servername.mydomain.com then that's what should be used.

Having to add separate "no proxy" entries for each non-FQDN in our Intranet is a nonsense and halts any idea of migrating to Firefox for many of our clients.