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

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.

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/

On the open question of how this arises: it is DNS64 on the probe's own network, not anything the site's zone does.

A DNS64 resolver (RFC 6147) synthesises an AAAA record from the name's A record when the name has no AAAA of its own, embedding the IPv4 address in the network's NAT64 prefix per RFC 6052. That also explains the twitter case you mention: where a real AAAA exists, DNS64 returns it and synthesises nothing, so the same name can show a normal v6 address on one probe and a translated one on another.

Prevalence on 2026-08-18 from the public bucket, 16,656 web_connectivity measurements, one object per country-hour for IT, DE, RU and GB at 02, 08, 14 and 20 UTC:

584 measurements carry an answer in a NAT64 prefix
all 584 are in the RFC 6052 well-known prefix 64:ff9b::/96
none are in 64:ff9b:1::/48, which is the range bogon_ipv6_ranges actually lists
they come from IPv6-only mobile networks: AS31133 and AS31205 (MegaFon), AS2856 (BT), AS3320 (Deutsche Telekom), AS206067. A separate 37,674-measurement sample covering RU, IT, US and IN found 543 more, the Indian ones all on AS55836 (Jio).

So the scoring path in this issue is the rarer branch. The prefix in the bogon list is the one operators take for local use, and none of the sampled probes used it.

The common case looks harmless for the control comparison, because the probe asks for A and AAAA and keeps both answers. For example https://explorer.ooni.org/m/20260818080042.865750_RU_webconnectivity_ac216087d50433fd on AS31205: the answers are 64:ff9b::cebd:6516 and 206.189.101.22, the control returned 206.189.101.22, so dns_answer_matches_ctrl already matches on the v4 answer. I decoded the embedded v4 out of the synthesised address in 22 such measurements and it never turned a control mismatch into a match: either the plain A answer matched already, or the decoded address differed from the control as well, which is the case the analysis is there to catch (echo.msk.ru on AS31205: probe 91.200.42.123, control 178.32.75.83).

One inconsistency worth a glance while this is open: 64:ff9b:1::/48 is in this repository's list but not in probe-cli's internal/netxlite/bogon.go, so probe and pipeline can classify the same answer differently.

Reproduction, if useful:

import gzip, io, json, re, urllib.request
BASE = "https://ooni-data-eu-fra.s3.eu-central-1.amazonaws.com/"
xml = urllib.request.urlopen(BASE + "?list-type=2&prefix=raw/20260818/08/RU/webconnectivity/").read().decode()
for key in [k for k in re.findall(r"<Key>(.*?)</Key>", xml) if k.endswith(".jsonl.gz")]:
    raw = urllib.request.urlopen(BASE + key).read()
    for line in gzip.GzipFile(fileobj=io.BytesIO(raw)):
        if b"64:ff9b" in line:
            m = json.loads(line)
            print(m["probe_asn"], m["input"], m["test_keys"]["control"]["dns"]["addrs"])

Navigation Menu

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

Lanius-collaris commented on Jan 18, 2025

yarrrly commented on Aug 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions