"Wolfgang Riedel (wriedel)" <> Sat, 13 February 2016 20:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D6C031A7013 for <>; Sat, 13 Feb 2016 12:36:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -13.806
X-Spam-Status: No, score=-13.806 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fizRxFmbGErj for <>; Sat, 13 Feb 2016 12:36:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C4991A1AB3 for <>; Sat, 13 Feb 2016 12:36:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=24772; q=dns/txt; s=iport; t=1455395801; x=1456605401; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=M4Zre4w66sk4oaiGdGcH2kzUY+krGUQJElx1ZqhQi2Q=; b=JkhV5EJvNsGELQKp6zKGNFQx0VQHKwt291i8/zDX8nDfr6u9gL3ATpo6 ssWEfycTSX281E+m2IpaRlvJrmhbngG30tI/DNVYHT+TJrfGqE1m8epPi JeFh2MIcP1Y4ttUNSff5slkw7sTlR13WCa2a+4UHfnP/RYoru+At7VACo o=;
X-Files: signature.asc : 872
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.22,442,1449532800"; d="asc'?scan'208,217";a="238045796"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2016 20:36:40 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u1DKadIT024899 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 13 Feb 2016 20:36:40 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 13 Feb 2016 14:36:39 -0600
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Sat, 13 Feb 2016 14:36:39 -0600
From: "Wolfgang Riedel (wriedel)" <>
To: Ray Bellis <>
Thread-Index: AQHRY/5NTWKudmU6QEKjV5II8zU5uZ8q2Q6A
Date: Sat, 13 Feb 2016 20:36:38 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_F8EDD7BC-C6D6-410A-8E5F-90BE60FCDC47"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Approved-At: Sat, 13 Feb 2016 13:42:04 -0800
Cc: "" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 13 Feb 2016 20:36:44 -0000

Hi Ray,

may thanks for your reply.

I consultant with some colleagues and were good with filing a new request and replace the mnemonic = DNSAS with mnemonic = AVC as you suggested.
Also some answer to your question inline.

For all other on list, if you’re looking for more details on DNS-AS please have look at

Thank you,

> On 10 Feb 2016, at 13:26PM, Ray Bellis <> wrote:
> 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.

yes I agree and we have chosen the wording by intension to outline that we leverage the authoritative name server as a sigle source of truth for application metadata.

> - 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!]

it’s not so far off given that BGP expresses routing policy intend and DNS-AS metadata for application policy intend

> 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.

OK will adress this

> 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.

yes good catch and I agree and will remove this

> 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):

at this time there are not plans to submit this as an Internet Draft

> -  why DNS?

Readily available tool - already leveraged to identify an application by DNS-NAME

> How does the client know what domain names are supposed to be looked up?

it’s a function of an DNS-AS client which snoop DNS request as an trigger and raises it’s own query for a DNS-AS Resource Record to get the metadata to enforce policy later

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

This ‘could be done’ - but most customers don’t or won’t always identify what application is running on a server via it’s FQDN.

>  - (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?

there is nothing confidential inside a DNS-AS resource record.
The key is that it it authoritative!

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

what happens if I haven't done my homework and didn’t secure and harden my DNS infrastructure ;-)
If DNS is compromised you have bigger problems than how a network element chooses mark and service (queue) for a given application...

> 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.

yes will file a new request for mnemonic = AVC

> kind regards,
> Ray Bellis