Re: [dns-privacy] New Version Notification for draft-zatda-dprive-xfr-using-dso-00.txt
Matthijs Mekking <matthijs@pletterpet.nl> Fri, 12 July 2019 13:46 UTC
Return-Path: <matthijs@pletterpet.nl>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1A6120118 for <dns-privacy@ietfa.amsl.com>; Fri, 12 Jul 2019 06:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 5n2VhkjkUrsW for <dns-privacy@ietfa.amsl.com>; Fri, 12 Jul 2019 06:46:49 -0700 (PDT)
Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.24]) (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 188D31200CD for <dns-privacy@ietf.org>; Fri, 12 Jul 2019 06:46:48 -0700 (PDT)
Received: from [IPv6:2001:980:4eb1:1:e1b9:7845:dec9:b665] ([IPv6:2001:980:4eb1:1:e1b9:7845:dec9:b665]) by smtp-cloud7.xs4all.net with ESMTPSA id lvsohDDyp0SBqlvsqhHh50; Fri, 12 Jul 2019 15:46:46 +0200
To: dns-privacy@ietf.org
References: <156260792242.808.508025353392512987.idtracker@ietfa.amsl.com> <E2CC956E-C409-46CC-881A-0C9D900C6EFC@sinodun.com>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <76919d2d-210a-a803-8ec9-07b9d465345d@pletterpet.nl>
Date: Fri, 12 Jul 2019 15:46:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <E2CC956E-C409-46CC-881A-0C9D900C6EFC@sinodun.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfDBu0pdwVulKFzC4kdU7GOw3VIeKHAi7C7jEdN8ALZoyj15g/iPs8xuN99WbtkHWj5SPA4QnsQNF/dpEdwIbP149GPllirP3RhJ9UQZqR1isvPAAij6J U6vK/Ubuc5VUP7MzO8gGAduXYPEPzkPP6LW/YBbxMk8RCysPvH6Sr7PCn723bk+HprLFFly6M1nt8gozabn2R2nxEEIW3atr+aNpNdfRTFp165cdr4EDfmdf bhkwl0NstA8ZKOlbnrOTh1QBx9WlCJ9Y0uZfQOjbH/A=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/0hyZ6KYd4TNQ-rL2GpRYzQMF8j4>
Subject: Re: [dns-privacy] New Version Notification for draft-zatda-dprive-xfr-using-dso-00.txt
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jul 2019 13:46:52 -0000
Hi Sara, Thanks for this first version. I have read it and here are my thoughts. 1. About use cases. The draft mentions performance because it will reduce the number of messages required to perform one transfer. Hopefully this new protocol can also add performance improvements for the DNSSEC case (reduce redundant information in the change such as RRSIG deletions, basically ideas that are listed in my MIXFR draft [1]. Similar we could incorporate the IXFR-ONLY idea [2] that will contribute to the improved error handling use case. [1] https://datatracker.ietf.org/doc/draft-mekking-mixfr/ [2] https://datatracker.ietf.org/doc/draft-kerr-ixfr-only/ 2. QUESTION: Is there a use case to allow XuD over TCP where confidentiality is not an issue e.g when the zone contents are already publicly available? Section 3 lists several use cases other than confidentiality for DSO based zone transfers, so I guess the answer to the question is yes :) So why not allow DSO transfers over TCP too? 3. QUESTION: Is there a use case where a client may want to signal that the version of the zone it holds has been updated via another mechanism and the zone transfer should restart from a different SOA than that currently exchanged between client and server? I think "signalling the version of the zone it holds" should be supported. Not only because it may have been updated by another mechanism, but also it can go out of sync. Consider the case where a secondary is restored from a backup and has an older version of a zone on disk. Of course a client could do this by unsubscribing and resubscribing with its current SERIAL, so maybe no special DSO type message is needed? 4. >From the draft: DNS wildcarding is not supported. SUBSCRIBE-XFR requests received for zones containing wildcards are considered an error (see below). But I fail to find any text around wildcarding below. But this does raise a question whether a SUBSCRIBE-XFR Request should support multiple zones. I am thinking of a use case where a server has a bulk of zones it serves, then it could end up with maintaining lots of subscriptions. 5. Alternatively if incremental zone transfer is not available, the entire zone MAY be returned in a DSO-AXFR message. QUESTION: Should we bother with a separate DSO-AXFR message or just allow full zone transfer inside the DSO-IXFR message as with [RFC1995] IXFR? A separate message type makes is more explicit and IXFR was constrained by having to respond to a IXFR request. I don't see much value in two separate type of messages, except that it is slightly easier to detect whether the transfer is an incremental or a full one. What does interest me is that a client can subscribe to incremental zone transfers only, and may decide to subscribe to a different master if an incremental zone transfer is not available (a situation that should happen rarely though, when would an incremental zone transfer be unavailable?). 6. QUESTION: Do we need the equivalent of a RECONFIRM message from DNS PUSH Notifications [I-D.ietf-dnssd-push]? Yes, a client may want to reconfirm that the zone it serves is not stale. The SOA REFRESH timer may expire without having received new changes, and so a RECONFIRM message to ensure the zone is fresh seems desirable. Best regards, Matthijs On 7/9/19 11:03 AM, Sara Dickinson wrote: > Hi All, > > A new draft has been submitted that outlines the basics of a DSO based mechanism for zone transfers requiring TLS. > > There is much more work to do on the details and potentially additional messaging to define but hopefully this includes information to get some initial feedback on this proposal. > > Best regards > > Sara. > >> On 8 Jul 2019, at 18:45, internet-drafts@ietf.org wrote: >> >> >> A new version of I-D, draft-zatda-dprive-xfr-using-dso-00.txt >> has been successfully submitted by Sara Dickinson and posted to the >> IETF repository. >> >> Name: draft-zatda-dprive-xfr-using-dso >> Revision: 00 >> Title: DNS Zone Transfer using DNS Stateful Operations >> Document date: 2019-07-08 >> Group: Individual Submission >> Pages: 21 >> URL: https://www.ietf.org/internet-drafts/draft-zatda-dprive-xfr-using-dso-00.txt >> Status: https://datatracker.ietf.org/doc/draft-zatda-dprive-xfr-using-dso/ >> Htmlized: https://tools.ietf.org/html/draft-zatda-dprive-xfr-using-dso-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-zatda-dprive-xfr-using-dso >> >> >> Abstract: >> DNS zone transfers are transmitted in clear text, which gives >> attackers the opportunity to collect the content of a zone by >> eavesdropping on network connections. This document specifies use of >> DNS Stateful Operations to enable a subscribe/publish mechanism for >> zone transfers reducing the over head introduced by NOTITY/SOA >> interactions prior to zone transfer request. This additionally >> prevents zone contents collection via passive monitoring of zone >> transfers by restricting XFR using DSO to require TLS. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy >
- Re: [dns-privacy] New Version Notification for dr… Sara Dickinson
- Re: [dns-privacy] New Version Notification for dr… Tom Pusateri
- Re: [dns-privacy] New Version Notification for dr… Sara Dickinson
- Re: [dns-privacy] New Version Notification for dr… Tony Finch
- Re: [dns-privacy] New Version Notification for dr… Matthijs Mekking