Re: [DNSOP] Variant bad idea of the day
"John R Levine" <johnl@taugh.com> Tue, 01 January 2019 18:23 UTC
Return-Path: <johnl@taugh.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 63021128D52 for <dnsop@ietfa.amsl.com>; Tue, 1 Jan 2019 10:23:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=CqUvNUPi; dkim=pass (1536-bit key) header.d=taugh.com header.b=EzJazAe/
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 2Ga6zBvvaYhe for <dnsop@ietfa.amsl.com>; Tue, 1 Jan 2019 10:23:26 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 B50A3124408 for <dnsop@ietf.org>; Tue, 1 Jan 2019 10:23:25 -0800 (PST)
Received: (qmail 41480 invoked from network); 1 Jan 2019 18:23:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a206.5c2bb019.k1901; bh=aFO/BpMaiXt/CLKKMEyMv/nhaIE3Wil4oMth9XwrpUk=; b=CqUvNUPiH9/z6v5asVL3flA2nMBIw9gLY242Mayrwrs+pCD3rEo1zHs2ynHJ64xttb/rvYCe7XmeiXzHJbCJv7YtsJI+paPNoTtnrdlBjIRgllvuw5GHEJMEPP2vcrG/SbX2VK6fZof+LwTlB1gWuD6v/GuS1i0D9wfE65SiOIDYrZ9soCZzEcDha7teDNX9U4LL8E7lWTX+9M7XxDR+cCZqBXSJcmjqNtKpsuYQXRWB87Fhoj1ZbtXpLPkCJlDV
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a206.5c2bb019.k1901; bh=aFO/BpMaiXt/CLKKMEyMv/nhaIE3Wil4oMth9XwrpUk=; b=EzJazAe/mL5C2H4WScCQVfvMa89tMF8G9Wj7wdD4HqCahbWpGcmfoWr1Hd2dQaSPeqfA77qmrX74D1KEnfuEPukJndRF0dw/gc1Z4nSbyVZgdf/BJg7fI2Cz0IEqbqRPE1GpVx7+sGWAdZeeOPM0G8BGg+DMDYMPXEv4X1lAfw8o2+04ni5N/ZzM6zQaNuMkP9IcebOesIkI/fNrEGlMga0gduZtPer4MDxk/YWXOKP5kg9BL4/kOORR8T9S0Kgf
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 01 Jan 2019 18:23:21 -0000
Date: Tue, 01 Jan 2019 13:23:20 -0500
Message-ID: <alpine.OSX.2.21.1901011313460.82866@ary.local>
From: John R Levine <johnl@taugh.com>
To: Patrik Fältström <paf@frobbit.se>
Cc: dnsop@ietf.org
In-Reply-To: <B2BF3312-575F-423A-8F4C-6F8294DA5929@frobbit.se>
References: <alpine.OSX.2.21.1812311912250.81953@ary.local> <6245AC94-7E00-46A2-8BCD-B734A30B67C7@frobbit.se> <alpine.OSX.2.21.1901011128390.82740@ary.local> <B2BF3312-575F-423A-8F4C-6F8294DA5929@frobbit.se>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-2099227107-1546367001=:82866"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xUfzjpX6UDbe6t3IqnXcn9Z3aVw>
Subject: Re: [DNSOP] Variant bad idea of the day
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: Tue, 01 Jan 2019 18:23:27 -0000
On Tue, 1 Jan 2019, Patrik Fältström wrote: >> Not just at foo, but do the same thing on any name under foo. The idea is to publish the LGR for the subtree and the server can handle all of the variants from one zone. > > Got it. As long as the query reaches this server of course. You also > mean auth servers from delegated zones can query for this explicitly and > load its internal LGR from its parent? I hadn't worked it out that far but it would be a good idea if servers could automatically find out what their default variant rules are. It's rather unexplored territory since until now a name server doesn't know or need to know what the parent servers for its zones are. We do have the example of DS above and DNSKEY below to prove that two servers are in the same chain of authority, but that doesn't tell us how the child can locate the parent other than chasing down from the root. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly
- [DNSOP] Variant bad idea of the day John R Levine
- Re: [DNSOP] Variant bad idea of the day Patrik Fältström
- Re: [DNSOP] Variant bad idea of the day John R Levine
- Re: [DNSOP] Variant bad idea of the day Patrik Fältström
- Re: [DNSOP] Variant bad idea of the day John R Levine
- Re: [DNSOP] Variant bad idea of the day Brian Dickson
- Re: [DNSOP] Variant bad idea of the day John R Levine