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: 1 Jan 2019 13:23:20 -0500
Message-ID: <alpine.OSX.2.21.1901011313460.82866@ary.local>
From: "John R Levine" <johnl@taugh.com>
To: "=?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?=" <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