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.
- Re: [DNSOP] CloudFlare policy on ANY records chan… Evan Hunt
- Re: [DNSOP] CloudFlare policy on ANY records chan… Florian Weimer
- Re: [DNSOP] CloudFlare policy on ANY records chan… Florian Weimer
- Re: [DNSOP] CloudFlare policy on ANY records chan… Florian Weimer
- [DNSOP] CloudFlare policy on ANY records changing Wessels, Duane
- Re: [DNSOP] CloudFlare policy on ANY records chan… Paul Vixie
- Re: [DNSOP] CloudFlare policy on ANY records chan… Evan Hunt
- Re: [DNSOP] CloudFlare policy on ANY records chan… Tony Finch
- Re: [DNSOP] CloudFlare policy on ANY records chan… Evan Hunt
- Re: [DNSOP] CloudFlare policy on ANY records chan… Tony Finch
- Re: [DNSOP] CloudFlare policy on ANY records chan… Evan Hunt
- Re: [DNSOP] CloudFlare policy on ANY records chan… Tony Finch
- Re: [DNSOP] CloudFlare policy on ANY records chan… Paul Vixie
- Re: [DNSOP] CloudFlare policy on ANY records chan… Jared Mauch
- Re: [DNSOP] CloudFlare policy on ANY records chan… Florian Weimer
- Re: [DNSOP] CloudFlare policy on ANY records chan… Darcy Kevin (FCA)
- Re: [DNSOP] CloudFlare policy on ANY records chan… Evan Hunt
- Re: [DNSOP] CloudFlare policy on ANY records chan… Tony Finch
- Re: [DNSOP] CloudFlare policy on ANY records chan… Tony Finch
- Re: [DNSOP] CloudFlare policy on ANY records chan… Evan Hunt