Subject: Question for the DNS system.

From: "Felix, Zhang" <[email-masked]>
Date: Wed, 10 Mar 2004 13:02:36 +0800

Dear all, 

     According to the current Internet, in most cases, the allocation/design of DNS is not more than 3-5 levels, such as us.ibm.com etc. What's my problems is that "when using lots of DNS names with more than 5 levels, Is there some problem with the whole DNS system,  such as some performance problem for searching,  dificulities to operate etc.....?  Could the current DNS tree architecure bear large traffic or not?"  Is there somebody can provide some real data about the current Internet, such as average search time etc.
 
     As everyone knows, IPv6 is coming ..........   :-)

 Best regards.
 
 Yours Felix. Zhang.

---

From: James Seng <[email-masked]>
Date: Wed, 10 Mar 2004 14:48:12 +0800

Just a matter of curiousity: which division do you work for in Huawei?

-James Seng

---

From: Donald Eastlake 3rd <[email-masked]>
Date: Wed, 10 Mar 2004 17:30:53 -0500 (EST)

Deep (many label) DNS names work fine. But for some reason the DNS
system has long suffered from lust for the root where people scramble
for DNS names with the minimum number of labels. This, coupled with the
marketing efforts of some TLD owners resulting in very wide zones that
require huge servers, are harder to deploy DNSSEC on, etc. It's wide
zones that are a potential problem, not deep names.

(There is some logic in going for short domain names interms of total
number of characters or ease of memorization. But based on that,
1.2.3.example would be superior to onetwothree.example. Yet people lust
after the second...)

Thanks,
Donald
======================================================================
 Donald E. Eastlake 3rd                       [email-masked]
 155 Beaver Street              +1-508-634-2066(h) +1-508-786-7554(w)
 Milford, MA 01757 USA                   [email-masked]

On Wed, 10 Mar 2004, Felix, Zhang wrote:

> Date: Wed, 10 Mar 2004 13:02:36 +0800
> From: "Felix, Zhang" <[email-masked]>
> To: [email-masked]
> Subject: Question for the DNS system.
>
> Dear all,
>
>      According to the current Internet, in most cases, the
> allocation/design of DNS is not more than 3-5 levels, such as
> us.ibm.com etc. What's my problems is that "when using lots of DNS
> names with more than 5 levels, Is there some problem with the whole
> DNS system, such as some performance problem for searching,
> dificulities to operate etc.....?  Could the current DNS tree
> architecure bear large traffic or not?"  Is there somebody can provide
> some real data about the current Internet, such as average search time
> etc.
>

---

From: Zhang Bao Feng <[email-masked]>
Date: Wed, 12 Mar 2003 08:17:58 +0800

Dear Eastlake, 

You are absoutly right, but if considering about the end-to-end SIP call, this lookup time will make some influence with the calling establish time, as Michael mentioned,  "The performance of lookups scales linearly  (worst case) with the number of zone cuts ".  

So that's the reason why I want to know the real-data about the lookup time in current DNS system. :-) It may be a problem for real-time applications.

Yours Felix.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 10 Mar 2004 20:30:13 -0500

In message <004201c2e82c$dea75af0$07120b0a@huaweizw6v4czf>, Zhang Bao Feng writ
es:
>Dear Eastlake, 
>
>You are absoutly right, but if considering about the end-to-end SIP call, this
> lookup time will make some influence with the calling establish time, as Mich
>ael mentioned,  "The performance of lookups scales linearly  (worst case) with
> the number of zone cuts ".  
>
>So that's the reason why I want to know the real-data about the lookup time in
> current DNS system. :-) It may be a problem for real-time applications.
>
I believe that the crucial factor is whether or not the relevant
NS records and their associated A records are cached.  If they are, 
lookups will go very quickly.  Of course, the cache is populated by the 
first such lookup, so that one might be somewhat slower.

		--Steve Bellovin, http://www.research.att.com/~smb