Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp

神明達哉 <jinmei@wide.ad.jp> Thu, 07 February 2019 19:39 UTC

Return-Path: <jinmei.tatuya@gmail.com>
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 0E5401200D8 for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 11:39:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level:
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no 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 0wmgBFcypFhM for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 11:39:44 -0800 (PST)
Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0F512D4EB for <dnsop@ietf.org>; Thu, 7 Feb 2019 11:39:44 -0800 (PST)
Received: by mail-wm1-f50.google.com with SMTP id r17so1099256wmh.5 for <dnsop@ietf.org>; Thu, 07 Feb 2019 11:39:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Zqd0eXJmrCwWovtLwqhpUkf9nqlYlsJrtTuSF3JXUYQ=; b=SkpniwMo/MRISzuqzg3l4Z+OK6ZklBMspDqj12RSP9x6ItNf06X+izck/ERW589wOr ZZkNY2G/7RncksTXNx7OpYz1E6yOa7yl7mF1Cf5n/6KiF8icWcq0vc4/koD8wdyR36Ci mbZqsA5mgeXlh/CibJVYwJKu2VUUAzaS0cqFaiGpVDwkxhgwdbmTgn7vLzgpT9CKoVNj W+iqQRSrCq4SRCThmBQPfQZHFrOdtC5jgKDT1xG+uTILvrPeawOLEU8T4tE+v03z3L/C bmo8hTIwygKwv5K5OYvKw4AaVv6GsoDVIdj081mZMerhaRHQLEKCC6QWYjqqsUcDlE4R 94XQ==
X-Gm-Message-State: AHQUAuYJjqQOKbrAVw+P4Tddcivyye0VlJQnBsZG5U3VlinuX9cQuVOo Z+qcui1YqqsteYIr6Mc54wzHi+YM0ZUmPsss4R2gAATW
X-Google-Smtp-Source: AHgI3IYGC+8/iKKq8FvYj9hDEYF6a+j6NKGry0aOZnmZBBjvhFd7JNvRL2WInszY+hx56AhvKwRTa7Tl0Fuv9B0/Z9U=
X-Received: by 2002:a1c:ce0e:: with SMTP id e14mr9159772wmg.53.1549568382238; Thu, 07 Feb 2019 11:39:42 -0800 (PST)
MIME-Version: 1.0
References: <BCACF554-8BE6-49BC-B75A-BCED776F5189@NLnetLabs.nl> <4A75C4E3-F74F-46DB-9A8A-879C0BB79190@powerdns.com> <20190207190927.GA30071@jurassic.lan.banu.com>
In-Reply-To: <20190207190927.GA30071@jurassic.lan.banu.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Thu, 7 Feb 2019 11:39:30 -0800
Message-ID: <CAJE_bqc=D4exSxtyA=MPkSENjQSabV1LTh5X1s618bv3c_tYgg@mail.gmail.com>
To: Mukund Sivaraman <muks@mukund.org>
Cc: Peter van Dijk <peter.van.dijk@powerdns.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fa8504058153003e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eKs7rGZOq64B_Cl2aWvzoghiu2o>
Subject: Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 07 Feb 2019 19:39:46 -0000

At Fri, 8 Feb 2019 00:39:27 +0530,
Mukund Sivaraman <muks@mukund.org> wrote:

> > The draft doubles the number of packets involved in a legitimate
> > exchange; it more than doubles the number of packets involved in a
> > spoofed exchange. About half of these packets are ICMP
> > packets. Without the draft, ICMP packets are useful debugging aids,
> > and in big numbers, indications of attacks or operational
> > problems. With the draft, ICMP becomes another useless source of
> > background noise.
>
> I had implemented the draft about a year ago as a server-side patch for
> BIND so that it could be tried/tested. But I was not aware of the ICMP
> issue that you mentioned. Today I looked at a packet capture with ATR
> response and sure enough, the 2nd truncated response generates an ICMP
> message from the recipient. I agree that this would be noisy.

Probably off topic in the context of the adoption call, but I'd note
that it depends on some implementation details of the resolver.  ICMP
port unreachable errors will be likely to be increased if the resolver
closes the UDP socket for a query with an authoritative server
immediately after it receives a return packet.  BIND behaves that way
by default, so did PowerDNS recursor when I checked the implementation
many years ago (it probably still does).  But not all resolver
implementations adopt this practice; if I understand it correctly
Unbound uses a pool of (many) UDP sockets and reuse the same socket
for multiple queries.  I've not tested it myself but I believe you
won't see an increase of ICMP errors with such resolver
implementations.

--
JINMEI, Tatuya