Closed Bug 88217 Opened 21 years ago Closed 7 years ago
default domain (domain suffix appended to non-FQDN hostnames)
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.
Summary: [RFE] default domain → [RFE] default domain
there's already a bug filed to make this configurable, but I can't find it at the moment (it may well be WONTFIX).
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.
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!
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.
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".
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).
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.
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?
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.
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.
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?
Summary: [RFE] default domain → [RFE] configurable URL guessing
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.
Summary: [RFE] configurable URL guessing → [RFE] default domain
> 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?
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.
> 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?
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.
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)
Target Milestone: mozilla1.0 → mozilla1.0.1
nsbeta1 anyhow, I seem to see more and more sites that would benefit from this feature inside our corporate network everyday.
moving neeti's futured bugs for triaging.
Assignee: neeti → new-network-bugs
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.
Severity: normal → enhancement
Assignee: general → darin
OS: other → All
Summary: default domain → default domain (domain suffix appended to non-FQDN hostnames)
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.
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.