Re: [DNSOP] CloudFlare policy on ANY records changing

Tony Finch <dot@dotat.at> Fri, 13 March 2015 11:10 UTC

Return-Path: <fanf2@hermes.cam.ac.uk>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951601A01AA for <dnsop@ietfa.amsl.com>; Fri, 13 Mar 2015 04:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ENcVEerrHmiq for <dnsop@ietfa.amsl.com>; Fri, 13 Mar 2015 04:10:23 -0700 (PDT)
Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) (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 8F4E41A0110 for <dnsop@ietf.org>; Fri, 13 Mar 2015 04:10:23 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:56705) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1YWNTu-000363-Yu (Exim 4.82_3-c0e5623) (return-path <fanf2@hermes.cam.ac.uk>); Fri, 13 Mar 2015 11:10:18 +0000
Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1YWNTu-0001g1-O4 (Exim 4.72) (return-path <fanf2@hermes.cam.ac.uk>); Fri, 13 Mar 2015 11:10:18 +0000
Date: Fri, 13 Mar 2015 11:10:18 +0000
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Evan Hunt <each@isc.org>
In-Reply-To: <20150313003003.GB65353@isc.org>
Message-ID: <alpine.LSU.2.00.1503131036040.10193@hermes-1.csi.cam.ac.uk>
References: <0A8D7AE0-B6FF-4B85-A42B-4EBF93A17873@verisign.com> <54FF86CB.7010705@redbarn.org> <20150311015710.GB10189@isc.org> <alpine.LSU.2.00.1503111205440.10193@hermes-1.csi.cam.ac.uk> <20150311150622.GA91255@isc.org> <alpine.LSU.2.00.1503111617130.23307@hermes-1.csi.cam.ac.uk> <20150311171535.GC91255@isc.org> <alpine.LSU.2.00.1503111723080.10193@hermes-1.csi.cam.ac.uk> <871tku18np.fsf@mid.deneb.enyo.de> <49DEE35910F1A6438E9805F4DEBBA30715CC32C0@038-CH1MPN1-041.038d.mgd.msft.net> <20150313003003.GB65353@isc.org>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: Tony Finch <fanf2@hermes.cam.ac.uk>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/cnUjQJFv-HBdEGcyvxoBCUTk03o>
Cc: dnsop <dnsop@ietf.org>, "Darcy Kevin (FCA)" <kevin.darcy@fcagroup.com>
Subject: Re: [DNSOP] CloudFlare policy on ANY records changing
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 13 Mar 2015 11:10:32 -0000

Evan Hunt <each@isc.org> wrote:
>
> This could be a pretty brilliant solution, actually: If you're
> authoritative for a signed zone and you receive a query of type ANY,
> return the applicable NSEC/NSEC3; if the zone is *not* signed, synthesize
> a response containing a single RR with a type from the "private use" range
> (e.g. TYPE65531 or whatever), zero length rdata, and a long TTL.  The
> resolver would get an answer, so it stops asking; it would *not* cache
> the answer as an empty node, so subsequent queries for other qtypes can
> still resolve.

I tried this and it works OK. In the below, > is an nsupdate prompt and $
is a shell prompt in another window.

# set up fake ANY response
> add bar.mini.dotat.at 60 in type6666 \# 1 66
> send

# cache fake ANY response
$ dig +short bar.mini.dotat.at any
\# 1 66

# set up real response
> del bar.mini.dotat.at
> add bar.mini.dotat.at 60 in txt "booze"
> send

# name server fetches missing RRsets
$ dig +short bar.mini.dotat.at txt
"booze"

> I like this better than any of the prior suggestions.  (It doesn't
> address qmail's problem, but that's a lost cause no matter which method
> is chosen.)

This will work with qmail. Its query sequence is: ANY (for CNAME-based
rewriting and to prime the cache); MX (for delivery); fallback to A.

With this proposal, it will get a no-CNAME reply to ANY, so it will not
rewrite the address. Then it will get the same answers as before to its MX
etc. queries. The delivery will proceed OK.

Slightly interesting things occur if there is actually a CNAME at the
query name, but this is the same as what would happen if you are lucky
enough to make these queries while the QNAME changes from not-a-CNAME to
actually-a-CNAME. So it is OK to always give a fake reply to an ANY query.

If you are feeling generous when you implement this idea, you can add a
special case when the QNAME is a CNAME and return that, which will
preserve qmail's rewriting behaviour.

When you have cached non-CNAME data at a name and a subsequent query gets
a CNAME answer, the CNAME overrides the existing data at that name if you
make more not-ANY queries. But you can get some, um, interesting responses
to ANY queries.

; <<>> DiG 9.11.0pre-alpha <<>> bar.mini.dotat.at any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54981
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bar.mini.dotat.at.             IN      ANY

;; ANSWER SECTION:
bar.mini.dotat.at.      3596    IN      CNAME   localhost.
bar.mini.dotat.at.      3578    IN      TXT     "booze"

;; AUTHORITY SECTION:
mini.dotat.at.          86400   IN      NS      mini.dotat.at.

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Mar 13 11:00:27 GMT 2015
;; MSG SIZE  rcvd: 101

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Viking, North Utsire: Southerly 6 to gale 8, decreasing 4 or 5. Rough or very
rough, becoming moderate or rough. Fair. Good.