IETF Logo Mail Archive

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

Tom Pusateri <pusateri@bangj.com> Fri, 24 August 2018 16:50 UTC

Return-Path: <pusateri@bangj.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 611B4130E1A for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 09:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-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 s4QXWu_9wkWa for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 09:50:34 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17C1D130E16 for <dnsop@ietf.org>; Fri, 24 Aug 2018 09:50:34 -0700 (PDT)
Received: from [172.16.10.126] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id A36382F5C; Fri, 24 Aug 2018 12:46:19 -0400 (EDT)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <5063A32B-4877-4860-BA73-CCB068AB7FCB@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CEB756F6-1B83-4132-8EA7-69FB117AC076"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 24 Aug 2018 12:50:32 -0400
In-Reply-To: <3C6100BD-62D6-41ED-B7BF-679F0D4E4113@fugue.com>
Cc: dnsop WG <dnsop@ietf.org>, Paul Vixie <paul@redbarn.org>, Tim Wattenberg <mail@timwattenberg.de>
To: Ted Lemon <mellon@fugue.com>
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>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WC7C605XEAir8TnyV-HsaeFZ5bM>
Subject: Re: [DNSOP] Fwd: 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: Fri, 24 Aug 2018 16:50:36 -0000


> On Aug 24, 2018, at 9:54 AM, Ted Lemon <mellon@fugue.com> wrote:
> 
> On Aug 24, 2018, at 9:52 AM, Tom Pusateri <pusateri@bangj.com <mailto:pusateri@bangj.com>> wrote:
>> Yes, it was intended to be more general than for service registration. It’s directly applicable to name registration for IP addresses. I can add a section on other uses if more motivation is desired. Mark Andrews had some uses as well that hopefully, he can share. If others have uses in mind that this solves I would love to hear about them.
> 
> The reason I'm asking is not that I don't think there are theoretical use cases for what you are proposing.   I'm asking if there are actual use cases.   How would this be used in practice?   What can't someone do right now that they need to do and that this new technology enables?

Specifically, there are two applications mentioned in the draft.

1. When a DNS server receives a dynamic DNS Update from a client registering its name after having received an IP address from an DHCP lease, the length of the DHCP lease can be tied to the length that the DNS address/PTR records stay in the authoritative server.

2. When an RFC 6763 DNS-SD service is registered (including PTR, SRV, & TXT records), these records can timeout according to the lease lifetime contained in the update lease EDNS(0) option.

These are not theoretical. They solve practical problems that exist today. I think there are others associated with existing problems for sleeping devices and IoT devices that I need to research to more clearly answer your specific question but I think these two already fulfill that requirement.

Tom

v2.23.0 | Report a Bug | By Email