---

Why did the email go to me? It should have gone to...

Finding correct contacts for ~25K ASes is hard. Having a small team, we needed to use an automated method. We had little success using the RIR whois databases, so we turned to third-party systems (e.g., WhoisXML API). These turned up many contacts, though some are outdated, some are outright incorrect, etc. Because we were receiving so many bounces, we sent our notices not only to abuse and technical contacts, but also to other (e.g., administrative) contacts--to make sure the notice was received by somebody, even if they had to pass it along to the right person.

We recognize that the notification process was imperfect, but in the end, this was a best-effort service, with good intentions.

---

How do I fix the problem?

How you deploy Destination-Side Source Address Validation (DSAV) depends on your network architecture. BCP 84 has a good introduction and some starting places for different architectures. See especially section 2. The important thing is a configuration that disallows packets having a source address originating from your network from entering your network.

---

How do I test our fix?

While we do not yet have a fully-featured self-tester in place, we have created a simple self-test that is linked from the report page in original email you received. At the moment, that is the only place it can be accessed.

---

How do your tests work?

Our testing infrastructure relies on DNS resolvers within the target network. By sending these DNS resolvers spoofed queries for domains under our control, we are able to infer a lack of DSAV if we observe a query from these resolvers at our authoritative server. The following diagram summarizes the testing methodology.

A detailed description of our methodology and results will be published in the proceedings of IMC 2020; a link to the paper will be made available after its publication.

---