Improve treatment of bogons in analysis (not all bogons are made equal)

[hellais]

In doing some work on the new analysis pipeline I came across an interesting case which we should probably think about how to handle properly.

The case is this one: https://explorer.ooni.org/m/20241203074026.659796_IT_webconnectivity_714c5108998baea8.

Currently the analysis logic scores measurements where the DNS answer was a bogon and there was no successful TLS as a strong signal for blocking. However this case highlights how we should not be treating all bogons equally.

This particular IPv6 bogon (64:ff9b:1:fffe::68f4:2a01), is in the prefix that's allocated as per RFC 6052 (https://datatracker.ietf.org/doc/html/rfc6052) for use in IPv6 to IPv4 mappings.

Basically inside of this bogon address the last 32 bits are used to encode the target IP address such that if there is an IPv6 translator on the network it's able to route traffic towards the target IPs.
In this example the last 32 bits are 68f4:2a01 which using this one-liner:

python -c 'x="68f4:2a01".split(":");print(f"{int(x[0], 16) >> 8}.{int(x[0], 16) & 0xFF}.{int(x[1], 16) >> 8}.{int(x[1], 16) & 0xFF}")'

map to:
104.244.42.1
That checks out with what we see in the measurement.

I don't understand so well how and in which circumstances this would be happening.

That is is it the operator of the site (which doesn't natively support V6) that configures their DNS zone to return these addresses such that IPv6 only networks that have a v6-to-v4 translator service deployed are able to route traffic to their v4 address?

I did a quick search in measurements from the last month to see how prevalent this is and found it appears in DNS resolutions for 565 unique domains and for those which are very tested, this appears on 15+ distinct resolvers, so I am excluding this is a behavior of the resolver.

Moreover in the case of twitter, we observe that there are instances in which we get an answer that contains a V6 address that isn't in this special prefix, which makes we wonder why this is happening.

[Lanius-collaris]

IANA IPv6 Special-Purpose Address Registry :
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

---

RFC 8215: Local-Use IPv4/IPv6 Translation Prefix
https://www.rfc-editor.org/rfc/rfc8215.html

Abstract

This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use
within domains that enable IPv4/IPv6 translation mechanisms.

---

That is is it the operator of the site (which doesn't natively support V6) that configures their DNS zone to return these addresses such that IPv6 only networks that have a v6-to-v4 translator service deployed are able to route traffic to their v4 address?

I think it's unlikely. How can the operator of the site know if a user is from an IPv6-only network and the NAT64 prefix? Users may use public DNS resolvers that never send EDNS Client Subnet ( e.g. 9.9.9.10 ), and the sent subnets may not match users' ( e.g. 94.140.14.140
https://adguard-dns.io/en/blog/privacy-friendly-edns-client-subnet.html ).

I did a quick search in measurements from the last month to see how prevalent this is and found it appears in DNS resolutions for 565 unique domains and for those which are very tested, this appears on 15+ distinct resolvers, so I am excluding this is a behavior of the resolver.

Moreover in the case of twitter, we observe that there are instances in which we get an answer that contains a V6 address that isn't in this special prefix, which makes we wonder why this is happening.

At least dnscrypt-proxy and Unbound support customizable DNS64 prefix.
https://github.com/DNSCrypt/dnscrypt-proxy/blob/062dc53971c198b47eb5beab172edad1f3013def/dnscrypt-proxy/example-dnscrypt-proxy.toml#L888
https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#dns64-module-options

DNS servers related to public NAT64 gateways do not use well-known 64:ff9b/96 prefix, for example:

2001:67c:2960::64

https://level66.services/services/nat64/