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

Mark Andrews <marka@isc.org> Fri, 31 March 2017 16:16 UTC

Return-Path: <marka@isc.org>
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 196E7129401 for <dnsop@ietfa.amsl.com>; Fri, 31 Mar 2017 09:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 bSBjy7fvpfhA for <dnsop@ietfa.amsl.com>; Fri, 31 Mar 2017 09:16:17 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 E6F62124D37 for <dnsop@ietf.org>; Fri, 31 Mar 2017 09:16:16 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 5DC4E3493C7; Fri, 31 Mar 2017 16:16:15 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 4D2A9160047; Fri, 31 Mar 2017 16:16:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 342A7160092; Fri, 31 Mar 2017 16:16:15 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Lvkh7wQVL-mr; Fri, 31 Mar 2017 16:16:15 +0000 (UTC)
Received: from rock.dv.isc.org (107-1-12-170-ip-static.hfc.comcastbusiness.net [107.1.12.170]) by zmx1.isc.org (Postfix) with ESMTPSA id ED8A3160047; Fri, 31 Mar 2017 16:16:14 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 5E3F46A6CAB2; Sat, 1 Apr 2017 03:16:10 +1100 (AEDT)
To: "John Levine" <johnl@taugh.com>
Cc: dnsop@ietf.org, peter.van.dijk@powerdns.com
From: Mark Andrews <marka@isc.org>
References: <20170331153357.6888.qmail@ary.lan>
In-reply-to: Your message of "31 Mar 2017 15:33:57 -0000." <20170331153357.6888.qmail@ary.lan>
Date: Sat, 01 Apr 2017 03:16:10 +1100
Message-Id: <20170331161610.5E3F46A6CAB2@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nz097b8Ha0njhlyfq_-NvAfzNb4>
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 16:16:20 -0000

The long term way to fix this is for DNS servers to *always* fill
in the additional section for select RR types (e.g. SRV) including
chasing down missing additional records and setting TC=1 if those
additional records will not fit for recursive queries.  TC=1 is
already required when glue records do not fit.

This lets the applications get the entire chain without having to
come back and ask again.  This service would be requested via a
EDNS option which will appear in the response and its presence in
the response indicates that the client does not have to query for
missing RRsets.  The recursive server is guarenteeing that the
response is complete.

Now if SRV is inappropriate for the application, e.g. because it
doesn't work well with wild cards, then a application specific RR
needs to be defined.

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.

Clients would ask for A, AAAA, and SRV in parallel until this is
well supported or we have a flag day after which A and AAAA records
should not be requested.

CNAME does 50% job.  Lets do something that does a 100% job.  Yes
it requires both DNS recursive servers and applications update their
behaviours.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org