Re: [DNSOP] Clarifying referrals (#35)

Johannes Naab <naab@net.in.tum.de> Fri, 23 March 2018 23:31 UTC

Return-Path: <naab@net.in.tum.de>
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 9A8A612E868 for <dnsop@ietfa.amsl.com>; Fri, 23 Mar 2018 16:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 MZDJQpVDbXBr for <dnsop@ietfa.amsl.com>; Fri, 23 Mar 2018 16:30:59 -0700 (PDT)
Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E6B12E890 for <dnsop@ietf.org>; Fri, 23 Mar 2018 16:30:58 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 00B94282F00; Sat, 24 Mar 2018 00:30:51 +0100 (CET)
Date: Sat, 24 Mar 2018 00:30:50 +0100
From: Johannes Naab <naab@net.in.tum.de>
To: dnsop@ietf.org
Cc: Andrew Sullivan <ajs@anvilwalrusden.com>
Message-ID: <20180323.7e0ea201f1e40763f6991d62df0dd57f@localhost>
References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20180115213920.ukw3wxxdarapzfop@mx4.yitter.info>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20180115213920.ukw3wxxdarapzfop@mx4.yitter.info>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/O2joU4XYBV_qnyHll8QA0HPG1JY>
Subject: Re: [DNSOP] Clarifying referrals (#35)
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, 23 Mar 2018 23:31:03 -0000

On Mon, Jan 15, 2018 at 04:39:20PM -0500, Andrew Sullivan wrote:
>       A response that has only a referral contains an empty answer
>       section.  It contains the NS RRset for the referred-to zone in the
>       authority section.  It may contain RRs that provide addresses in
>       the additional section.  The AA bit is clear.

Hi all,

the behaviour with respect to the (clear) AA bit is not completely
observed in the wild:

ba.anycastdns.cz (185.38.108.108, 185.28.194.194) is authoritative for
.ba given by the root zone, they return the following referrals:

% dig +norec @185.28.194.194 google.ba.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48224
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1480
;; QUESTION SECTION:
;google.ba.                     IN      A

;; AUTHORITY SECTION:
google.ba.              86400   IN      NS      ns1.google.com.
google.ba.              86400   IN      NS      ns2.google.com.

;; Query time: 70 msec
;; SERVER: 185.28.194.194#53(185.28.194.194)
;; WHEN: Sat Mar 24 00:01:18 CET 2018
;; MSG SIZE  rcvd: 84

I.e. a referral, but with AA-bit.

Both Unbound and BIND appear to treat this as delegation:
https://github.com/NLnetLabs/unbound/blob/release-1.7.0/iterator/iter_resptype.c#L270
(since at least 2007, including the comment about the AA-bit)

https://gitlab.isc.org/isc-projects/bind9/blob/b2307b25465c16d37ff6de22438a2d214287417c/lib/dns/resolver.c#L603 and L7314
(Not 100% sure)

RFC 2308 2.2 does not specifically care about the AA-bit:

>   It is possible to distinguish between a NODATA and a referral
>   response by the presence of a SOA record in the authority section or
>   the absence of NS records in the authority section.


My current take away:
The clean interpretation would be a NODATA response.
But based on practical evidence and implementations, such responses are
to be treated as referrals.
anycastdns.cz should change the name servers behaviour.

Best regards,
Johannes

-- 
Johannes Naab