r/dns

Wondering if this is happening for others? Cache-stats showing 0 hits 0 miss. Cache-keys showing nothing either.

config:

cache-max-age 0s
max-ttl 5s
cache-size 10MB

We’ve been facing an unusual issue with our website for the last couple of months.

The website works perfectly on some internet connections, but on certain ISPs it sometimes becomes inaccessible. After some time, it starts working again without us making any changes.

What’s confusing is that this happens intermittently — the same ISP may work at one point and then fail later.

We’re using Cloudflare for DNS, and the server is online and accessible from other networks when the issue occurs.

It seems like the problem may be related to ISP DNS resolvers, DNS caching, or ISP-level routing, rather than the server itself.

Has anyone experienced similar issues with Indian ISPs?

What would be the best way to identify whether the problem is actually with the ISP's DNS resolver/routing?

Any suggestions for troubleshooting or proving that the issue is ISP-side would be appreciated.

I've extended my DNS platform API to include the Model Context Protocol (MCP).

This makes my DNS query and analysis tools directly accessible to the AI and saves me a few tokens whenever I have the AI analyze and evaluate my DNS again.

The endpoint is public but rate-limited, and the backend has a global quota—if this quota is exhausted, your requests will be queued and responses may take longer.

It’s been a big help to me, and I’m curious to hear what you think.

I have device-wide DNS settings on both my CachyOS linux enviornment and my Pixel 10a phone.

In my browser settings (Google Chrome) there is an option to toggle "use secure DNS". Do I need to enable this setting, if it's already enabled device-wide?

Now I switched from Bind9 to PowerDNS, the reason: I used to store my DNS-Data in OpenLDAP. Everything is running on Debian. Now on Debian 13 there is the Bind9 module misssing to store date in OpenLDAP. So I switch to PowerDNS but now I store my data in a MariaDB Galera cluster. Then I added HAproxy to build a HA-environment. The setup is much easier then Bind9 with OpenLDAP AND I also store my Kea-DHCP leases and reserversions in the cluster.

This document provides guidelines and documents best current practice for operating authoritative DNS servers, recursive resolvers, and stub resolvers in a mixed IPv4/IPv6 environment. This document recommends that both authoritative DNS servers and recursive resolvers support IPv4 and IPv6. It also provides guidance on how recursive DNS resolvers should select upstream DNS servers, including when IPv4-embedded IPv6 addresses are available. This document obsoletes RFC 3901. This document is a product of the Domain Name System Operations Working Group of the IETF.

https://datatracker.ietf.org/doc/rfc10001/

Once upon a time MX records didn't even exist. And it was assumed the A record for a hostname was where you could find the mail server for that hostname.

When we got around to adding things like SPF, DKIM and DMARC, why didn't they make new bona fide record types instead of shoehorning them into TXT records?

I'd like to know if using DNS to block adult websites would cause privacy issues, slow down my internet connection for gaming, or put me at risk of being banned from games. Specifically, I read that AdsGuard is recommended, but as you can see, I don't know much about this topic.

Hi everyone,

I’m looking for help understanding a strange and potentially serious domain delegation issue.

I discovered the problem while developing and deploying my website. The website suddenly became inaccessible and redirected visitors to an unrelated advertising/parking page.

I purchased this .com domain through Dynadot using a promotional offer from 899COM discount. I have always managed the domain through my Dynadot account.

The domain is supposed to use the two authoritative nameservers assigned by Cloudflare.

I first checked Cloudflare. The zone was active, the DNS records appeared correct, and direct queries to the assigned Cloudflare nameservers returned the expected results.

I then checked my Dynadot account. It still displayed the same two Cloudflare nameservers. I did not see any unknown nameservers or unauthorized configuration changes in the control panel.

However, when I queried Verisign’s authoritative .COM registry servers directly, they returned three completely different nameservers operated by Registrar.eu.

I tested more than one Verisign .COM authoritative server and received the same result, so this does not appear to be a normal recursive DNS caching problem.

I also compared the registration data from two separate RDAP sources:

- The Verisign registry RDAP record lists three Registrar.eu nameservers.

- The Registrar.eu RDAP record lists my intended Cloudflare nameservers.

- My Dynadot control panel also lists the intended Cloudflare nameservers.

In other words, the registrar-side data and the registry-side data contradict each other.

The Verisign RDAP record also contains this event:

"eventAction": "last changed"

"eventDate": "2026-08-12T10:08:33Z"

I did not make any domain-related change at that time. I was having dinner and was not using Dynadot. I also found no corresponding nameserver change in my Dynadot account.

As a troubleshooting step, I removed the Cloudflare nameservers from Dynadot and added them again. Dynadot accepted the change and continued to display the correct Cloudflare nameservers.

However, Verisign’s authoritative .COM servers did not update. They continued publishing the three Registrar.eu nameservers.

Normally, I would expect a successful registry-level nameserver update to appear relatively quickly on the authoritative .COM servers, even if recursive DNS caches require additional time to expire.

