Re: [DNSOP] AS112 for TLDs

"John L. Crain" <john.crain@icann.org> Fri, 04 April 2008 22:51 UTC

Return-Path: <dnsop-bounces@ietf.org>
X-Original-To: dnsop-archive@optimus.ietf.org
Delivered-To: ietfarch-dnsop-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B713A68AA; Fri, 4 Apr 2008 15:51:17 -0700 (PDT)
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534163A6922 for <dnsop@core3.amsl.com>; Fri, 4 Apr 2008 15:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWb46cA26xzz for <dnsop@core3.amsl.com>; Fri, 4 Apr 2008 15:51:10 -0700 (PDT)
Received: from EXHUB016-3.exch016.msoutlookonline.net (exhub016-3.exch016.msoutlookonline.net [207.5.72.226]) by core3.amsl.com (Postfix) with ESMTP id A5FF33A68AA for <dnsop@ietf.org>; Fri, 4 Apr 2008 15:51:10 -0700 (PDT)
Received: from EXVMBX016-2.exch016.msoutlookonline.net ([207.5.72.172]) by EXHUB016-3.exch016.msoutlookonline.net ([207.5.72.226]) with mapi; Fri, 4 Apr 2008 15:51:17 -0700
From: "John L. Crain" <john.crain@icann.org>
To: Andrew Sullivan <ajs@commandprompt.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Date: Fri, 04 Apr 2008 15:51:16 -0700
Thread-Topic: [DNSOP] AS112 for TLDs
Thread-Index: AciWZ5CjqUbQYFsfSsuehiRZAWTHqwAPtL7L
Message-ID: <C41BFEF4.75F6%john.crain@icann.org>
In-Reply-To: <20080404151957.GK1184@commandprompt.com>
Accept-Language: en, en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en, en-US
MIME-Version: 1.0
Subject: Re: [DNSOP] AS112 for TLDs
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0697692686=="
Sender: dnsop-bounces@ietf.org
Errors-To: dnsop-bounces@ietf.org

Hi all.

I fully agree with Andrew that the cause is far worse than the disease.

I don't think the disease is life threatening. I keep hearing about the "Problem" of bogus queries to the root. It is certainly messy and ugly but from my perspective as an operator it is more of irritant than anything else. The capacity building for root operators, at least in our case, is not built around those bogus queries, it's build around other problems such as the number of hosts with weak security that are available for use in DDOS attacks.

In % terms the 90%+ of bogus queries is irritating, moving those queries out to the ISPs doesn't stop them, just shares the pain a little and probably hides the problem somewhat.

For now I still believe the best answer is to keep answering with NXDOMAIN and hoping that one day, this is where I am delusional,  that those do the querying will fix their end of the problem...


John Crain




On 04/04/2008 08:19, "Andrew Sullivan" <ajs@commandprompt.com> wrote:

On Fri, Apr 04, 2008 at 07:37:31AM -0700, David Conrad wrote:
> >>    leakage to the root servers is enormous.
> > This sounds to me like a cure that is quite possibly worse than the
> > disease.
>
> In what way?

It rather depends on how much the root zone changes.

The targets of "run your own root copy" are the people who don't know
how to capture and appropriately isolate (or don't care to do it)
their bogus traffic.

The proposed solution is to tell them to get a copy of the root zone
and run that.  What makes us think that they'll keep that copy up to
date, do sensible things with it, &c?

I am familiar with one largeish zone that had its infrastructure on
the wrong end of an expensive link between it and the largest ISP in
the country.  Their answer to this was to transfer the zone to the
ISP.  Unfortunately, nobody at the ISP was monitoring the log files,
and someone failed to keep the TSIG keys in sync, so their copy of the
zone gradually came to be wrong.  Since none of this
copying-of-zone-around was documented anywhere, it took some time to
debug the problem, during which time large sections of that domain
were unavailable to a substantial population in the country in
question.

I can just imagine the hue and cry that would happen when new top
level domains "don't work for everybody".

A

--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop