Subject: RE: Cite on DNS-related traffic.

From: Daryl Bunce <[email-masked]>
Date: Tue, 30 May 2000 16:56:21 -0700 (PDT)

I've often wondered how much of the overload is due to 
browsers looking for XYZ.com, then looking for www.XYZ.com...
Just one of those things thought about in the wee hours.

---

From: [email-masked]
Date: Tue, 30 May 2000 22:45:44 -0400

> Just one of those things thought about in the wee hours.

I run an off-site secondary for another .edu's DNS.  I once got
curious, and watched *WAY* too many lookups for (in quick sequence)

www.netscape.com.dept.other.edu
www.netscape.com.other.edu
www.netscape.com.edu
www.netscape.com  

No, I don't know why I got the last one, as I'm only answering for
'other.edu'.  Perhaps the host doing the queries had a sudden fit
of inspiration, saw my machine as an NS for its domain, and guessed.
Or maybe just some funky info in a DHCP config file someplace...

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Garreth Jeremiah <[email-masked]>
Date: Tue, 30 May 2000 23:33:13 -0400

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

it may be additionally set up for the others also, as the implimentation of the
resolver is obviously client dependent.  After trying its "domain suffix's" it
will attempt to resolve the bare form of the host domain pair.

If I am totally off the mark here - sorry - it's late and the wife is
screaming for me to sleep as I have an early start tomorrow.

Garreth J Jeremiah
IT Specialist (Security)

 On Tue, 30 May 2000, [email-masked]
wrote: > On Tue, 30 May 2000 16:56:21 PDT, Daryl Bunce <[email-masked]> 
said: > > I've often wondered how much of the overload is due to

---

From: [email-masked]
Date: Tue, 30 May 2000 23:48:21 -0400

> clearly set to: dept.other.edu

Yes.  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...

/Valdis (who thinks things would work a LOT better overall if everybody
just kept their machines configured right and installed recent patches
once a year or so.... ;)

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 May 2000 09:22:26 -0700

> > 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

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

---

From: Garrett Wollman <[email-masked]>
Date: Wed, 31 May 2000 13:52:47 -0400 (EDT)

> a) That it should try 'other.edu' and 'edu', if suffixing with the

This should not be true, but is historic behavior on the part of
several very common resolvers.  (Particularly, this is the behavior
one gets with an old BSD resolver all the time, or with a newer BSD
resolver when it's misconfigured.)

Have a look at
<http://khavrinen.lcs.mit.edu/wollman/dns-cache-week.png> and
<http://khavrinen.lcs.mit.edu/wollman/dns-errors-week.png> for an
interesting look at what one of our major resolvers does.  (For
hysterical raisins, our main name servers have historically been
name-resolution servers for low-end clients.)  (Yes, I know that
``lame server'' is not an actual DNS protocol error, it's a
configuration error, but the operational result is the same: we sent a
query and got an unhelpful response.)

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
[email-masked]  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick

---

From: Garrett Wollman <[email-masked]>
Date: Wed, 31 May 2000 13:55:42 -0400 (EDT)

> of inspiration, saw my machine as an NS for its domain, and guessed.

Many people mistakenly assume that any name server which serves their
domain can be configured in their stub resolver.  Recent versions of
BIND can be configured to answer ``no'' to such queries.  (We don't
want to do that here because there are far too many clients to be
changed, almost none of which use DHCP.)

-GAWollman

---

From: [email-masked]
Date: Wed, 31 May 2000 13:58:38 -0400

> I would be curious to see if your lookup was as inefficient on

I have no idea - the DNS in question is an off-campus secondary run as
a favor for somebody - the university in question is about 9 hours drive
from here.  As such, if they did an efficient lookup, I'd never see the
packet, so I dont know. ;)