I checked the security information available in my Dynadot account and found no unknown login or visible unauthorized configuration change. Therefore, I currently have no evidence that my Dynadot account was compromised. However, I understand that only the provider’s internal account, API, provisioning and EPP logs can conclusively determine this.

The Verisign registry identifies Hosting Concepts B.V. d/b/a Registrar.eu, also associated with Openprovider, as the sponsoring registrar.

My current understanding is that Dynadot may be acting as the customer-facing retailer or reseller for this registration, while Registrar.eu/Openprovider is the registrar of record communicating with Verisign through EPP.

The situation appears to be:

1. Dynadot’s control panel contains the correct Cloudflare nameservers.

2. Registrar.eu’s RDAP database contains the correct Cloudflare nameservers.

3. Verisign’s .COM registry publishes different Registrar.eu nameservers.

4. Re-saving the nameservers through Dynadot does not update Verisign.

5. Verisign shows an unexplained “last changed” event that I did not initiate.

6. Because of the incorrect registry delegation, the domain was directed to an unrelated parking or advertising service.

My questions are:

- Does this look like a registrar-to-registry EPP provisioning or synchronization failure?

- What could update the Verisign domain object without changing the nameservers shown by Dynadot or Registrar.eu RDAP?

- Could an automated provisioning or synchronization process have overwritten the registry delegation?

- What logs should I request from Dynadot and Openprovider?

- Should they be able to provide the relevant EPP domain:update request, before-and-after values, clTRID and Verisign svTRID?

- Is there an appropriate escalation path through ICANN if the providers cannot explain or correct the registry delegation?

- Has anyone experienced a similar mismatch involving Registrar.eu/Openprovider?

I have asked Dynadot to escalate the case to its upstream registrar, EPP engineering and security teams, and to preserve the relevant audit and EPP transaction logs.

Any advice from people familiar with Verisign EPP, registrar provisioning or reseller registrar arrangements would be greatly appreciated.

I would greatly appreciate Reddit users test and feedback the new Linux PIA daemon running 24/7 every 5 minutes, regardless if the app has been launched or not. IMHO this massively increases DNS lookups so ISPs can easily find a needle in the haystack if the app dumps a ton of needles in the haystack. Am I wrong? 288 daily pings versus “as needed”? Seems suspect given V1 does the exact same thing as V2, but didn’t require mandatory background checks. The “disable background latency checks” does nothing to stop this, and was only subject to pings during use.

Manually changing DNS provider away from ISP is a solution, but not for all those that don’t know how.

I only noticed this because these URLs rose to the top of a small home network I monitor. I blocked [apiv2.privateinternetaccess.com] in pi-hole just to see how it reacts. Pissed it off and it started trying [apiv2.piaproxy.net]. Blocked it too, and now both are constantly seeking an out. Not until you kill pia-daemon does it stop.

sudo systemctl stop piavpn && sudo systemctl disable piavpn

Prior URL behavior was (and still is) are the basic URLs for the VPN to connect/work:

serverlist.piaservers.net
www.privateinternetaccess.com
api.privateinternetaccess.com

Watch your wireshark/pi-hole logs and prove me wrong, because I am up for a multi-year renewal and if they’re not going to be a bit more transparent I will go elsewhere. I relayed my DNS logic to them after reading their reason and they are ghosting me now. If more customers inquire, they might put something on their website about major changes to their product’s normal behavior. I don’t need them trading privacy for convenience...or perceived convenience. I’ve never experienced any of the the things they are attempting to fix with V2.

• Linux Mint 22.3 - Cinnamon 64-bit
• PIA Version v3.7 (build 08412)
• pia-client (runs only when app is launched – pia-daemon required*)
• pia-daemon (auto configured to restart = always)

apiv2.privateinternetaccess.com?

I reached out to support to inquire what these new changes were. Here is their response:

>Jul 24, 2026, 11:41 AM GMT+8:

>Thank you for reaching out with your inquiry about the unexpected background requests to apiv2.privateinternetaccess.com when the PIA app is not actively running.

>I’d like to explain that these periodic 5-minute requests are lightweight, background maintenance checks performed by PIA's Linux system service. They occur regardless of whether the VPN tunnel is turned OFF or ON, and whether the app window is open or closed.

>Specifically, every 300 seconds, the background engine contacts PIA's V2 API endpoint to perform three essential upkeep tasks:

• Real-Time Server Stats: It checks for live server latency (ping) and load levels to ensure that when you press "Connect," the app can immediately route you through the fastest server without delay.
• Session Keep-Alive: It refreshes your secure login token, preventing your account from timing out while idle.
• Server Updates: It syncs any dynamic server list updates, streaming-optimized routes, or port forwarding configurations.

>Please rest assured that these queries are standard HTTPS requests that only download compressed public server data. No personal data, browsing activity, or traffic logs are transmitted during this process.

>If you have any further questions or concerns, please don’t hesitate to reach out.

>Regards,

>Private Internet Access Support