Re: [dnsext] DNS-AS RRTYPE PARAMETER ALLOCATION

Ray Bellis <ray@bellis.me.uk> Wed, 10 February 2016 12:26 UTC

Return-Path: <ray@bellis.me.uk>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A971A21A4 for <dnsext@ietfa.amsl.com>; Wed, 10 Feb 2016 04:26:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level:
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 YELhhi22Ne1O for <dnsext@ietfa.amsl.com>; Wed, 10 Feb 2016 04:26:41 -0800 (PST)
Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26CE01A21B2 for <dnsext@ietf.org>; Wed, 10 Feb 2016 04:26:41 -0800 (PST)
Received: from [46.227.151.81] (port=51655 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1aTTqv-000685-LH (Exim 4.72) (return-path <ray@bellis.me.uk>); Wed, 10 Feb 2016 12:26:37 +0000
To: wriedel@cisco.com
From: Ray Bellis <ray@bellis.me.uk>
X-Enigmail-Draft-Status: N1110
Message-ID: <56BB2C7E.2000206@bellis.me.uk>
Date: Wed, 10 Feb 2016 12:26:38 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsext/YHGWzdPDVBjm7C8qCdw4yTEaUrw>
Cc: dnsext@ietf.org
Subject: Re: [dnsext] DNS-AS RRTYPE PARAMETER ALLOCATION
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 10 Feb 2016 12:26:43 -0000

Wolfgang,

I've been appointed as the designated expert to review your RRTYPE
application per RFC 6895.

In principle the application is OK, and it's highly desirable that you
avoid use of TXT.

Within my remit however I do have some concerns over the name of the RRTYPE:

- the term "authoritative" has a particular meaning in the DNS
  protocol, and "authoritative source" is a commonly used term
  too.  Typing "dns authoritative source" into Google already
  produces 75,000 results, none that I could see relating to
  your project.

- using "DNS" within the RRTYPE name seems redundant - we're
  already in the DNS.

- the letters "AS" are also commonly used to refer to a BGP
  "Autonomous System".

[FWIW, when I first saw your requested mnemonic in the subject of your
application I was expecting to see an application for an RRTYPE to
represent a BGP AS number!]

Also missing is any explicit statement that the intended wire and
presentation format are identical to that of a TXT record.
Consideration should also be given to what happens if the data does not
fit within a single 255 octet "character-string" sub-field.

Incidentally, the "CISCO-CLS=" prefix in the RDATA would appear to be
redundant when you get your own RRTYPE, and if it's expected that other
vendors would use this then I suggest that you either omit it or use
something more neutral.

At a higher level I have concerns about the overall use case  that
should be addressed if you plan to document "DNS Authoritative Source"
in an Internet Draft (although I don't expect these to be a factor in my
decision as they're probably outside the scope of RFC 6895):

-  why DNS?  How does the client know what domain names are
   supposed to be looked up?

-  if the "Application Name" is the primary key, why not incorporate
   that into the domain name?

  - (corollary) is it expected that a client would want to (or even
    be allowed to) obtain information about all known applications at
    a domain with a single DNS query?

-  what about DNS Security?  What happens in your SDN if someone
   manages to poison a record?

The decision will be reached within two weeks of today, and before
approval the explicit linking to the TXT record format must be resolved.

I urge you to reconsider your project name of "DNS Authoritative Source"
as being a clash with existing terminology. I'm not currently inclined
to reject the application on that basis of the requested DNSAS mnemonic,
but welcome community feedback on that issue.

kind regards,

Ray Bellis