IETF Logo Mail Archive

Re: [DNSOP] CloudFlare policy on ANY records changing

"Darcy Kevin (FCA)" <kevin.darcy@fcagroup.com> Thu, 12 March 2015 23:38 UTC

Return-Path: <kevin.darcy@fcagroup.com>
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 D9A641A8841 for <dnsop@ietfa.amsl.com>; Thu, 12 Mar 2015 16:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 w1ACanW9fAYf for <dnsop@ietfa.amsl.com>; Thu, 12 Mar 2015 16:38:07 -0700 (PDT)
Received: from odbmap02.extra.chrysler.com (odbmap02.out.extra.chrysler.com [129.9.40.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35AA41A882A for <dnsop@ietf.org>; Thu, 12 Mar 2015 16:38:07 -0700 (PDT)
Received: from shbmap04.shdc.chrysler.com (Unknown_Domain [53.28.160.92]) by odbmap02.extra.chrysler.com (Symantec Messaging Gateway) with SMTP id EE.D0.16364.D5322055; Thu, 12 Mar 2015 19:38:05 -0400 (EDT)
X-AuditID: 8109281a-b7f7b6d000003fec-80-5502235d90b9
Received: from mail.chrysler.com (Unknown_Domain [151.171.240.14]) by shbmap04.shdc.chrysler.com (Symantec Messaging Gateway) with SMTP id 30.71.05140.C5322055; Thu, 12 Mar 2015 19:38:04 -0400 (EDT)
Received: from 038-CH1MPN1-041.038d.mgd.msft.net ([169.254.1.125]) by 038-CH1MMR1-003.038d.mgd.msft.net ([151.171.240.14]) with mapi id 14.03.0224.003; Thu, 12 Mar 2015 23:38:04 +0000
From: "Darcy Kevin (FCA)" <kevin.darcy@fcagroup.com>
To: dnsop <dnsop@ietf.org>
Thread-Topic: [DNSOP] CloudFlare policy on ANY records changing
Thread-Index: AQHQW4Bk5v2xx91fRkSuzMP5GZWVq50WZyyAgAAfMgCAAKxBAIAAMD8AgAAZ+ICAAAoigIAAA0EAgAGCT9WAAGqSsA==
Date: Thu, 12 Mar 2015 23:38:04 +0000
Message-ID: <49DEE35910F1A6438E9805F4DEBBA30715CC32C0@038-CH1MPN1-041.038d.mgd.msft.net>
References: <CAGmQtQJta4EXRD4pLOk=xVH0dGirHeb=edkPTMWLmKXBcBVK0Q@mail.gmail.com> <5B445B49-BA18-493A-A1EA-DC90C7C6D7AE@vpnc.org> <21759.4545.472775.866594@tale.kendall.corp.akamai.com> <F6A39307-6C8F-4FD5-8CAD-97775C5276A9@vpnc.org> <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>
In-Reply-To: <871tku18np.fsf@mid.deneb.enyo.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.143.13.209]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsViKrMgRjdWmSnUYO9lE4u7by6zODB6LFny kymAMYrLJiU1J7MstUjfLoEr48Ma/YKPvBUH581jb2CcyN3FyMkhIWAi8XVBIzOELSZx4d56 ti5GLg4hgQuMEp97lzPBFE2cu58JInGCUeJM3wUWCGc3o8SDxsVgVWxAVQuv3AUbJSIgJfFs 1iOgIg4OYQE7if2fCyDC9hJbD/eyQthZEjd2bgUrZxFQlTh4qZcNxOYViJCYsPIp1Pw+Vomb 616CJTgF9CU6DvaB2YxAp34/tQZsL7OAuMStJ/OhLhWQWLLnPNQ7ohIvH/9jhbAVJTYt2swI Ua8jsWD3JzYIW1ti2cLXzBCLBSVOznwCtlhC4C+rxO21B5gnMErMQrJjFpL+WUj6ZyHpX8DI sopROj8lKTexwMBIL7WipChRLzmjqLI4J7VILzk/dxMjMNYaOTWkdjA+nct7iFGag0VJnDfi i2egkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZQ123mve/ez130wJM18rhg9s7OijVFa99n P9j08cg1l7vdb7YFqfBbt/T5XhTxbHHJ+brBupvpof7V9JW/eFj7mk7tPfTv6R8W50UJUz22 TZtQF3naNJ7jtAFj7KtrB7VyfA7v2PCzo4jty7m297sa85c7J1VUpf3cr965+vm5KbdP39p3 KFNKiaU4I9FQi7moOBEA0DfZ1oMCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyffUHPt1YZaZQg3OPNC3uvrnM4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujA9r9As+8lYcnDePvYFxIncXIyeHhICJxMS5+5kgbDGJC/fW s3UxcnEICZxglDjTd4EFwtnNKPGgcTFYFRtQx8Ird5lBbBEBKYlnsx4BFXFwCAvYSez/XAAR tpfYeriXFcLOkrixcytYOYuAqsTBS71sIDavQITEhJVPoeb3sUrcXPcSLMEpoC/RcbAPzGYE uuj7qTVge5kFxCVuPZkPdamAxJI955khbFGJl4//sULYihKbFm1mhKjXkViw+xMbhK0tsWzh a2aIxYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkap4oyk3MQCAxO94oyUZL3kjKLK4pzU Ir3k/NxNjMDoMJVZEL2DcdYN+UOM0hwsSuK8W/IOhQgJpCeWpGanphakFsUXleakFh9iZOLg lGpgFNEOarNzYpULjXfvmPWg4dCCvbOlDvb3WMRcNOJ+vfymbHrHz0/uvUEPe+8WX7hQt47r 92q9V5/S65cWLF4ZJGa2oNwiufqV7YXJG7K+MXqdVlvi8Xuis9Ra+5i95mk2vWKuXC1z3t7q mfnglnBeJEv6uvq+t1N6zv+KFUk62eG6baOb08MfSizFGYmGWsxFxYkAvCEB8VwCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/OQnsC0jSOdTKV7EkVXL7JH_LpfI>
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: Thu, 12 Mar 2015 23:38:09 -0000

So you're thinking it's more likely that we'll get folks to understand this new type, that's designed to frustrate QTYPE=* queries in a more-or-less graceful way, than it is to convince them to stop making QTYPE=* queries in the first place?

Don't get me wrong -- I would actually *applaud* the definition of a new RR type (and possibly, a new meta-type to go along with it) that was designed to facilitate a controlled ability to fetch all RRsets for a given name, in a single query. That would be forward progress, in my opinion. But to create a new RR type solely for the purpose of making an RFC 1034/1035-defined feature of DNS less useful than it would otherwise be? I see that as going backwards, verging on Luddite. What's next? A new RR type to "gracefully" frustrate senders of MX queries, because we consider SRV a more general mechanism for accomplishing the same thing? That's a hell of a way to evolve a protocol, creating new RR types specifically to render old QTYPEs or RR types useless...

																- Kevin 

-----Original Message-----
From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Florian Weimer
Sent: Thursday, March 12, 2015 12:30 PM
To: Tony Finch
Cc: Evan Hunt; dnsop; Wessels, Duane; Paul Vixie
Subject: Re: [DNSOP] CloudFlare policy on ANY records changing

* Tony Finch:

> I also tried a stupid hack to send an ANY RR in the response. BIND's 
> resolver treats this as a FORMERR and returns SERVFAIL to the client.

What about introducing a new non-meta RR type for this purpose?  It would not increase the response size by much.

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

v2.23.0 | Report a Bug | By Email