Subject: RE: Cite on DNS-related traffic.

From: Rick H Wesson <[email-masked]>
Date: Thu, 1 Jun 2000 09:21:37 -0700 (PDT)

Daryl,

I happen to own a iso-3166-2.com domain (ar.com) and a large part of the 
queries to my name servers are for  SLDs under .AR. which is the ccTLD
for Argentina.

The number of queries for *.com.ar.com., which all fail is significant
compared to queries for anything valid under ar.com.

I suspect similar behavior for any 2 letter SLD in a gTLD that has a
matching iso-3166-2 ccTLD. 

best regards,

-rick

On Tue, 30 May 2000, Daryl Bunce wrote:

> 
> 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: Thu, 01 Jun 2000 20:06:10 +0200

> matching iso-3166-2 ccTLD. 

We made some measurements in 1998 to quantify this. The background is
that the Norwegian (.no) domain name authority (see www.norid.no) used
to have a rule that <ccTLD>.no couldn't be used, due to the well known
problems mentioned in RFC 1535. We wanted to see if this rule could be
relaxed. Thus we logged all DNS queries to several of the authoritative
.no name servers, to a number of other important recursive name servers,
and also all DNS requests passing through some LAN segments used to
interconnect the most important routers of one particular ISP.

We logged DNS requests over one week, to get statistically significant
data. Of the "problem requests" we only looked at requests for *.com.no,
because this was the most common case. Example of the results:

27888935 DNS requests (all possible names) through interconnect segments
 5710521 requests for *.com (20.5%)
    2550 requests for *.com.no (4.47e-4 of the *.com requests)

 8831582 DNS requests (all possible names) to non-recursive .no server
  359117 requests for *.com (4.07%)
    7869 requests for *.com.no (2.19% of *.com requests)

 5160927 DNS requests (all possible names) to recursive .no server
  100406 requests for *.com (1.95%)
   11588 requests for *.com.no (11.5% of *.com requests)

We concluded that we could live with the these numbers, and removed the
rule that <ccTLD>.no couldn't be used.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 02 Jun 2000 08:31:40 +0200

At 09:22 31.05.2000 -0700, Joe Touch wrote:

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

so far nobody's mentioned RFC 1535, the short summary of which is "this is 
bloodyawfulstupidbehaviour".

If I am out to attack you, and can place a record at ANY position in your 
search path, I can control your offsite name lookups totally.

In the case of someone seaarching

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

any DNS administrator at dept.other.edu, other.edu or com.edu(!) can 
prevent him from getting to www.netscape.com, instead sending him elsewhere.

                     Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Jun 2000 10:56:31 -0700

> prevent him from getting to www.netscape.com, instead sending him elsewhere.

Yes. This is can also be changed by how the resolver is configured
(there are overrides, e.g., 'ndots'). 

RFC 1535 removes only some of those lookups; remaining are:

While RFC 1535 specifies that names including dots SHOULD be
resolved as absolute first, this can be changed by the resolver
configuration. And configuration information can be hard for
users to determine.

The use of the trailing dot (www.netscape.com.) remains
a useful way to force the resolver to avoid suffix extensions.

Joe

---

From: Keith Moore <[email-masked]>
Date: Fri, 02 Jun 2000 14:59:33 -0400

> a useful way to force the resolver to avoid suffix extensions.

this works sometimes, but not in all cases.
for example, trailing dots are not legal syntax for email addresses.

Keith

---

From: John C Klensin <[email-masked]>
Date: Fri, 02 Jun 2000 15:41:48 -0400

> a useful way to force the resolver to avoid suffix extensions.

And a useful way to induce massive confusion, since many
applications do not recognize the hack and won't pass it to a
resolver (which, of course, may or may not recognize it either).

   john

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Jun 2000 13:12:05 -0700

> resolver (which, of course, may or may not recognize it either).

It's not a hack - it's a fully qualified domain name.
Wouldn't this be a fine way to flag the bug in those apps?

Joe

---

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

---

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)

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

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. ;)