Re: [DNSOP] draft-ietf-dnsop-dns-rpz

Marek Vavruša <mvavrusa@cloudflare.com> Fri, 06 October 2017 18:13 UTC

Return-Path: <mvavrusa@cloudflare.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 C5AD8134BCE for <dnsop@ietfa.amsl.com>; Fri, 6 Oct 2017 11:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 0iarV4Kzabt0 for <dnsop@ietfa.amsl.com>; Fri, 6 Oct 2017 11:13:50 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 56874134BD0 for <dnsop@ietf.org>; Fri, 6 Oct 2017 11:13:48 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id o52so32968723qtc.9 for <dnsop@ietf.org>; Fri, 06 Oct 2017 11:13:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ViNlVODREeHQ5RzfrocGjbX2YGos4JkfU9t6J1TUpxk=; b=FrFT0bYsBBYTJmUHwi+xuhaeOKNa51XMGkYoF4NfGcovBhKcf2IHxPNnMcaGo9OEoj dllNM7F3kbViKYuZHSLUUZAxBEtDfeWsCvnTKGuhwDHQ13G1tCrh2Qocsrins5SJHxTS 2tfg36xeRnY5Q0o/GAmyI59M71OKSmBRA7TFw=
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=ViNlVODREeHQ5RzfrocGjbX2YGos4JkfU9t6J1TUpxk=; b=E/VCo2qHpLshtVDUruCAQFGXWKZG3R0DGn4KI7KgNvlgq97wMzvymnDFK5+GmRLxIb LWlKtOy9I5agrKgBjcceK9R+Z5uc9YSruccuEOrxOOfD3ZYkuTcNlGYjK0J+nehTQqnV E1W/tcdIID7DFn0xrJVeoePBL80lKNf+/9Eub69pSf5lCme5VqpQVskiVX5PpUTIsksi W1/AMIWLF6FuE1JXdSCACl8GV+9UjpYbsGArTz0TRfD7rAr5VXVbtxQyQDp0EVwcEXlr hJh8g3yGBhel8G6MnFMOGrSSsao2auT4fvugnTilMybE2bR33H84Bk+lQgVgcBTOC/OS 5/oA==
X-Gm-Message-State: AMCzsaVcF7uiZ2NK8tceSlBNOCOVhMEwG4Dm2uCozRhL4R8dy6k2/G8k zH9JDQDzN6Q7aT/X1+WwWijhKX7UeaZ376QYEbklOWau5JQ=
X-Google-Smtp-Source: AOwi7QBYITyAXF7VkDKOaplCbL05ZbbXGX2Wd9suN5xICD+h/x9ozuxcpCCz3d94AbVG43TdBuic4HzU6qGD+0tz9m0=
X-Received: by 10.129.5.14 with SMTP id 14mr2316823ywf.463.1507313627324; Fri, 06 Oct 2017 11:13:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.16.194 with HTTP; Fri, 6 Oct 2017 11:13:46 -0700 (PDT)
In-Reply-To: <201710061638.v96Gckki082320@calcite.rhyolite.com>
References: <fbd50d63-7669-ebc6-1b58-ddab42259418@nic.cz> <201710061638.v96Gckki082320@calcite.rhyolite.com>
From: =?UTF-8?Q?Marek_Vavru=C5=A1a?= <mvavrusa@cloudflare.com>
Date: Fri, 6 Oct 2017 11:13:46 -0700
Message-ID: <CAC=TB12WtCnLW7SfOYPRMW8YYT5r0OB=pb1hb82jbUWq7qCAwQ@mail.gmail.com>
To: Vernon Schryver <vjs@rhyolite.com>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dujFrNi1oP5JhdghYtsNcEsQGf0>
Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz
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: Fri, 06 Oct 2017 18:13:52 -0000

Hi Vernon,

There's a functionality [1] to do all these things (and more), you
just can't read/write complicated rules from RPC compatible format
(DNS zone files). Feel free to contribute of course.

Marek

[1]: http://knot-resolver.readthedocs.io/en/stable/modules.html#dns-application-firewall

On Fri, Oct 6, 2017 at 9:38 AM, Vernon Schryver <vjs@rhyolite.com> wrote:
>> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+ietf@nic.cz>
>
>> The current very limited implementation of RPZ in knot-resolver [1] is
>> done via a couple dozen lines of lua code, i.e. only JIT-compiled.  The
>> approach might remain similar, perhaps a bit more modularized, but in
>> any case I expect it would be included by default, so I wouldn't fear
>> about users having to recompile.
>>
>> [1]
>> https://gitlab.labs.nic.cz/knot/knot-resolver/blob/v1.4.0/modules/policy/policy.lua#L294
>
> I wish I wouldn't offend people when I point out that a mechanism
> that uses local zone files is not a very limited response policy
> zone implementation.  Such things might be far better than real
> "rpz", but they're not "rpz".  (I can make a case for them being
> better although I don't buy it, perhaps because I'm biased.)
>
> Overwriting public DNS data triggered by qnames has always been trivial,
> but that is not "rpz."  Simply fire up a local authority server with
> your own "DNS lies" and point your resolvers to it, perhaps with custom
> "hints" files.  If you're running combined authority/resolver code
> such as BIND, simply add some local zone files.  But such ad hoc
> authority server schemes as well as the new so called "rpz" schemes
> of adding local zone files to resolvers the lack features that motiviated
> the original implementation of real RPZ including:
>
>   - distributed policy zones, including from external organizations
>       This sounds minor, but it is major.  It's related to why so few
>       organizations maintain their own anti-spam DNS blacklists.
>       You could use FTP, rsync, HTTP, etc. and a cron job, but in
>       practice you won't.  And if you did, it updates would have
>       latencies of hours or days instead of seconds with real RPZ.
>
>   - dynamically combine policy from multiple sources
>       In theory this could be done with some perl, awk, or even
>       Bourne shell code, but not in practice at scale.
>
>   - policies triggered by the contents of A and AAAA responses or by
>          the names or IP addresses of authorities
>       The bad guys can and do register new domains faster than you can
>       update your local blacklist, faster than they can hijack new IP
>       addresses for those new domains, and faster than they'd like to
>       establish new authorities serving those new domains.
>
>   - no need to restart the resolver to reload the zone
>       This not only minimizes end user disruption when the zones
>       are reloaded but allows organization-wide policy changes with
>       latencies measured in seconds.
>
> In other words, hacking local zone file qname overrides into a
> resolver is not hard (including CNAME and DNAME chains).  The horrid
> code involves triggering on A or AAAA contents and authority names
> and addresses...well there're also SOA timers, IXFR, AXFR, Notify,
> and TSIG, but that code is less horrid than voluminous.
>
> Please don't misunderstand me as saying no one else can or should
> write real RPZ code.  Many people could and I really wish they
> would.  That's why I spent a lot effort outside my comfort zone on
> the I-D.  What bugs me are implementations of so called RPZ and RRL
> that share only the acronyms with the BIND stuff.
>
>
> Vernon Schryver    vjs@rhyolite.com
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>