registrars Various registrars adding DS Record (DNSSEC) to your domains withoug your knowledge

[blank]

Noticed some weird situation with some of my recently transferred domains:

cloudflare notified me that the configuration is not valid because I have a DS-Record
I never set a DS-Record for any of my domains because, at this point, DS Records are a pain in the a**.

If you have a DS-Record and you are no longer with the registrar where it was set, your domain name will no longer resolve on most modern browsers because, basically, the NS is no longer authoritative for the zone.

I did a little bit of an investigation and I noticed that quite a few of my domains were affected.

For most of them, I backtracked the issue with LCN. For some reason they set DNSSEC records without asking you.
I had a discussion with them and they are just plain idiots. They don't really understand how this works at all. I don't suspect them of doing this intentionally just to keep the customer or to take vengeance.

On the other hand, there is at least one situation where the DSSEC record did not originate with LCN but with a very popular registrar amongst us domainers.
It is very interesting that it was set after expiry, during the grace period, just when the NS change too.

If this is intentional, it is a very very mean way to f**k with customers that will transfer out.

 

[capybara]

with a very popular registrar amongst us domainers.

Uniregistry?

 

[blank]

At this point it is clear that there is no mistake - it is consistent behavior.
I will not post the name of the registrar yet.

The situation is very serious if you transfer to a registrar that does not support DNSSEC (and there are many of those). You will be unable to use that domain name until you transfer again to a registrar that supports DNSSEC so that you can disable it.

 

[capybara]

I don't know why the secrecy, but I can share my own experience. I don't use Uni myself as a holding registrar but some time ago I bought a domain there, and after setting my nameservers it wouldn't start resolving, so I started checking and it appeared it was because of a DS record which I "received" with my purchase.

 

[blank]

@Don Gondon - sounds like Uni does it too then.
@Uniregistry - care to comment?

I was not referring to Uni because I don't use them so I don't know them.

I'm not mentioning the registrar yet because, in my opinion, this tactic is shameful from the ethical perspective. It would be "naming and shaming" and I don't want to do that just yet. Maybe it's a mistake and they'll fix it, maybe they're just as clueless (bust harmless) as LCN.

I reached out to them, waiting for a reply.

 

[capybara]

I am not sure why this would be "shaming", every company can have some erroneous things going on and people discussing it in public is not really shaming... just discussing.

However, in the case of this problem, I am not even sure we can truly describe it as an error. If we buy a domain – we most likely don't need other people's DS records, we probably don't need even their nameservers. However, if we buy a site, we want it to work with no downtime during the ownership transfer, and in this case all DNS settings should be preserved as they are. The best solution would probably be to have an option during the transfer/push – to keep or not to keep that.

 

[blank]

The problem is that they add DS records without the customer knowledge.
The bigger problem is why they do it. That's where the ethics come into question.

If you transfer such domain to a registrar that simply does not support DNSSEC you have a huge problem.

 

[Rob Monster]

Actually, (free) DNSSEC is a very good thing.

However, when domains transfer out, DNSSEC should be disabled -- since registrars that don't have it still exist and that does create issues.

@vitigo

 

[blank]

In a perfect world, where everybody plays by the rules, DNSSEC is a very good thing.
In this world it is a nuisance.

I don't think we need registrars to force us into adopting DNSSEC. We will do that on our own, like with many other technologies.

In this case, the use of DNSSEC was forced and it was enabled without the customer's knowledge (or consent).
In this case, DNSSEC basically glues a domain to a registrar for the less tech savvy amongst us.
I can guess why ... and it's not at all pretty.

LE: Rob - disabling the DNSSEC key when transferring out kind of beats the purpose for DNSSEC

 

[Rob Monster]

In a perfect world, where everybody plays by the rules, DNSSEC is a very good thing.
In this world it is a nuisance.

I don't think we need registrars to force us into adopting DNSSEC. We will do that on our own, like with many other technologies.

In this case, the use of DNSSEC was forced and it was enabled without the customer's knowledge (or consent).
In this case, DNSSEC basically glues a domain to a registrar for the less tech savvy amongst us.
I can guess why ... and it's not at all pretty.

LE: Rob - disabling the DNSSEC key when transferring out kind of beats the purpose for DNSSEC

There was a huge industry push in 2018-19 to get all registrars to use DNSSEC, in part because DNS hijacking has become much more rampant as a core hack strategy.

ICANN has a good primer on the topic:

https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en

Why would anyone in their right mind move domains to a registrar that does not support DNSSEC?

As for the expired domains, obviously if the domain was strategic, the registrant would not let it expire. So, disabling DNSSEC for an expired domain that is leaving makes sense.

Also, Epik does allow users to set Epik DNS even if domains are registered elsewhere, including the option of using DNSSEC.

Other registrars actually break your DNS the moment you leave them. We don't do that and don't plan on starting precisely because it fails the "do unto others" test.

 

[blank]

Rob - I mailed you with my test results.
I know what you mean, I am familiar with the topic.

This might be a bit of a "corner case" but it is still valid.
I suggest configuring your systems to behave the way you describe here.
At this time there is a difference in some situations.

Knowing you, I am willing to believe that this is not intentional and it was a simple mistake as the current config fails the "do unto others" test

 

[branding]

In a perfect world, where everybody plays by the rules, DNSSEC is a very good thing.
In this world it is a nuisance.

I don't think we need registrars to force us into adopting DNSSEC. We will do that on our own, like with many other technologies.

In this case, the use of DNSSEC was forced and it was enabled without the customer's knowledge (or consent).
In this case, DNSSEC basically glues a domain to a registrar for the less tech savvy amongst us.
I can guess why ... and it's not at all pretty.

LE: Rob - disabling the DNSSEC key when transferring out kind of beats the purpose for DNSSEC

I agree. The process of transferring DNSSEC enabled domains is a mess.

Registrars who are signing by default should be stripping the DNSSEC related records upon a transfer out by default unless you explicitly chose to keep them intact.

But like you said, that would leave you vulnerable for a certain amount of time.

It can be fixed at the registry level and it is them who should come up with a solution. I'm only aware of SIDN (NL registry) using an EPP extension that will solve most of these issues.

In 99.999% of my domains I stay away from using DNSSEC for a multitude of reasons but issues like OPs play a big part.

 

[Future Sensors]

For die-hards, there's this proposed standard (RFC 8063)

Key Relay Mapping for the Extensible Provisioning Protocol

https://www.rfc-editor.org/rfc/rfc8063.txt

https://datatracker.ietf.org/doc/html/rfc8063

Here's some background:

https://www.sidn.nl/en/news-and-blogs/key-relay-keeping-the-dnssec-chain-intact-during-transfers