Re: [DNSOP] New draft for ALIAS/ANAME type

"John R Levine" <johnl@taugh.com> Fri, 31 March 2017 18:01 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 A5301129450 for <dnsop@ietfa.amsl.com>; Fri, 31 Mar 2017 11:01:09 -0700 (PDT)
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=Mh7Yar3J; dkim=pass (1536-bit key) header.d=taugh.com header.b=B5B5GAtl
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 O7GzXk-yCxwn for <dnsop@ietfa.amsl.com>; Fri, 31 Mar 2017 11:01:08 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA96D12441E for <dnsop@ietf.org>; Fri, 31 Mar 2017 11:01:07 -0700 (PDT)
Received: (qmail 66433 invoked from network); 31 Mar 2017 18:01:05 -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=1037e.58de9961.k1703; bh=vBvWO72FS2p9G1/BqOVEhCI9f4H5Lqqa4Nnrv88aqWY=; b=Mh7Yar3JEgDe4WKrMei9geI4q4QpuH9tH74/NVHFMYsxtxlEtA3CVfZNsNWtueq1MiuHrQ+hOJm9o+0qlBEIx0uZgYA60h0Gs/gEnLpf8zBT7mXFZ6ND9TADnrECbMmFHO9snk1KkzWSRCzOib/V0hlf4BabPV+0xhWo3dqhIwrmDCJ7e1NZ+qaHcOR5cFHEpzocwyPQwNpHHdH7eChkVUBKmhxsNBSL8iLrEea+oIyxu9McclzpjaiZ5PIllCP4
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=1037e.58de9961.k1703; bh=vBvWO72FS2p9G1/BqOVEhCI9f4H5Lqqa4Nnrv88aqWY=; b=B5B5GAtlZGkqiu7ggNBBdDeUC2yMXLR5zgm9OR/k5TLriZ3EGHOvR3SIIoCzB7aWQwPLgAK/ECA5fq83U4X4BBpy+xM0RrPJvghjrREXTCQW2rJWO62HZF7B2H2qrETZTMG6oTE/Q0rPTQUhS07GxtAod5QEu6UV2+gvz1BiG1ar05Yt6kgnShc7f8H9Oxj0uNRjPfs6cgAhIZDNWR98ZlROY9BWqsoti5Zu32k9vEzsVxP5EOLWKwIO3jlmvoU/
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; 31 Mar 2017 18:01:05 -0000
Date: 31 Mar 2017 13:01:03 -0500
Message-ID: <alpine.OSX.2.20.1703311243310.10405@ary.local>
From: "John R Levine" <johnl@taugh.com>
To: "Mark Andrews" <marka@isc.org>
Cc: dnsop@ietf.org, peter.van.dijk@powerdns.com
In-Reply-To: <20170331161610.5E3F46A6CAB2@rock.dv.isc.org>
References: <20170331153357.6888.qmail@ary.lan> <20170331161610.5E3F46A6CAB2@rock.dv.isc.org>
User-Agent: Alpine 2.20 (OSX 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DtL5iP1V4kC-rR66gYPdUieJiWM>
Subject: Re: [DNSOP] New draft for ALIAS/ANAME type
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 31 Mar 2017 18:01:10 -0000

> This gets you a single lookup with no followup queries required
> once the recursive server supports this.  If the client is still
> talking to a legacy server it would still need to do followup queries
> for missing records.

I like this but there's an obvious question: if the recursive server has 
to know about ANAME anyway, have the it do the extra fetches, and all of 
the DNSSEC troubles go away.

Straw man, er, straw being:

name ANAME canonname servername rrtype1 rrtype2 ...

If the authoritative server gets a request for one of the rrtypes, it 
returns the ANAME.  (If it gets a request for a type that isn't in the 
ANAME and there isn't a real RR, it returns the usual NOERROR.)  The cache 
sees the ANAME and looks up the canonname from the server at servername 
(with "." as the servername default to look it up in the usual way.) 
Putting an actual rrtypeI at the same name as the ANAME is naughty, like 
putting it at the same name as a CNAME.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly