Using a WAF to allow or block incoming requests based on domain

A few weeks ago, we received an email asking how to configure an allow list using domains (not IPs) for incoming requests. The project that sent us the email planned to integrate Adyen—a popular payment service in Europe—based on the recommendations from this page: https://docs.adyen.com/development-resources/webhooks/domain-and-ip-addresses/.

Adyen uses DNS A records to provide developers with a list of IPs to allow in their WAF. Frankly, this is one of the worst and most unreliable methods to distribute such a list, and I would think twice about using a payment provider that relies on such questionable practices. Let’s check why this approach is problematic.

Imagine you set up a webhook on a third-party service (e.g., GitHub, Stripe, etc.) that should trigger a request to your API endpoint whenever a specific action occurs—like a code push to a repository or a new payment from a buyer. By default, this API endpoint is public—anyone can make requests to it. To secure it, you typically restrict access using an allow list of IP addresses, blocking requests from any other sources. (There are more robust options, but in this post, we're focusing on IP-based allow lists for WAFs.)

To build this allow list, you need to know the IPs that the third-party service uses to send requests—or be able to retrieve them dynamically. The most straightforward and reliable method is for the third-party service to expose an API endpoint (e.g., domain.com/allowed_ips) that returns the current list of allowed IPs. Your firewall, a scheduled job, or even an edge function can then periodically fetch this list and update the rules. This is simple, reliable, and efficient.

Unfortunately, some services (like Adyen) still use DNS resolution for this purpose—asking developers to resolve a domain to determine allowed IPs. Why is this unreliable? Because DNS responses are cached at multiple levels, from your local resolver to your cloud provider’s DNS service. Even after Adyen updates its A records, your system may continue to resolve the old IPs for hours (or longer, depending on TTL settings). This means your firewall could block legitimate traffic from Adyen’s new IPs, causing you to lose users or revenue.

One final note: allow lists based on IPs do not protect your service from many types of attacks—especially if the IPs are publicly known. Attackers can spoof packets to make them appear as if they originate from a trusted third-party service. The most reliable protection for webhooks is validating requests using signatures, tokens, or other secrets that can verify the authenticity of the sender.