DeLegacy IPv6 RPZ Project
DNS Ad-blocking, but for legacy IP

Get rid of CDN loads of legacy IP traffic on your network by overriding websites' use of legacy (IPv4-only) CDN endpoints. This allows your network to turn off legacy IP entirely, instead focusing on monostack aka. IPv6-only operation.

Website Inertia

Many websites use Content Delivery Networks (CDNs) to help paper over their slow backends through caching or for serving large static assets such as image or video files to save on bandwidth costs. Most widely used CDNs make customer resources reachable over IPv6 in principle, but website owners have to explicitly opt-in by configuring their domain to use the correct dual-stack capable (A + AAAA) CDN endpoints.

In many instances the website itself is IPv6 capable, but incorrectly configured legacy CDN endpoints break much of the site in monostack networks. Usually all that's missing for such sites to work flawlessly on monostack networks is switching to the correct IPv6 (AAAA) capable CDN endpoint.

As website owners are fallible, forgetful humans there is more of this going on than you'd hope. The DeLegacy RPZ project aims to allow networks of any size to fix these misconfigurations on their own and take control of legacy CDN traffic on their network.

DNS Rewriting With Response Policy Zones (RPZ)

The technical means we use to make legacy CDN endpoints bend to our will is a Response Policy Zone (RPZ) ruleset. This allows us to deliver an ever changing set of DNS rewrite rules to your local DNS resolver in almost real-time without us seeing any privacy sensitive query traffic.

RPZ was originally created to satiate the security industry's lust for domain blocking. We're using it for a different purpose. See also https://dnsrpz.info.

Security & Privacy

RPZ is a very powerful mechanism which can technically be used not just for good, however we do believe the near universal use of TLS provides reasonable protection from our ruleset doing anything seriously nefarious without being detected. The devil's in the details as usual. We're working on characterizing and documenting the attack surface. More security-minded brains always welcome: #Community.

If you don't care about realtime updates you can deploy the RPZ in a human-in-the-loop configuration to mitigate against us being secretly evil :-).

Status: Experimental

The nature of this project is that it subverts website operator's expectations as to how their CDN behaves. Consequently it is possible some websites break when our RPZ is in use.

When this is the case we can exclude specific sites from the more general rules. Please report any issues you observe.

Some websites might refuse to work as expected out of compliance, abuse prevention or arbitrary other considerations. Others might have a technical failure caused by the unexpected client IP format.

However, the vast majority of websites don't depend on such mechanisms and are completely functional with our ruleset in use.

Using for advanced users

In short: Install a supported DNS recursor, drop the RPZ config below into place. Restart. Enjoy.

Slightly longer: There are two setup types for the zone.

1. As secondary, retrieving it with (AXFR) zone transfers. Keeps it automatically updated. Recommended for people just using this RPZ.
2. As primary, by manually deploying the zonefile. Manual updates required. Only recommended for people with advanced needs, e.g. requiring own modifications, or people that want to keep more control over the rule content.

Currently the config snippets below are only tested on Debian and NixOS.

1. Secondary, with Zone Transfer

BIND

$ apt install bind9

Write to /etc/bind/named.conf.local:

options {
    response-policy {
        zone "rpz.delegacy.monostack.org";
    };
};
zone "rpz.delegacy.monostack.org" {
    type secondary;
    primaries {
        // IPs of primary.delegacy.monostack.org
        2a01:4f8:251:305f::1;
        168.119.78.96;
    };
    // Optional: provide a path to cache the zone and avoid re-downloading it on every BIND restart.
    file "rpz.delegacy.monostack.org.zone";
};

unbound

Beware that unbound might have issues recursively following CNAMEs. See #17 for more info.

$ apt install unbound

Write to /etc/unbound/unbound.conf.d/delegacy-rpz.conf:

rpz:
  name: rpz.delegacy.monostack.org
  primary: primary.delegacy.monostack.org
  # rpz-log: yes #< optionally enable logging of matched rules

2. Primary, with Zonefile

