[EMAIL PROTECTED] 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
