Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
Mark Andrews <marka@isc.org> Wed, 20 July 2016 07:40 UTC
Return-Path: <marka@isc.org>
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 75F6512D10B for <dnsop@ietfa.amsl.com>; Wed, 20 Jul 2016 00:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.188
X-Spam-Level:
X-Spam-Status: No, score=-8.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-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 JUzyweCt2rIk for <dnsop@ietfa.amsl.com>; Wed, 20 Jul 2016 00:40:20 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 AD51512B02A for <dnsop@ietf.org>; Wed, 20 Jul 2016 00:40:19 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 555041FCB04; Wed, 20 Jul 2016 07:40:16 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2F832160046; Wed, 20 Jul 2016 07:40:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 114ED160084; Wed, 20 Jul 2016 07:40:15 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id H5ifyHe-9sX5; Wed, 20 Jul 2016 07:40:14 +0000 (UTC)
Received: from rock.dv.isc.org (dhcp-b190.meeting.ietf.org [31.133.177.144]) by zmx1.isc.org (Postfix) with ESMTPSA id B1F4E160046; Wed, 20 Jul 2016 07:40:14 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 12E3B4EF26EC; Wed, 20 Jul 2016 17:40:08 +1000 (EST)
To: Jim Reid <jim@rfc1035.com>
From: Mark Andrews <marka@isc.org>
References: <b00ec4.3833.15606420d47.Coremail.yzw_iplab@163.com> <236F5488-42D4-4A89-ACAB-B55FD2B5782A@fl1ger.de> <20160720051949.8FC154EF155E@rock.dv.isc.org> <36A593C1-1F01-4FE1-BC9A-3279F6460358@rfc1035.com>
In-reply-to: Your message of "Wed, 20 Jul 2016 08:18:44 +0100." <36A593C1-1F01-4FE1-BC9A-3279F6460358@rfc1035.com>
Date: Wed, 20 Jul 2016 17:40:08 +1000
Message-Id: <20160720074008.12E3B4EF26EC@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ymIZqe99Au6X9hLIzqUcjhgdjDs>
Cc: IETF dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 20 Jul 2016 07:40:21 -0000
In message <36A593C1-1F01-4FE1-BC9A-3279F6460358@rfc1035.com>, Jim Reid writes: > > > On 20 Jul 2016, at 06:19, Mark Andrews <marka@isc.org> wrote: > >=20 > >> That's not who DDos work. If attacker would only do what the specs = > say > >> we wouldn't have any DDos. But an attacker can just create an UDP = > packet > >> with that bits and a spoofed address and fire it off (or get a botnet = > to > >> fire it off). > >=20 > > Which is why DNS COOKIES with a valid server cookie / TCP / DNS-O-TLS > > was suggests as being a necessary precondition. > > The draft does not say that Mark. It was stated up thread. Additionally aren't these discussion supposed to get consensus of the changes needed rather than the "I-D is cast in stone" especially right at the start of the processes. If this was last call this sort of nit picking would be justified but at this stage of the development process it seems to be unnecessary. > Under Security Considerations, it says: "One could mitigate this by only > serving responses to EXTRA requests over TCP or when using Cookies > [RFC5395], although there is no easy way to signal this to a client other > than through the use of the truncate bit." > > It's a bit of a stretch to call that a suggestion and a far bigger one to > claim cookies and/or TCP as a necessary precondition. There's no language > like "clients and servers SHOULD (MUST?) use DNS cookies/TCP/DNSoverTLS > for EXTRA queries and responses". Well, not yet anyway. Maybe in the next > release. > > And if DNS over TLS is the answer, the overheads of that handshake would > more than cancel out the benefit of optimising away an extra > query/response RTT. > > FWIW, I think it's a Bad Idea and the start of a very slippery slope to > make queries or responses to QTYPEs dependent on the underlying transport > protocol (modulo AXFR of course). Are layering violations acceptable > nowadays? Nameservers make decisions TODAY about what they will put in a message based on COOKIES / TCP / UDP and a host of other considerations. Personally I don't think EXTRA is needed. A nameserver can predict a lot of the future queries based on the contents of the reply to the initial query. MX -> A / AAAA / TLSA of _25._tcp.<MX TARGET> SRV -> A / AAAA / if _tcp then TLSA of _<port>._tcp.<SRV TARGET> Yes, the responses get bigger but bigger isn't the real problem. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Ted Lemon
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Bob Harold
- Re: [DNSOP] Asking for TCP and/or cookies: a tren… Mukund Sivaraman
- Re: [DNSOP] Asking for TCP and/or cookies: a tren… Mukund Sivaraman
- Re: [DNSOP] Asking for TCP and/or cookies: a tren… Stephane Bortzmeyer
- Re: [DNSOP] Asking for TCP and/or cookies: a tren… Paul Wouters
- Re: [DNSOP] Asking for TCP and/or cookies: a tren… Mukund Sivaraman
- Re: [DNSOP] Asking for TCP and/or cookies: a tren… Paul Wouters
- [DNSOP] Asking for TCP and/or cookies: a trend? (… Stephane Bortzmeyer
- Re: [DNSOP] my lone hum against draft-wkumari-dns… 延志伟
- Re: [DNSOP] my lone hum against draft-wkumari-dns… 延志伟
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Ralf Weber
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Peter van Dijk
- Re: [DNSOP] my lone hum against draft-wkumari-dns… 延志伟
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Jim Reid
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Mark Andrews
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Jim Reid
- Re: [DNSOP] my lone hum against draft-wkumari-dns… 延志伟
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Mark Andrews
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Ralf Weber
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Ted Lemon
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Ralf Weber
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Matthew Pounsett
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Ted Lemon
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Matthew Pounsett
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Ralf Weber
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Christopher Morrow
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Ralf Weber
- Re: [DNSOP] my lone hum against draft-wkumari-dns… George Michaelson
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Robert Edmonds
- [DNSOP] my lone hum against draft-wkumari-dnsop-m… Paul Wouters
- Re: [DNSOP] my lone hum against draft-wkumari-dns… Ralf Weber