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

Ted Lemon <mellon@fugue.com> Sat, 25 August 2018 15:11 UTC

Return-Path: <mellon@fugue.com>
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 C1E6E124BE5 for <dnsop@ietfa.amsl.com>; Sat, 25 Aug 2018 08:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.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 BRaU2yACb7xG for <dnsop@ietfa.amsl.com>; Sat, 25 Aug 2018 08:11:40 -0700 (PDT)
Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 6250D12008A for <dnsop@ietf.org>; Sat, 25 Aug 2018 08:11:40 -0700 (PDT)
Received: by mail-it0-x243.google.com with SMTP id h20-v6so5508794itf.2 for <dnsop@ietf.org>; Sat, 25 Aug 2018 08:11:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JYwVI0k1GKUxR5no3IHLQlUBOxFermRWFZfboPZ8b9Y=; b=OvDTyAe2cJ2ZECKb/kUisBjO2yOl9/OLnsp9Xotq7k/lL5uj/CO8v2/6EnXWk3gvpD vt9mmkflRXyoujiA79AXcTFXCeH+i1REMSHY2iwtpZVgrqjjAYxmkwfpq+q4bCUAS7lE IvsrDXm2rj/h+OeK6DT9i7wk6BkLe472+rkk+NHMWp2neXUHABLES2FLAcWPVBRL2Mmk +K+CvxSPCaRJSeFBSn+1TE88pQskw3bNhalN11Lrwn5mxSK2Qp6MQymBqhQjMF/PeRYI Z6AVEb34ARXw6SNVOo5jiXgbsv32ogoiS2KtO+ZmcehW05ftMvG9K3jeJlKM73mJrjCE NAbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JYwVI0k1GKUxR5no3IHLQlUBOxFermRWFZfboPZ8b9Y=; b=H55awB73ZbQJbKsf62pVMpJPP+2HmLj381F4I3gLNV9i5o9zwOaJ3WTHLTl/IPrOSM a0CEoeFb/FECckmtTQkoootHZ03j0K4CAMetZxOgFVaaYN8N0EWGkaFBCEbd2EhKx54b 8aso97/zmJ9cDelC2QXdiuohcnnjJKmCzeXTmD4mfo2NuWbjcC5rfQdV95G/er9YMunp y4gspb9WyOckxyFZHCwzwAnlsa05zlymf0V+pN5r4pBOALZAbw8xhdGs6oiBuBAPlUpV kcxzSL036Nt5Kx9pUWhW7qRlyUVzVtuTOAMO/pRCLM1N4hXyVzi1+nmnzHmuYWVRXwiG MSSA==
X-Gm-Message-State: APzg51DvfpbxxVYdPAzznqaAbSIAMCWQTk01aje4NPG5qsOkNqVHjLor dE/Jl7PXOuOp4aPixK1KPOxO5nK2pkxEVu8mKQEiWw==
X-Google-Smtp-Source: ANB0VdYxmKtJYW2M8toyTYEqsAO7bWHsMY3Uf4yFKqiFA7USXlMMPHkiiZPKT8pHtMoOq6RBXc0j35n6QyDCzMRv22s=
X-Received: by 2002:a02:5f44:: with SMTP id r65-v6mr5081581jab.34.1535209899369; Sat, 25 Aug 2018 08:11:39 -0700 (PDT)
MIME-Version: 1.0
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> <99FA0B76-D225-45FC-A33C-B65E2673A45E@isc.org> <CAPt1N1kp8Tg5tWEiDCMuMNTmehRsBSkkC1=u+RcvkG6ZCegE-g@mail.gmail.com> <977DF12E-178B-4500-B045-F27BF1CDF51C@isc.org>
In-Reply-To: <977DF12E-178B-4500-B045-F27BF1CDF51C@isc.org>
From: Ted Lemon <mellon@fugue.com>
Date: Sat, 25 Aug 2018 11:11:02 -0400
Message-ID: <CAPt1N1=cafnVmnNM2eSF67QbgRk8hUEAd2Gwuqx4OUehPZSmyQ@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: Tom Pusateri <pusateri@bangj.com>, dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b53e85057443e8dd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eYiuxvgfCqEoaC-p0pTrY1V1Am4>
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 15:11:44 -0000

Right; my question is, is this an operational problem people are having
IRL?   If it is, then it makes sense to do something about it.   If it's
not, it doesn't.   I've never seen people do what you're describing in
practice; that's why I'm asking.   And we definitely agree that there needs
to be a cleanup process; the question is, does it have to be done this
way.   E.g., if the lease isn't part of the zone, is that actually a
problem?   Does the lease *need* to be part of the zone transfer, or is it
enough that the primary has it?   For my part, it seems unnecessary for the
secondaries to have it, since they can't update the zone anyway.   As long
as the primary remembers that there's a lease, the right thing will happen.

On Sat, Aug 25, 2018 at 10:30 AM Mark Andrews <marka@isc.org>; wrote:

> It avoids leaving dangling records published longer than necessary.
>
> Network dies so the machine can’t do the cleanup it was intending.
>
> Last second cleanup as the lid closes doesn’t get through.
>
> It’s relatively easy to implement, no more difficult than resigning for
> DNSSEC at the cost of a small amount of space.  It also transfers the
> necessary state to all the slaves allowing them to take over if the master
> server fails presuming they have the keying material for DNSSEC.
>
> --
> Mark Andrews
>
> On 25 Aug 2018, at 22:53, Ted Lemon <mellon@fugue.com>; wrote:
>
> I'm not saying nobody does it.   I'm trying to understand how this helps.
>
> On Fri, Aug 24, 2018 at 11:24 PM Mark Andrews <marka@isc.org>; wrote:
>
>> Ted stop being daft. People have been registering addresses of machines
>> in the public DNS for decades.   SLAAC. Is just one source of addresses.
>> DHCP is another. Come up with a third method and they will do it with it.
>>
>> Also DHCP servers from ISPs don’t have authority to update DNS servers
>> for my machines. Only those machines have such authority so don’t discount
>> DHCP derived addresses.
>>
>> --
>> Mark Andrews
>>
>> On 25 Aug 2018, at 12:53, 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
>>>
>>>