Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

Florian Weimer <> Thu, 20 April 2017 09:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5300212EBBB for <>; Thu, 20 Apr 2017 02:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u8w-F33BXtAk for <>; Thu, 20 Apr 2017 02:21:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC58512EBA4 for <>; Thu, 20 Apr 2017 02:21:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 772283DBF2; Thu, 20 Apr 2017 09:21:40 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 772283DBF2
Authentication-Results:; dmarc=none (p=none dis=none)
Authentication-Results:; spf=pass
DKIM-Filter: OpenDKIM Filter v2.11.0 772283DBF2
Received: from ( []) by (Postfix) with ESMTPS id B24DC17AD4; Thu, 20 Apr 2017 09:21:39 +0000 (UTC)
To: Evan Hunt <>, Paul Wouters <>
Cc: dnsop <>
References: <20170414200316.86192.qmail@ary.lan> <> <> <>
From: Florian Weimer <>
Message-ID: <>
Date: Thu, 20 Apr 2017 11:21:38 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.79 on
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 ( []); Thu, 20 Apr 2017 09:21:40 +0000 (UTC)
Archived-At: <>
Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Apr 2017 09:21:42 -0000

On 04/20/2017 08:36 AM, Evan Hunt wrote:
> On Wed, Apr 19, 2017 at 10:47:24PM -0400, Paul Wouters wrote:
>> ANAME could just be a regular RRTYPE without any special handling,
>> meaning "go look there for up to date information on A/AAAA". It could
>> come along A/AAAA records using one of the existing bitmaps multi-type
>> query proposals that have been suggested in the last two years.
> But, because there are always going to be legacy servers, the client would
> then need to send an ANAME query, and when it got no answer, send another
> query for A and AAAA.
> If clients were willing to do that, then they'd have been willing to use
> SRV, and we'd have standardized on that long since.

This is simply not true.  SRV is broken for almost any purpose, which is 
why it is only used for protocols which have mandated its use.

Most name lookup interfaces only take a name and return an address. 
With these interfaces, it is technically impossible to synthesize a 
query name for a SRV lookup, and return the port number in the SRV 
record to the caller.  (This even true for the RFC 3493 interface, which 
is often used without a service name argument, or a numeric service name.)

An ANAME query to find a substitution name does not suffer from this 
problem.  It fits well with existing name lookup interfaces.

> Which would've been
> fine, but browser vendors have had years to do it, and they never have.

Why are you focusing on browsers?  This is about the system name 
resolution service, which browsers still use to perform NIS/WINS/LDAP 
host name lookups, not just DNS.  As I tried to explain above, SRV is 
incompatible with most of the traditional system name resolution 
interfaces.  A name substitution with an ANAME redirection would not 
have this problem.

> Apparently, what they want is to send address queries and get redirected
> answers. And if we can't make them do the smart thing, at least we can
> give them an interoperable and standards-compliant way to do the dumb
> thing.

I have no idea how to map most URI schemes to SRV lookups and resolve 
conflicts between port numbers, transport protocols in use (e.g., if 
QUIC is active), and service names (should an XMLRPC request get a 
different name?).  Without that mapping, there is nothing that browser 
vendors could implement.

What I'm trying to say: The SRV failure is not sufficient evidence that 
client-side name substitution would not see significant uptake because 
SRV works at the wrong layer(s).