DNS: no error for query failure due to missing DNS server

RESOLVED WONTFIX

Status

()

Core
Networking
--
minor
RESOLVED WONTFIX
16 years ago
2 years ago

People

(Reporter: benc, Unassigned)

Tracking

(Depends on: 1 bug, {helpwanted})

Trunk
helpwanted
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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
(Reporter)

Updated

16 years ago
Keywords: nsbeta1
(Reporter)

Comment 1

16 years ago
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:  207.69.188.186

 
(Reporter)

Updated

16 years ago
Blocks: 27975
(Reporter)

Comment 2

15 years ago
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.
(Reporter)

Comment 3

15 years ago
*** Bug 143511 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

15 years ago
Keywords: helpwanted

Comment 4

15 years ago
gordon, can you look at this?
Assignee: new-network-bugs → gordon

Comment 5

15 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 6

15 years ago
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)

Comment 7

15 years ago
Those particular error values are not cross platform.  NSPR simply returns
PR_DIRECTORY_LOOKUP_ERROR.
(Reporter)

Comment 8

15 years ago
*** Bug 53967 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 9

14 years ago
REOPEN: This shouldn't be wontfix, it should depend on bug 196076.
Status: RESOLVED → REOPENED
Depends on: 196076
Resolution: WONTFIX → ---
(Reporter)

Comment 10

14 years ago
->defaults
Assignee: gordon → darin
Status: REOPENED → NEW

Updated

14 years ago
Severity: normal → minor
Target Milestone: --- → Future

Updated

12 years ago
Assignee: darin → nobody
QA Contact: benc → networking
Target Milestone: Future → ---
Status: NEW → RESOLVED
Last Resolved: 15 years ago2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.