IETF Logo Mail Archive

Re: [DNSOP] Clarifying referrals (#35)

Matthew Pounsett <matt@conundrum.com> Mon, 13 November 2017 19:59 UTC

Return-Path: <matt@conundrum.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 05B31129601 for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 11:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com
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 V8_-qBHwOgT5 for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 11:59:37 -0800 (PST)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 2603F1241F3 for <dnsop@ietf.org>; Mon, 13 Nov 2017 11:59:36 -0800 (PST)
Received: by mail-it0-x233.google.com with SMTP id m191so7883385itg.1 for <dnsop@ietf.org>; Mon, 13 Nov 2017 11:59:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JYk4zZ1ditQtnNHDa56sUbCiHMCGi+erTpffd/YfjGM=; b=QQE4lEFzMzykbbDT6yeUKPjcPLXQrMXOolqDiIW+83dy8Ycb9biXDEJFJfS2JC240K r7LvthRbgSAPEiViFTnbcMkF8zOnYgDLOsN+2RtYl8LZ7UJLJw0FaSubAC1BPPfLj3i/ yQbb0qbeHTmcSNXOOEzimXFAsaM/oJ1OUPMLKWgen8KK8cQr5UHcnCvNW0qZjetlru6p OTpfEByotpM1GncQ9eQQGSOgcjcht+bUHC5BSIJz5ilj9Vc8qf7Nhv66N5N6BDz+8oZx rEa+oMY+wwdq0L+wUDPUFx92Pqr3s2aOOtQYinqgV6e4dpISoE14JdYPHu5BoHDHdtfb l33w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JYk4zZ1ditQtnNHDa56sUbCiHMCGi+erTpffd/YfjGM=; b=pKhYJ3yR6MEF0DNk5xUpV1jgUPfaZCdMnwVADvt2Sff5E6a389Nv2wOUzPYFrN1mVA uSDJZg/fySJBcwpmB0D3L/ztco6QpgWhk9jANGgja6HfJcolQEH4GFnAjDO0Dg+qAZjg /rG0ga0/9HrYqOS2RDJYAYXXKWMOeZ3lXOP7IFqX5j5OiRS33nOKM09q6aA05vKUi6O4 Z5QPad99d7BQ0RnplCh8xbEoND54NbPQxXJ2fls3FEfQGnC8g6rSBGyWpoewEPPfPZ17 5gXhxGIkKEA/j2d/w3/ftV+POvzqjsjQIngfl0pVUy68jtXFTQ7ip537FdZi+qAtDMuy xllg==
X-Gm-Message-State: AJaThX4Ju9kSVNPc5nzm5SGLkp0oevlqKi3aUXBsJyYtpaaNK2DTBcZv P/retHNspXQ0oVkng5K2S0vHk7DxMVg4Ah+gvlRMeyoyqxI=
X-Google-Smtp-Source: AGs4zMapQglBa10bg8y/+HY4nTj10D6iKm03EFFqcYh5oFHzcG1C4HapWY/gq3vRh/VeCjwAnxs1BvqxD6SAGnh7PjY=
X-Received: by 10.36.40.207 with SMTP id h198mr7199335ith.95.1510603176318; Mon, 13 Nov 2017 11:59:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.11.196 with HTTP; Mon, 13 Nov 2017 11:59:35 -0800 (PST)
In-Reply-To: <5A09F26B.40705@redbarn.org>
References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <c66000fbd9174916a1142650298c7632@XCASPRD01-DFT.dpu.depaul.edu> <20171113085235.2fddd72a@p50.localdomain> <CAAiTEH_ikmAryaAXbKxVBHODfJx4Vohb7XWUPnqGw9s41ZR_Bg@mail.gmail.com> <5A09EAA6.5010305@redbarn.org> <CAAiTEH_U6eSZhSHbztwKF0xvem2e6PENG34JftGGmizdsAJJpg@mail.gmail.com> <5A09F26B.40705@redbarn.org>
From: Matthew Pounsett <matt@conundrum.com>
Date: Mon, 13 Nov 2017 11:59:35 -0800
Message-ID: <CAAiTEH_w5v_6P2afpEKVXRWfB7zgTSCuAkg6f3RNt6NfjJNz8w@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: jtk@aharp.iorc.depaul.edu, "dnsop@ietf.org" <dnsop@ietf.org>, Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: multipart/alternative; boundary="001a113f651cb8aad6055de2b501"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/88w0bn5IeTu_B9ymOU9XeWgD3bc>
Subject: Re: [DNSOP] Clarifying referrals (#35)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 13 Nov 2017 19:59:39 -0000

On 13 November 2017 at 11:28, Paul Vixie <paul@redbarn.org> wrote:

>
> ... If that were a problem, given BIND's market share, we should be
>>
> seeing widespread brokenness, but I don't think we are–none that's
>> making it from my support department to me or to our hostmaster@
>> accounts, at any rate.
>>
>
> yikes! you remind me of the guy who said on nanog a few years back that
> since he wasn't seeing spoofed-source ddos attacks any more, we should all
> stop worrying about them.
>

your lived experience can be cause for concern, but never for complacency.


I don't think that word means what you think it means.  Lack of concern for
a non-problem is not complacency.

The rest of us still see spoofed-source DDoS attacks, and they're a
frequent topic of discussion in the networking and DNS communities, so even
someone who doesn't see them on their network should still be aware that
they happen.  I have seen no similar discussion of REFUSED-generated chaos
in recursive servers.   If someone is seeing such brokenness, they haven't
brought it to dnsop@, or dns-operations@, or an OARC or NANOG meeting.  If
someone is seeing such brokenness, hopefully they'll speak up so that we
can advise the authoritative implementations to change their behaviour
again.

I use the plural there deliberately.  I referenced BIND above because that
was the implementation I was most familiar with at the time the behaviour
changed ... but it does seem to be the consensus among the authoritative
implementors that REFUSED is the correct response.  It wouldn't be the
first time that a majority of implementations settled on a behaviour that
didn't strictly follow the specification because it was necessary for good
inter-operation.    Perhaps someone who was present for an implementer's
internal discussion about replacing upward referrals could comment on the
reasoning, and what (if any) collaboration occurred between the
authoritative and recursive implementations at the time.

v2.14.0 | Report a Bug | By Email