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

Paul Vixie <paul@redbarn.org> Fri, 24 August 2018 01:23 UTC

Return-Path: <paul@redbarn.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 78DFD130E14 for <dnsop@ietfa.amsl.com>; Thu, 23 Aug 2018 18:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 r5N3X19Lv0L4 for <dnsop@ietfa.amsl.com>; Thu, 23 Aug 2018 18:23:22 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0026F130DFE for <dnsop@ietf.org>; Thu, 23 Aug 2018 18:23:21 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:9061:ce0d:93bf:336d] (unknown [IPv6:2001:559:8000:c9:9061:ce0d:93bf:336d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 413B2892C6; Fri, 24 Aug 2018 01:23:21 +0000 (UTC)
Message-ID: <5B7F5E07.5080100@redbarn.org>
Date: Thu, 23 Aug 2018 18:23:19 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Tom Pusateri <pusateri@bangj.com>, Tim Wattenberg <mail@timwattenberg.de>
CC: dnsop WG <dnsop@ietf.org>
References: <153507165910.12116.7113196606839876181.idtracker@ietfa.amsl.com> <AFB90F6F-5D99-4403-AAB6-1123727973E6@bangj.com>
In-Reply-To: <AFB90F6F-5D99-4403-AAB6-1123727973E6@bangj.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TpMNka3HvwVdkvJlCWCBAq6jraI>
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 01:23:23 -0000

tom, tim, thanks for this. i have two concerns, and three observations.

concern #1 is about this text:

>    3.  TIMEOUT resource records are not automatically sent in AXFR, IXFR
>        zone transfer requests.  Both primary and secondary servers
>        should be configured on a per zone basis to transfer TIMEOUT
>        resource records to ensure they are supported.

this is impractical given the high automation usually now involved in 
primary/secondary AXFR and IXFR relationships. i suggest negotiating for 
this with an OPT RR in the AXFR or IXFR request, indicating whether the 
initiator ("secondary" in this document) supports TIMEOUT or not.

concern #2:

you don't appear to have addressed TTL overrun here. it's necessary for 
a record which will expire to have a declining TTL as that expiry time 
nears. if it's always been 3600, then when you're within one hour of 
expiry time, returned TTL has to be reduced to whatever time remains.

observation #1:

none of the crypto seems nec'y. i would not quibble about it except that 
since it is crypto it will have to morph over time to become stronger 
against growing brute-force attacks and vuln research. this puts a 
maintainance burden on the community every time we encode crypto into a 
protocol. can you explain why the TIMEOUT RDATA isn't in clear text?

observation #2:

might you arrange for an _-related schema, so that each RRset having a 
TIMEOUT can have those records as a niece/nephew domain? for WWW.FSI.IO 
AAAA, the TIMEOUT would be at AAAA._TIMEOUT.FSI.IO, in this case.

observation #3:

this was all considered previously. most recently it was the subject of 
an apple patent (EP1759516) by cheshire and sekar. first and foremost it 
was proposed in the old DNSIND working group by myself, in 1996. you 
don't have to worry about the patent, due to my prior art. since the 
draft is expired, i've put a copy online here:

http://family.redbarn.org/~vixie/defupd.txt

the IETF DNSIND WG rejected this draft on the basis of its complexity. 
the idea of a zone having timers inside it, for self-modification, was 
just a bridge too far at that time. given what is now called "the camel" 
i think pendulum has swung _well_ away from that point of view, but is 
now in the process of swinging back. if i had hope, i would submit 
DEFUPD again, exactly as it was in 1996, because it still deftly threads 
the needle posed by UPDATE. your needs may differ.

"good luck storming the castle, boys!" (_The Princess Bride_)

vixie

re:

https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-00.txt