STEPS: 1- Use browser in normal DNS-served environment. 2- Turn off DNS server (I happen to be my own hostmaster, but this simulates various real-world events). 3- Attempt connection to some hostname you haven't connected to already (previously used DNS names are persistently cached). EXPECTED RESULTS: Some kind of accurate and/or friendly error like: DNS server unavailable -or- DNS request timed out. OBSERVED RESULTS: This does not happen, instead it says: hostname could not be found. Please check the name and try again. COMMENTS: I found this problem why trying to verify the /etc/resolv.conf - resinit() bug for Linux. Even if that feature works, if the new /etc/resolv.conf pointed to bad DNS server entries, you still need a correct error message in the end. NOTES: If there are dupes, please mark them dupes of THIS bug. I'm trying to clear out all the DNS bugs, but they have a lot of drift, so I'm writing bugs as I write my DNS functional tests. PLATFORMS: Mozilla 1.1b, Linux; Chimera 0.4, Mac OS X
ANALYSIS: If you want to see if your system is in this state, use nslookup. nslookup tries to tap the DNS server it points to on startup, and you will get an error. [localhost:/tmp] benc% nslookup *** Can't find server name for address 10.112.112.112: Timed out *** Can't find server name for address 10.112.112.112: Timed out *** Default servers are not available DNS availability is confirmed by a normal startup, and display of the default server. [localhost:/tmp] benc% nslookup Default Server: ns2.mindspring.com Address: 188.8.131.52
I think it is worth pointing out that if this error was correctly displayed, we would get more accurate problem descriptions in a dozen or so bugs we have received. Since we are not looking at an easy resolution of the resinit problem, I am wondering how difficult this would be.
*** Bug 143511 has been marked as a duplicate of this bug. ***
gordon, can you look at this?
Since we're essentially calling gethostbyname() or the equivalent on any particular OS, we don't necessarilly have access to the underlying cause of the error. We would probably need to have our own DNS resolver implementation to address this problem. Marking WONTFIX.
Doesn't the situation I described result in "TRY_AGAIN"? ERRORS No errors are defined for endhostent(), gethostent() and sethostent(). The gethostbyaddr() and gethostbyname() functions will fail in the following cases, setting h_errno to the value shown in the list below. Any changes to errno are unspecified. HOST_NOT_FOUND No such host is known. TRY_AGAIN A temporary and possibly transient error occurred, such as a failure of a server to respond. NO_RECOVERY An unexpected server failure occurred which can not be recovered. NO_DATA The server recognized the request and the name but no address is available. Another type of request to the name server for the domain might return an answer. (solaris man pages)
Those particular error values are not cross platform. NSPR simply returns PR_DIRECTORY_LOOKUP_ERROR.
*** Bug 53967 has been marked as a duplicate of this bug. ***
REOPEN: This shouldn't be wontfix, it should depend on bug 196076.