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

Tom Pusateri <pusateri@bangj.com> Fri, 24 August 2018 04:03 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 38AF2130EA8 for <dnsop@ietfa.amsl.com>; Thu, 23 Aug 2018 21:03:27 -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, 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 J69KPGnVkO6D for <dnsop@ietfa.amsl.com>; Thu, 23 Aug 2018 21:03:25 -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 03CA7130E6B for <dnsop@ietf.org>; Thu, 23 Aug 2018 21:03:25 -0700 (PDT)
Received: from [172.16.10.101] (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 BA1AB2E0E; Thu, 23 Aug 2018 23:59:12 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <7F91FFF7-71C3-4F8E-82CD-266B170983E0@bangj.com>
Date: Fri, 24 Aug 2018 00:03:23 -0400
Cc: dnsop WG <dnsop@ietf.org>, Tim Wattenberg <mail@timwattenberg.de>
Content-Transfer-Encoding: quoted-printable
Message-Id: <45A6E3AE-16C2-4A77-9B57-C76DAA8C972A@bangj.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>
To: Paul Vixie <paul@redbarn.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jkDKcKgLPJgemoST-SMpLgjYcK4>
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: Fri, 24 Aug 2018 04:03:27 -0000

I don’t think there is a TTL issue because, as we proposed it, the record is never returned in a query. The TTL could always be set to 0 for our purposes since it never leaves the authoritative servers.

Tom


> On Aug 23, 2018, at 11:44 PM, Tom Pusateri <pusateri@bangj.com>; wrote:
> 
> Paul,
> 
> Thanks for the feedback!
> 
> An RRset isn’t granular enough because the components of the set could come from different clients with different timeout values.
> Therefore, a unique identifier is needed for each record. The hash provides that unique identifier since it is calculated over the entire record including the unique RDATA.
> 
> The contents of the TIMEOUT RDATA field are not encrypted. The list of hashes are the list of unique identifiers. If each record had a unique identifier, we could use that instead but because they don’t, we create one with the hash.
> 
> The AAAA._TIMEOUT.FSI.IO idea is a neat one that we hadn’t thought of but it isn’t unique to a record with a potentially different timeout value from a different client and only works if all the members of the RRset have the same timeout.
> 
> We’ll take a look at your TTL concern and your previous draft.
> 
> Thanks!
> 
> Tom
> 
> 
>> On Aug 23, 2018, at 9:23 PM, Paul Vixie <paul@redbarn.org>; wrote:
>> 
>> 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
>> 
>> _______________________________________________
>> 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