[dnsext] Review request: AMTRELAY RRType

"Holland, Jake" <jholland@akamai.com> Mon, 14 January 2019 05:54 UTC

Return-Path: <jholland@akamai.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5A01E130F52 for <dnsext@ietfa.amsl.com>; Sun, 13 Jan 2019 21:54:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.253
X-Spam-Status: No, score=-5.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kDr4hhYbKTHG for <dnsext@ietfa.amsl.com>; Sun, 13 Jan 2019 21:54:35 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 2DD5912008A for <dnsext@ietf.org>; Sun, 13 Jan 2019 21:54:35 -0800 (PST)
Received: from pps.filterd (m0050102.ppops.net []) by m0050102.ppops.net-00190b01. ( with SMTP id x0E5qGm4020539; Mon, 14 Jan 2019 05:54:34 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=E7F83S6VDp4AmL+u6LIVfoh13K37hP/yX++0/PfdGLU=; b=XIEL1lYfAuQ2qft9oCpKqwGb4KXnjDlOAv8Qnp1TT+xpFy7KrufWlw1tpROgdHDIMCI9 JOjzAviHdGUtJYvchVj1XWXwWg16V/vBHW/h3d3vO+/UYisWvVarAuNhDxi+ei1qWS00 tCk2cc3QPN58Ipwph7cK/rLUceAY46wj3Peah9OAHjOgkrTS5zXOkRTRlKnXJ5UqvDhs Q40GY2vNeHczW3894CxApWHEKfxM76QChwCmrXots4wKjjJUMrCiJk5x4TTKOfcz111y Mir3m2XCLGRmm/PLfLO6QMQ4zv74p2/YkFej+ZeFgFHOl7RbiH4ULHAzjmhRZoH0Op6l lQ==
Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2pycv3nnap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Jan 2019 05:54:33 +0000
Received: from pps.filterd (prod-mail-ppoint4.akamai.com []) by prod-mail-ppoint4.akamai.com ( with SMTP id x0E5lDnY024625; Mon, 14 Jan 2019 00:54:16 -0500
Received: from email.msg.corp.akamai.com ([]) by prod-mail-ppoint4.akamai.com with ESMTP id 2pycf0ph6g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 14 Jan 2019 00:54:16 -0500
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ( by ustx2ex-dag1mb2.msg.corp.akamai.com ( with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sun, 13 Jan 2019 23:54:16 -0600
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([]) with mapi id 15.00.1365.000; Sun, 13 Jan 2019 23:54:15 -0600
From: "Holland, Jake" <jholland@akamai.com>
To: "dnsext@ietf.org" <dnsext@ietf.org>
CC: Jake Holland <jakeholland.net@gmail.com>, "Holland, Jake" <jholland@akamai.com>
Thread-Topic: Review request: AMTRELAY RRType
Thread-Index: AQHUq82URMg726snZUqUvPFuqhFX5Q==
Date: Mon, 14 Jan 2019 05:54:14 +0000
Message-ID: <4D6E764D-A923-46E4-AB50-951181D4F516@akamai.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <385FAC30BE1B8F4AA18A63996C7EE95C@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-14_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901140051
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-14_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901140049
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsext/RlfWKTo43fn6yDL2junKawiwyUY>
Subject: [dnsext] Review request: AMTRELAY RRType
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Jan 2019 05:54:37 -0000

Hi dnsext folks,

I'm writing to solicit feedback on a request for a new RRType in
draft-jholland-mboned-driad-amt-discovery, ahead of a formal request
to dns-rrtype-applications (as encouraged in section 3.1.1 of RFC 6895).

Here's the RRType form (also in appendix A of the draft).

A. Submission Date: [hopefully soon]

B.1 Submission Type:
 [x] New RRTYPE  [ ] Modification to RRTYPE
B.2 Kind of RR:
 [x] Data RR     [ ] Meta-RR

C. Contact Information for submitter (will be publicly posted):
 Name:  Jake Holland
 Email Address: jakeholland.net@gmail.com
 International telephone number: +1-626-486-3706
 Other contact handles: jholland@akamai.com

D. Motivation for the new RRTYPE application.
 It provides a bootstrap so AMT (RFC 7450) gateways can discover
 an AMT relay that can receive multicast traffic from a specific source,
 in order to signal multicast group membership and receive multicast
 traffic over a unicast tunnel using AMT.

E. Description of the proposed RR type.
   This description can be provided in-line in the template, as an
   attachment, or with a publicly available URL.
 Please see draft-jholland-mboned-driad-amt-discovery.

F. What existing RRTYPE or RRTYPEs come closest to filling that need
   and why are they unsatisfactory?
 Some similar concepts appear in IPSECKEY, as described in
 Section 1.2 of [RFC4025]. The IPSECKEY RRType is unsatisfactory
 because it refers to IPSec Keys instead of to AMT relays, but
 the motivating considerations for using reverse IP and for
 providing a precedence are similar--an AMT gateway often
 has access to a source address for a multicast (S,G), but does
 not have access to a relay address that can receive multicast
 traffic from the source, without administrative configuration.

 Defining a format for a TXT record could serve the need for AMT
 relay discovery semantics, but Section 5 of [RFC5507] provides a
 compelling argument for requesting a new RRType instead.

G. What mnemonic is requested for the new RRTYPE (optional)?

H. Does the requested RRTYPE make use of any existing IANA registry
   or require the creation of a new IANA subregistry in DNS
 Yes, IANA is requested to create a subregistry named "AMT Relay
 Type Field" in a "AMTRELAY Resource Record Parameters" registry.
 The field values are defined in Section 4.2.3 and Section 4.2.4,
 and a summary table is given in Section 5.

I. Does the proposal require/expect any changes in DNS
   servers/resolvers that prevent the new type from being processed
   as an unknown RRTYPE (see RFC3597)?

J. Comments:
 It may be worth noting that the gateway type field from Section 2.3 of
 [RFC4025] and Section 2.5 of [RFC4025] is very similar to the
 Relay Type field in this request.  I tentatively assume that trying to
 re-use that sub-registry is a worse idea than duplicating it, but I'll
 invite others to consider the question and voice an opinion, in case
 there is a different consensus.


I also have one additional request for DNS expert opinion about text that appears
in section 2.4:

I borrowed the language from https://tools.ietf.org/html/rfc4025#section-1.2,
but I'm not actually sure what "the fashion usual for PTR records" means,

   When the reverse IP mapping has no AMTRELAY RR but does have a PTR
   record, the lookup is done in the fashion usual for PTR records.  The
   IP address' octets (IPv4) or nibbles (IPv6) are reversed and looked
   up with the appropriate suffix.  Any CNAMEs or DNAMEs found MUST be
   followed, and finally the AMTRELAY RR is queried with the resulting
   domain name.

Does that mean I'd do an A/AAAA query for the domain name from the PTR, follow
CNAME/DNAMEs until the A/AAAA is resolved and use the final name that
found an answer (if any) to do the AMTRELAY (or IPSECKEY) query?  (That would
work I think, but it seems like a lot of round-trips...)

Thanks in advance for any advice you can offer.