Alternatively, the zonefile can be manually downloaded, potentially modified, and added as primary DNS zone. The latest zonefile is always available as a release here.

The config snippet to setup your DNS resolver is a bit different.

BIND

options {
    response-policy {
        zone "rpz.delegacy.monostack.org";
    };
};
zone "rpz.delegacy.monostack.org" {
    type primary;
    file "rpz.delegacy.monostack.org.zone"; // TODO: This path has to be adapted.
};

unbound

server:
    module-config: "respip validator iterator" # Enable the rpz (= respip) component if not already added.
rpz:
    name: "rpz.delegacy.monostack.org"
    zonefile: "rpz.delegacy.monostack.org.zone"

Community

We are part of the IPv6 Monostack Movement (patience young padawan. the website's not public yet). RPZ focused work happens in our Matrix room #ipv6-rpz:matrix.org.

Contributing

The obvious way to contribute is to propose well motivated and verifiable ruleset changes as pull requests :-).

Keep in mind that we need domains to test the proposed changes against so be sure to list at least one.

TODO: Review automation

We're also excited about developing automation for review to allow the RPZ scale to global use. The simplest review check we could think of so far: Do TLS connections still verify against all test domains?

However. CDNs are complicated. They return different results depending on the internet topological location of the DNS requestor or even send you to different servers using the same IP (anycast).

We want to build a diverse network of health check nodes to make these complexities immediately visible to ruleset contributors. We can ask our users to opt into helping here.

What we have already is a pile RIPE Atlas credits. RIPE Atlas is an existing globally distributed network measurement system. It's limited in what it allows both in volume due to the credit system and supported measurement types, so it's not ideal for our automated review ambitions but we can use it for CDN behavioural research.

Talk to us if you have the itch to look under CDN operator's hoods and poke around with a globally distributed stick :D.

TODO: Distribution DNS recursor integration

Think: apt install unbound-delegacy-rpz

An OpenWrt package with LuCI integration would also be quite helpful. See luci-app-unbound and adblock packages. User experience: https://beckmeyer.us/posts/openwrt_plus_unbound/.

TODO: Integrity, Traceability, Auditability & Security

Wide open field of research. Help us attain clarity!

• How do we mitigate against the RPZ primary operator secretly being an evil genius and targeting individual users by returning different AXFR results depending on source IP?

  • Do we need to worry? Is TLS sufficiently widely deployed for this to be moot? Privacy would still be a factor.

• How do we ensure the ruleset makes it intact to users' recursors?

  Options: 1) XFR-over-TLS and 2) plain XFR with DNSSEC validation at secondary (see root-of-trust section below).

  Note: Confidentiality is not necessary. Ruleset is public and a network adversary can see traffic metadata giving away user's association with delegacy already.

  XFR-over-TLS is suppored by unbound (see primary: option # syntax) and BIND.

• Where is the root of trust?

  Currently mostly concentrated in a single entity: the primary operator. Also: members holding TSIG keys for DDNS updates.

  Can we move RoT to be shared responsibility of the developer/FLOSS community?

  Perhaps using a multiple signers scheme?

• Validate DNSSEC signatures before using the ruleset?

  Knot supports acting as a validating XFR proxy https://www.knot-dns.cz/docs/3.2/html/reference.html#dnssec-validation. BIND and unbound don't seem to have any equivalent. We could also develop DNS recursor patches.

  Primary operator wrongdoing could be proved to developer community that way. However: the ephemeral nature of the zone on user systems still presents a challenge to detection and auditability.

  Could provide user tooling to collect observed zone contents (or ZONEMD hash).

TODO: Better and moar user documentation

Look at this poor excuse for documentation and make it something better!

License

The RPZ zone ruleset is licensed under

SPDX-License-Identifier: ODbL-1.0

The same license as OpenStreetMaps.

We used the in-line DNS proxy IPv6-dns-server as a starting point for our ruleset. Thanks for the great idea Miyuru <3

Zone maintenance tooling and automation is currently under the permissive "FSF All-Purpose" license.

SPDX-License-Identifier: FSFAP