Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
On Tue, 30 May 2000 23:33:13 EDT, Garreth Jeremiah said:
Excuse me if this is answering the wron question here, but.....
This is just cycling through the clients "DNS Suffix search order", which is
clearly set to: dept.other.edu
Not necessarily. Resolvers also get this information from the
host's current fully-qualified name.
...However, it's unclear (to me, at least) whether either
of the following should be true by default:
a) That it should try 'other.edu' and 'edu', if suffixing with the
given suffix fails.
b) That it should do any rewriting at all if there's a '.' already
in the name.
Yes, I know that you need both of these to make 'foobar.chem'
resolve to 'foobar.chem.other.edu' if you're in a *.phys.other.edu
subnet... But there's gotta be a way to avoid this behavior as
a default...
It may be useful to distinguish resolver behavior from browser behavior.
If the host has no more specific (explicit) resolver information,
the current fully-qualified hostname, minus the first component,
is used as the 'working suffix'. Attempts are made, with increasing
generality, to use this suffix on any partially qualified request.
This explains:
- why it starts with dept.other.edu as the trailer
- why it retries with increasingly general variants
In at least one resolver (FreeBSD, by quick check), there's a parameter
called 'ndots' - if the request contains that number of dots (defaulted
to 1), the request is supposed to happen as if already fully qualified.
This can be overridden by appending a '.' to the name, explicitly
indicating that it is already fully qualified.
I would be curious to see if your lookup was as inefficient on
'www.netscape.com.'
Joe