Verisign and Registrar.eu RDAP show different nameservers — Dynadot changes are not reaching the .COM registry
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 a customer-facing domain provider using a promotional offer from 899. I have always managed the domain through that provider’s control panel.
The domain is supposed to use these two Cloudflare nameservers:
audrey.ns.cloudflare.com
sid.ns.cloudflare.com
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 domain provider’s control panel. It still displayed the same two Cloudflare nameservers. I did not see any unknown nameservers or unauthorized configuration changes.
However, when I queried Verisign’s authoritative .COM registry servers directly, they returned three completely different nameservers:
ina1.registrar.eu
ina2.registrar.eu
ina3.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 RDAP data published by Verisign and Registrar.eu.
The relevant part of the Verisign registry RDAP response is:
{
"events": [
{
"eventAction": "registration",
"eventDate": "2026-04-08T16:43:25Z"
},
{
"eventAction": "expiration",
"eventDate": "2027-04-08T16:43:25Z"
},
{
"eventAction": "last changed",
"eventDate": "2026-08-12T10:08:33Z"
},
{
"eventAction": "last update of RDAP database",
"eventDate": "2026-08-12T17:13:05Z"
}
],
"secureDNS": {
"delegationSigned": false
},
"nameservers": [
{
"objectClassName": "nameserver",
"ldhName": "INA1.REGISTRAR.EU"
},
{
"objectClassName": "nameserver",
"ldhName": "INA2.REGISTRAR.EU"
},
{
"objectClassName": "nameserver",
"ldhName": "INA3.REGISTRAR.EU"
}
]
}
However, the Registrar.eu RDAP response for the same domain contains:
{
"events": [
{
"eventAction": "registration",
"eventDate": "2026-04-08T16:43:25Z"
},
{
"eventAction": "expiration",
"eventDate": "2027-04-08T16:43:25Z"
},
{
"eventAction": "registrar expiration",
"eventDate": "2027-04-08T16:43:25Z"
},
{
"eventAction": "last update of RDAP database",
"eventDate": "2026-08-12T17:13:59Z"
}
],
"nameservers": [
{
"ldhName": "audrey.ns.cloudflare.com",
"objectClassName": "nameserver"
},
{
"ldhName": "sid.ns.cloudflare.com",
"objectClassName": "nameserver"
}
]
}
The registration and expiration dates match, but the nameserver data does not:
- Verisign’s registry RDAP lists three Registrar.eu nameservers.
- Registrar.eu’s RDAP lists the two intended Cloudflare nameservers.
- My domain provider’s control panel also lists the two intended Cloudflare nameservers.
- Direct queries to Verisign’s authoritative .COM servers confirm that the registry is actually publishing the Registrar.eu nameservers.
I understand that “last update of RDAP database” is only the time when the RDAP data was refreshed. I am not treating that as the time of a domain configuration change.
The important event appears to be:
"eventAction": "last changed"
"eventDate": "2026-08-12T10:08:33Z"
This event appears in the Verisign registry response but not in the Registrar.eu RDAP response.
I did not make any domain-related change at that time. I was having dinner and was not using the provider’s control panel. I also found no corresponding nameserver change in my account.
I understand that “last changed” does not necessarily mean the nameservers were changed at that exact time. It could refer to another field in the Verisign domain object. However, the public RDAP response does not include an event actor or identify which fields were modified.
As a troubleshooting step, I removed the Cloudflare nameservers through my domain provider and added them again. The control panel 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 Verisign’s authoritative .COM servers, even if recursive DNS caches require additional time to expire.
I checked the security information available in my account and found no unknown login or visible unauthorized configuration change. I currently have no evidence that my account was compromised, although 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 the customer-facing domain provider may be acting as the retailer or reseller, while Registrar.eu/Openprovider is the registrar of record communicating with Verisign through EPP.
The current situation appears to be:
The customer-facing control panel contains the correct Cloudflare nameservers.
Registrar.eu’s RDAP contains the correct Cloudflare nameservers.
Verisign’s .COM registry publishes different Registrar.eu nameservers.
Direct queries to Verisign’s authoritative servers confirm the incorrect registry delegation.
Removing and re-adding the Cloudflare nameservers does not update Verisign.
Verisign shows an unexplained “last changed” event that I did not initiate.
Because of the incorrect registry delegation, the domain was directed to an unrelated parking or advertising service.
DNSSEC is currently not enabled, as shown by "delegationSigned": false.
My questions are:
- Does this look like a registrar-to-registry EPP provisioning or synchronization failure?
- What could cause Registrar.eu’s database to contain the correct Cloudflare nameservers while Verisign continues publishing Registrar.eu nameservers?
- Could an automated provisioning or synchronization process have overwritten the registry delegation?
- What types of changes can update Verisign’s “last changed” timestamp?
- Can the registrar identify the exact EPP transaction associated with the registry change, including which fields were modified and whether it was initiated manually or automatically?
- Should the registrar be able to locate the corresponding 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 or Openprovider?
I have asked the customer-facing provider 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.