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

Marek Vavruša <> Fri, 06 October 2017 18:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5AD8134BCE for <>; Fri, 6 Oct 2017 11:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0iarV4Kzabt0 for <>; Fri, 6 Oct 2017 11:13:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56874134BD0 for <>; Fri, 6 Oct 2017 11:13:48 -0700 (PDT)
Received: by with SMTP id o52so32968723qtc.9 for <>; Fri, 06 Oct 2017 11:13:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id 14mr2316823ywf.463.1507313627324; Fri, 06 Oct 2017 11:13:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 6 Oct 2017 11:13:46 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: =?UTF-8?Q?Marek_Vavru=C5=A1a?= <>
Date: Fri, 6 Oct 2017 11:13:46 -0700
Message-ID: <>
To: Vernon Schryver <>
Cc: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.



On Fri, Oct 6, 2017 at 9:38 AM, Vernon Schryver <> wrote:
>> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <>
>> 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]
> 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
> _______________________________________________
> DNSOP mailing list