Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

Mark Andrews <marka@isc.org> Sat, 25 August 2018 04:39 UTC

Return-Path: <marka@isc.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 F331E130DC1 for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 21:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 yHAx0Sl5PkP0 for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 21:39:03 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72672127AC2 for <dnsop@ietf.org>; Fri, 24 Aug 2018 21:39:03 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id D68553AB004; Sat, 25 Aug 2018 04:39:02 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 9E0D3160009; Sat, 25 Aug 2018 04:39:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7755E160044; Sat, 25 Aug 2018 04:39:02 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id k_0O1dfE89ye; Sat, 25 Aug 2018 04:39:02 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 4D6E3160009; Sat, 25 Aug 2018 04:39:01 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <A3840094-53FD-43DE-832F-247684F025C2@bangj.com>
Date: Sat, 25 Aug 2018 14:38:58 +1000
Cc: Ted Lemon <mellon@fugue.com>, dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5249205-8735-495F-B896-364BB195F1DC@isc.org>
References: <153507165910.12116.7113196606839876181.idtracker@ietfa.amsl.com> <AFB90F6F-5D99-4403-AAB6-1123727973E6@bangj.com> <5B7F5E07.5080100@redbarn.org> <7F91FFF7-71C3-4F8E-82CD-266B170983E0@bangj.com> <C0EE2719-B662-4231-AF51-D3B98B00AD0D@fugue.com> <6D607922-393D-4549-AAFA-49279C260CA4@bangj.com> <3C6100BD-62D6-41ED-B7BF-679F0D4E4113@fugue.com> <5063A32B-4877-4860-BA73-CCB068AB7FCB@bangj.com> <CAPt1N1=tXZNgT6ygAaLFfOMze7hbGZ6q_eN1C3iEo9ryBNcyLg@mail.gmail.com> <98EF2CAC-7C13-4E68-8D2B-EC0659EA9646@bangj.com> <CAPt1N1kFNY4=CUMsTvXmeRREeLAkY8xpBdw4vPDxujgke6QT8A@mail.gmail.com> <963460AA-14BB-44AA-87CA-7F09A707DB5D@bangj.com> <47AE41F8-9F5F-4CC8-B4F0-7E8191011E99@bangj.com> <F4335D3A-0241-437F-A428-8EA95F0A1C18@fugue.com> <56E8B2A6-7B65-4D25-B102-9EFA7E2CBE7B@bangj.com> <86D465A4-F390-4370-83EC-0E72FBE115BE@isc.org> <CAPt1N1=xy+JAtgvvF_+9LiTiefbpTy_Vd0b8gswozA1K1C57Nw@mail.gmail.com> <A3840094-53FD-43DE-832F-247684F025C2@bangj.com>
To: Tom Pusateri <pusateri@bangj.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/I9XZP2fpbWFKmk4cfu8BP7AvCX0>
Subject: Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Sat, 25 Aug 2018 04:39:06 -0000

Named already has the ability to allow a machine within a /48 to insert/remove a
delegation at the /48 point using TCP to authenticate the update request.
I wrote the code to support this about the same time as Geoff Huston was looking
at setting up 6to4 reverse delegations.  He ended up going the HTTP to do it.
The code to do that works for any /48 for IPv6 connections.

https://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-02 is a fully fleshed
out example of how to do this but I couldn’t get even a request to adopt call 
from the DNSOP chairs when I presented it.  Can we stop leaving this in
limbo and move it forward?

Mark

> On 25 Aug 2018, at 2:18 pm, Tom Pusateri <pusateri@bangj.com>; wrote:
> 
> Right, prefix delegation over DHCPv6 is a similar case that gets a prefix lifetime. I still use the WIDE dhcp6c client for PD and it has no means to update DNS. I haven’t found specific documentation from ISC DHCPv6 or KEA that describes creating DNS entries (PTR records) from delegated prefixes.
> 
> Tom
> 
>> On Aug 24, 2018, at 10:53 PM, Ted Lemon <mellon@fugue.com>; wrote:
>> 
>> When would that happen?
>> 
>> On Fri, Aug 24, 2018 at 10:52 PM Mark Andrews <marka@isc.org>; wrote:
>> Registering slaac derived addresses in the DNS.  These are tied to prefix lifetimes. 
>> 
>> 
>> -- 
>> Mark Andrews
>> 
>> On 25 Aug 2018, at 05:02, Tom Pusateri <pusateri@bangj.com>; wrote:
>> 
>>> 
>>> 
>>>> On Aug 24, 2018, at 2:59 PM, Ted Lemon <mellon@fugue.com>; wrote:
>>>> 
>>>> On Aug 24, 2018, at 2:43 PM, Tom Pusateri <pusateri@bangj.com>; wrote:
>>>>> It seems odd to take the position that the authoritative server shouldn’t need to clean up stale entries because it assumes the client will do it for you. I can’t imagine you taking this position under any other scenario.
>>>> 
>>>> The issue here is that this is a pretty major change to the DNS.   If we really want something this heavy, we should have a good reason for wanting it.   That's all.
>>>> 
>>>> The idea that some unnamed DHCP server somewhere doesn't do the right thing with cleaning up stale entries doesn't seem like a good enough reason, particularly given that the DHCID record tags the thing as having been added by the DHCP server, and considering that there are several open source implementations that do automatically delete records when the lease expires.
>>>> 
>>>> I think it might make sense to just wait on this.  I agree that it's an interesting idea for completeness, but we don't have enough operational experience yet to know whether we have a problem worth solving.   With respect to the DHCP use case, I'm certain we don't.
>>>> 
>>>> The good news is that if we do need this, you've done a design, and we also have Paul's design to look at.   So if operational experience a few years down the road shows us that we have a gap here, we can move on it pretty easily. I just don't see any reason to rush into it.
>>> 
>>> Ok, great. Hopefully others have some use cases they can share. In the mean time, back to learning Rust…
>>> 
>>> Thanks,
>>> Tom
>>> 
>>> _______________________________________________
>>> 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
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org