Intermittent NXDOMAIN from some UK ISP resolvers

[Munega]

What is the name of the domain?

buyer.italiansecret.app

What is the error number?

N/A — DNS resolution failure

What is the error message?

DNS_PROBE_FINISHED_NXDOMAIN / ERR_NAME_NOT_RESOLVED

What is the issue you’re encountering

We are seeing intermittent NXDOMAIN responses for buyer.italiansecret.app, affecting multiple users on different UK ISP networks. The failure disappears before it can be inspected.

What steps have you taken to resolve the issue?

When tested after an incident:

• Both assigned Cloudflare authoritative nameservers return the expected record.
• Cloudflare 1.1.1.1 and Google 8.8.8.8 return NOERROR.
• The application responds normally.
• DNSSEC is disabled.
• No authoritative NXDOMAIN events appear in the DNS Analytics data available to us.
• A second hostname pointing to the same backend continues to work and is being used as a comparison.

Could this indicate stale negative caching at ISP resolvers, intermittent authoritative divergence, or a delegation issue? What additional evidence should we collect during the next occurrence, and is per-query authoritative DNS logging available?

What feature, service or problem is this related to?

DNS not responding/updating

What are the steps to reproduce the issue?

The issue is intermittent and has only been reproduced by affected users on some UK ISP networks. They open https://buyer.italiansecret.app and Chrome reports DNS_PROBE_FINISHED_NXDOMAIN or ERR_NAME_NOT_RESOLVED. Retesting later usually succeeds without any configuration change.

This resolver information was captured while the failure was actively occurring, on mobile data and before enabling WARP.

The affected device could not resolve buyer.italiansecret.app. During the failure, dnscheck.tools reported these IPv4 resolvers:

46.68.66.77, 46.68.66.78, 46.68.66.79, 46.68.66.81, 46.68.66.82, 46.68.66.112

It also reported IPv6 resolvers in:

2a00:23ee:0:1::/64 and 2a00:23ee:0:102::/64

RIPE registration identifies the IPv4 range as ORANGE-GPRS-NET/EE infrastructure and the IPv6 range as British Telecom EE Mobile infrastructure.

Immediately after enabling Cloudflare 1.1.1.1/WARP on the same device and mobile connection, the hostname resolved and the portal worked.

Therefore these are not resolver details collected after recovery: they were captured on the failing DNS path. We still cannot identify which individual resolver returned or retained NXDOMAIN, but the evidence currently points to the EE/BT recursive resolver path or its negative cache rather than the application or load balancer.

[XRaySpeX]

Which router are you using to get those responses?

[Munega]

these are my customers. many of them are experiencing the same issue. if they use warp tool they have no issue. I tested this over mobile with one of them. we found out that the resolvers he was using were the ones I added in this ticket. 

[Munega]

During the failure, dnscheck.tools reported these IPv4 resolvers:

46.68.66.77, 46.68.66.78, 46.68.66.79, 46.68.66.81, 46.68.66.82, 46.68.66.112

It also reported IPv6 resolvers in:

2a00:23ee:0:1::/64 and 2a00:23ee:0:102::/64

RIPE registration identifies the IPv4 range as ORANGE-GPRS-NET/EE infrastructure and the IPv6 range as British Telecom EE Mobile infrastructure.

Immediately after enabling Cloudflare 1.1.1.1/WARP on the same device and mobile connection, the hostname resolved and the portal worked.

[XRaySpeX]

Are they all using mobile BB routers or are some on fixed Home BB?

[Munega]

not sure,  what can be done? it seems something very strange.
2 identical records in the dns.

one with portal.italiansecret.app works

the other buyer.italiansecret.app works for some people only.