Research:Beacon
The design of the beacon which will be used to verify operation and reach of the program is currently underway on the mailing list, and will be described here when it reaches stable consensus. It is intended to allow independent verification of IPv4 and IPv6 routing and domain name resolution, and to be robust against orthogonal DNSSEC validation errors.
Generally, our goal is to use two of each type of beacon, on independent and unrelated infrastructure, with one changing on a regular period, perhaps hourly.
Web Page
The beacon should be visible to the public in the form of a web page which attempts to load a variety of web objects, testing for sanction enforcement and a variety of forms of over-compliance. The web page should also display to the client the client's apparent IP address, source port number, and a timestamp that can be used by the client to validate what if anything might be between it and the beacon web server.
The web page should test:
- Whether a sanctioned domain loads (green background indicates correct blocking, red overlay indicates failure to block)
- Whether a subdomain loads (green background indicates correct blocking, red overlay indicates failure to block)
- Whether a different domain hosted at the same IP address loads (red background indicates over-blocking, green overlay indicates correct non-blocking)
- Whether a previously-but-no-longer-blocked domain loads (red background indicates over-blocking, green overlay indicates correct non-blocking)
- Whether a blocked IP address loads (green background indicates correct blocking, red overlay indicates failure to block)
- Whether a different IP address in the same subnet loads (red background indicates over-blocking, green overlay indicates correct non-blocking)
- Whether a previously-but-no-longer-blocked IP address loads (red background indicates over-blocking, green overlay indicates correct non-blocking)
- Whether a blocked Autonomous System Number loads (green background indicates correct blocking, red overlay indicates failure to block)
Potentially, we could test over-blocking of ASNs by multi-homing a beacon on a blocked and an un-blocked ASN, and testing to make sure the multi-homed object was not blocked.
Domain Beacon
As of March 27, 2022, we have two domain name beacons. They are:
sanctions-beacon.net
sanctions-beacon.com
Each will be set up to host the necessary responders, on two different independent network connections, using IP addresses not in any of our beacon IP address blocks. We will presumably need to get TLS certs for them as well. Because these should be blocked by name and not by number, we will also host positive beacons on the same servers (which should be visible, although resources identified by the beacon domains should not be visible). Depending upon the decision of the policy group on the matter of more specific domain names, we may also want to host separate beacons on more-specific subdomains, c.f. http://more-specific.sanctions-beacon.net. We may also need two other ("negative") domains, to host on the same IP addresses as these, which should not be blocked, to make sure that it's the domain, not the IP, that's being blocked.
IPv4 Beacon
As of April 11, 2022, we've received the two independent IPv4 /24 beacon subnets for which we performed an 8.4 inward transfer. They are:
IPv6 Beacon
As of April 7, 2022, we've received the two independent IPv6 /48 beacon subnets that we applied for. They are:
ASN Beacon
As of April 5, 2022, we've received both the 16-bit and 32-bit beacon ASNs we requested. They are:
