Re: [DNSOP] Future of "Using DNAME in the DNS root zone for sinking of special-use TLDs" ?

George Michaelson <ggm@algebras.org> Tue, 18 October 2016 23:04 UTC

Return-Path: <ggm@algebras.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B01129504 for <dnsop@ietfa.amsl.com>; Tue, 18 Oct 2016 16:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE6RW9m_BTMj for <dnsop@ietfa.amsl.com>; Tue, 18 Oct 2016 16:04:24 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E341294B7 for <dnsop@ietf.org>; Tue, 18 Oct 2016 16:04:23 -0700 (PDT)
Received: by mail-oi0-x22e.google.com with SMTP id t73so10882410oie.1 for <dnsop@ietf.org>; Tue, 18 Oct 2016 16:04:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zb7/Cl2W8ZOHObMy69F9Hi+cWgsErnB3NLnGImfq0Es=; b=1wK6wmZRo4VEdGu2FELt6jqzJm7tAURC2lTVysZaGOAUUrU4BxgJxyqHbTwTgh5Wuc BvRqSEdXtq4SVq+eRq5AfLNJJyfoUKbGozjKGNaRXoYKiIojwJWcYUxfY9XoCMfrkJoL F2fxdiYydvBhs66IgEKvuXpIVmmPMlVLcK9LF4cDlO+yaOV71o9WGDURQ5t0CT5kuVHR yFnihOL18uY4InHjcmpVSBT1blBw2noO8xfJSRDvKkQIKthZoyuWJ3mUPr1C5JwJm7ZU CWb3FxjvWFFqFYqFSuMgHXCS+2InsN+UHfqqA/nGuT0kjxEEqTV0Mhvi1sHvjbjViSbk IcOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zb7/Cl2W8ZOHObMy69F9Hi+cWgsErnB3NLnGImfq0Es=; b=YYVzOHFKvNMeQQH02OA8izzpqMyR4OGq7WnZg1l8Sz0E8Jzn4yVZF/jcrd+YixF2GJ pzkCOh7x+Ikho0uODUnykumdaICm6SB9pLA+TaZcNd3x0Bg9aYapsvCMFBi0EqSMteP8 O1+P4DRqFuh0gEBFo/y3zrOqZb4D/guVcHxj7GhX0wwVoHeX9WpblfQRvtFWDouxfnO1 2txqO5FNq7Ubczr72S11H4qQRlKwlQCxONHc7dutH1irmoOwuABIyIZWlIOj8zIruo5O VKLk2Z0WiMQeuygn5v0+BVeokrbAvZRLVr1Z9G3msINpxM4hvtQOzhHcWxznxcgIb2x9 2cLQ==
X-Gm-Message-State: AA6/9RlN+jo8A+DOX37nxf4+kCHglnK82oc8PLpVfGxD8whvL7LKClziZAyKV/5RoBxnd4cHnO8ad7wqqu3wXg==
X-Received: by 10.202.77.9 with SMTP id a9mr2313572oib.180.1476831863156; Tue, 18 Oct 2016 16:04:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.221.8 with HTTP; Tue, 18 Oct 2016 16:04:21 -0700 (PDT)
X-Originating-IP: [2001:dc0:a000:4:80f0:c608:73eb:7fc6]
In-Reply-To: <20161018225412.C0F9A56F08DA@rock.dv.isc.org>
References: <20161018175340.26608.qmail@ary.lan> <20161018211145.0DA0456EF21C@rock.dv.isc.org> <alpine.OSX.2.11.1610181740070.35115@ary.qy> <20161018220716.2A18956F019C@rock.dv.isc.org> <alpine.OSX.2.11.1610181836450.35412@ary.qy> <20161018225412.C0F9A56F08DA@rock.dv.isc.org>
From: George Michaelson <ggm@algebras.org>
Date: Wed, 19 Oct 2016 09:04:21 +1000
Message-ID: <CAKr6gn384nYStXCOo7-qhM7E_+34p-0wp3vfKPKZ-0HZoaN-SQ@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DOfE6kZJPhe74YljCLgzUzdxR3I>
Cc: dnsop WG <dnsop@ietf.org>, John R Levine <johnl@taugh.com>
Subject: Re: [DNSOP] Future of "Using DNAME in the DNS root zone for sinking of special-use TLDs" ?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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>
X-List-Received-Date: Tue, 18 Oct 2016 23:04:26 -0000

Mark, thats a bit of an unsatisfactory answer. the RFC (which you
authored) says:

"...As with caching positive responses it is sensible for a resolver to
   limit for how long it will cache a negative response as the protocol
   supports caching for up to 68 years.  Such a limit should not be
   greater than that applied to positive answers and preferably be
   tunable.  Values of one to three hours have been found to work well
   and would make sensible a default.  Values exceeding one day have
   been found to be problematic. ..."

So your response is an appeal to authority, which then cites nothing
to state why 1-3 hours is ok, and >24 is a problem.

The language is useful when it says "such a limit should not be
greater than that applied to positive answers" But it doesn't actually
tell us *why* Three Hours is a magic number.

The RFC is from 1998. The DNS has changed a bit since then.

Can you explain in a modern, 2016 DNS, why three hours is the "best"
time to chose, for this specific purpose?

(I can believe btw, its a good choice)

-G

On Wed, Oct 19, 2016 at 8:54 AM, Mark Andrews <marka@isc.org> wrote:
>
> In message <alpine.OSX.2.11.1610181836450.35412@ary.qy>, "John R Levine" writes:
>> >>> No.  They slow the leaks.  They do not STOP the leaks.  They depend on
>> >>> leaks to work.
>> >>
>> >> With a 24 hour TTL on the root zone, it ain't going to leak very much.
>> >
>> > The practical TTL is 3 hours.
>>
>> How come?  This is a real question, unbound appears to believe the 24 hour
>> TTL.
>
> Because that is what RFC 2308 says to do with negative answers.
>
>> > But dummy stub zones (which is what is being I'm requesting) require
>> > changes in the root zone to add a insecure delegation to not break
>> > other things.  That requires IANA to be instructed to do so.
>>
>> Hm, I see your point.
>>
>> R's,
>> John
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop