0

5.90.28.209 recurrently not responding from Spain – only zepto-mad reachable

Hi,

We are experiencing a recurring issue (not just today) where one of our linked-IP resolvers stops responding from our main internet connection in Spain:

  • 45.90.28.209 → no response (DNS queries time out, ping 100% loss)
  • 45.90.30.209 → works fine

From external services (e.g. ping.eu) 45.90.28.209 responds normally, so the problem seems to be the route/PoP reached from our ISP.

Because of this, our DNS servers frequently fall back to our secondary resolvers, and NextDNS filtering is not applied consistently.

ping.nextdns.io result:

zepto-mad                  8 ms  (ultralow2)
anycast.dns1.nextdns.io   error  (anycast1)
anycast.dns2.nextdns.io   error  (anycast2)
dns1.nextdns.io           error  (ultralow1)

 

 

Traceroute to 45.90.28.209 (stops after 37.19.193.233; first hops inside our ISP omitted):

 7  194.30.8.154      7.7 ms
 8  213.249.106.141   7.9 ms
 9  * * *
10  213.19.221.98    34.4 ms
11  37.19.193.233    34.5 ms
12  * * *
13  * * *

 

 

Update – diagnostic results

I managed to run the nextdns.io/diag tool. Public IP and the first hops (local network/ISP edge) have been hidden for privacy.

Summary:

  • Anycast primary (45.90.28.0) is unreachable from our ISP: the route dies after 37.19.193.233.
  • Anycast secondary (45.90.30.0) works, but routes us to vultr-fra (~36 ms), even though anexia-mad / zepto-mad are reachable at ~8 ms.
Testing IPv6 connectivity
  available: false
Fetching https://test.nextdns.io
  status: ok
  client: [hidden]
  protocol: UDP
  dest IP: 45.90.30.209
  server: vultr-fra-1
Fetching PoP name for ultra low latency primary IPv4 (ipv4.dns1.nextdns.io)
  anexia-mad: 7.951ms
Fetching PoP name for ultra low latency secondary IPv4 (ipv4.dns2.nextdns.io)
  zepto-mad: 12.78ms
Fetching PoP name for anycast primary IPv4 (45.90.28.0)
Fetch error: Get "https://dns.nextdns.io/info": dial tcp 45.90.28.0:443: connection timed out
Fetching PoP name for anycast secondary IPv4 (45.90.30.0)
  vultr-fra: 36.277ms
Pinging PoPs
  anexia-mad: 7.791ms
  zepto-mad: 8.097ms
  zepto-lis: 14.837ms
  anexia-lis: 22.11ms
  netbarista-par: 23.432ms
  zepto-mil: 28.985ms
  virtua-par: 34.065ms
  anexia-mil: 35.723ms
  anexia-zrh: 50.045ms
  anexia-par: 24.634ms

Traceroute for ultra low latency primary IPv4 (217.146.1.31)
  [hops 1-3 hidden]
    4    194.30.8.93    2ms   2ms   2ms
    5    194.30.8.58    7ms   7ms   *
    6    194.30.8.61   12ms   7ms   7ms
    7   193.149.1.17    7ms   7ms   7ms
    8 87.245.238.163    7ms   7ms   8ms
    9 213.227.186.32    8ms  16ms   8ms
   10   217.146.1.31    7ms   7ms   7ms

Traceroute for ultra low latency secondary IPv4 (194.156.155.239)
  [hops 1-3 hidden]
    4    194.30.8.93    2ms   3ms   2ms
    5   194.30.9.122    2ms   2ms   2ms
    6   194.30.8.166    3ms   3ms  29ms
    7    194.30.9.50    2ms   2ms   2ms
    8   194.30.8.154   22ms  16ms   8ms
    9 213.249.106.141   10ms   8ms   9ms
   10   171.75.8.105    9ms   9ms   9ms
   11 213.242.105.246    8ms   8ms   9ms
   12    84.17.33.97   15ms  24ms   8ms
   13 194.156.155.239    8ms   8ms   8ms

Traceroute for anycast primary IPv4 (45.90.28.0)
  [hops 1-3 hidden]
    4    194.30.8.93    2ms   2ms   2ms
    5   194.30.9.122    2ms   2ms   2ms
    6   194.30.8.166    2ms   2ms   4ms
    7    194.30.9.50    2ms   2ms   2ms
    8   194.30.8.154    7ms   7ms   7ms
    9 213.249.106.141    8ms   8ms   8ms
   10                   *     *     *
   11  213.19.221.98   35ms  34ms  34ms
   12  37.19.193.233   34ms  34ms  34ms
   13-20                *     *     *
  error: context deadline exceeded

Traceroute for anycast secondary IPv4 (45.90.30.0)
  [hops 1-3 hidden]
    4    194.30.8.93    2ms   2ms   2ms
    5                   *     *     *
    6    194.30.8.61    8ms   7ms  10ms
    7   193.149.1.36    8ms   7ms   7ms
    8  129.250.2.204    8ms   8ms   8ms
    9   129.250.2.60   23ms  23ms  23ms
   10   129.250.5.32   33ms  33ms  33ms
   11    129.250.2.9   34ms  34ms  34ms
   12  212.119.15.18   33ms  33ms  33ms
   13-15                *     *     *
   16     45.90.30.0   35ms  35ms  36ms

Could you please check why anycast primary (45.90.28.0) is unreachable from this route, and why anycast secondary sends us to Frankfurt instead of Madrid? Thanks.

4 replies

null
    • Iker_R
    • 6 days ago
    • Reported - view

    Update: 45.90.28.209 started responding again at 12:03 CEST (10:03 UTC) without any change on our side. It had been failing since at least 11:39 CEST (monitoring started then; the issue began earlier in the morning). Response time is now ~35 ms, so we still seem to be routed to a distant PoP instead of Madrid (~8 ms). We’ll keep monitoring and report if it fails again.

    • Iker_R
    • 6 days ago
    • Reported - view

    Update: 45.90.28.209 is responding again since 12:03 CEST. ICMP traceroute now reaches it through the exact same path as during the outage (213.19.221.98 → 37.19.193.233 → 45.90.28.209, ~34 ms), so the outage was on the PoP itself, not routing. This has happened to us repeatedly. Could you check the stability of this PoP? We’re also being routed to it (~34 ms) instead of the Madrid PoPs (~8 ms).

    • Mirli
    • 3 days ago
    • Reported - view

    45.90.30.xxx. Redirects to a closer server

      • Iker_R
      • 16 hrs ago
      • Reported - view

       
      Thanks for the reply. In our case 45.90.30.209 actually routes us to vultr-fra (~36 ms), not to a closer PoP, while anexia-mad / zepto-mad are reachable at ~8 ms (see the diag above). And the main issue is that 45.90.28.209 stopped responding for hours, with the outage at the PoP behind 37.19.193.233. We’re still hoping NextDNS can look into it.

Content aside

  • 16 hrs agoLast active
  • 4Replies
  • 58Views
  • 2 Following