IETF Logo Mail Archive

Re: [DNSOP] RFC7720 and AXFR

"A. Schulze" <sca@andreasschulze.de> Mon, 29 October 2018 15:51 UTC

Return-Path: <sca@andreasschulze.de>
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 460D9130DBE for <dnsop@ietfa.amsl.com>; Mon, 29 Oct 2018 08:51:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=andreasschulze.de header.b=7xyvweCC; dkim=pass (2048-bit key) header.d=andreasschulze.de header.b=UHX7/7qA
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 kJQC2c3nWPZY for <dnsop@ietfa.amsl.com>; Mon, 29 Oct 2018 08:51:33 -0700 (PDT)
Received: from mta.somaf.de (mta.somaf.de [IPv6:2001:470:77b3:103::25]) (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 7711212D4F0 for <dnsop@ietf.org>; Mon, 29 Oct 2018 08:51:33 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=andreasschulze.de; i=@andreasschulze.de; q=dns/txt; s=ed25519; t=1540828289; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : subject : from : date; bh=Ryq3WLvX/o0FR4KbaCJEkv299y6lFZFKbBFvqYp0BY8=; b=7xyvweCCg+jo80avr3PJumAP9bhbjHYOg1o4hmmIyi4hdej13FSYm8Tl gzAS2DygpIc/bx7uWj3iocZMzvE+AA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=20180930-2EE7; t=1540828289; x=1545828289; bh=Ryq3WLvX/o0FR4KbaCJEkv299y6lFZFKbBFvqYp0BY8=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To: Content-Type:from:reply-to:subject:date:to:cc:content-type: message-id; b=UHX7/7qAVC4243N5jPijvKFEir2/FGBgixmFFlMsZycj66KbHsk4MF0vzylEwdebv Dk145k+R3baAHCuJYZsra3sTxw/8903dpKqoJtAHGFVWYh3zn7u5KqDfk3tkwsY31R uF2X/14/4Dohe/TigDFe56mcIZD6oh4XdBPJ6wsJRjwn0slYvT5SIzqqgjxuALL/Cj eXNDZ7pOMDdwwCXdvVJN5xrcWQgaMRIALOCLcHCfoE+4ptwdswJaz+yVY1SUs9I7D7 4I36IzrjYBS/7US8s4znHsk48YJle3M7DjTpsH3XBjJ1cGKMnvihLPhLD5N/6to9Xd FBDzmG3YiVzeA==
To: dnsop@ietf.org
References: <2c00abd8-1c0d-cfee-5a5f-764a90f3f38c@andreasschulze.de> <20181028164441.GA22119@isc.org> <5BD5EE92.8070404@redbarn.org> <036d347d-3658-1007-7b9c-e1715916e58c@andreasschulze.de> <4244d902-2639-43eb-00f5-51947f018760@nic.cz>
From: "A. Schulze" <sca@andreasschulze.de>
Message-ID: <16237947-9240-1aaf-11af-d2f3f6ce429d@andreasschulze.de>
Date: Mon, 29 Oct 2018 16:51:08 +0100
MIME-Version: 1.0
In-Reply-To: <4244d902-2639-43eb-00f5-51947f018760@nic.cz>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IRIsxddrbyA7G_T1fKB69eLPduI>
Subject: Re: [DNSOP] RFC7720 and AXFR
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 29 Oct 2018 15:51:37 -0000


Am 29.10.18 um 14:49 schrieb Petr Špaček:
> Well, AXFR is not strictly necessary.
> 
> E.g. implementation of RFC 7706-like feature in Knot Resolver pulls zone
> file from a HTTPS URL so it can reuse any CDN you like (or not).

Well, good point!

unbound behave similar.

So it would be simply some homework for ICANN to provide the zones in a stable manner.
I don't know if that's maybe already the case for lax.xfr.dns.icann.org and iad.xfr.dns.icann.org.

Out job is provide example configurations for knot resolver and unbound
and probably other resolver...

On the long term this could motivate more admins to apply RFC7706
(Decreasing Access Time to Root Servers by Running One on Loopback)

Anyone from ICANN to take that job?

Andreas

v2.23.0 | Report a Bug | By Email