Nameservers Changed Issues on Sav.com

[xmarthost]

My nameservers for all domains have been changed to ns1.all-harmless.domains and ns2.all-harmless.domains, and I am unable to change the DNS again. What could be the issue?

Also, a friend of mine is facing the same problem with over 600 domains. What's going on with sav.com?

 

[Future Sensors]

They're pending moderator approval.

I didn't expect that to be necessary for your account. But I'll wait and see. Thank you.

 

[dirk]

I don't agree with the assessment of it being a security

Take note people. Rookie mistake.

So back in 2021, right after you bought the domain from buy domains, you decided sav was the best registrar to go with?

Interesting...

Edit: could be worse... You seem to like freenom as well.

 

[bmugford]

Take note people. Rookie mistake.

So back in 2021, right after you bought the domain from buy domains, you decided sav was the best registrar to go with?

Interesting...

Edit: could be worse... You seem to like freenom as well.

Additionally, I would expect a company in the security field to have registry lock on their domain.

The cost is only like $10/month.

Sav.com has it on. CleanDNS does not.

Brad

 

[zotix]

We like them. We do have domains in other places

Well, if you like them. go for it

.....................

 

[Future Sensors]

freenom

I said earlier in this thread that I'm proud of influential DNS engineers from the Netherlands.

Let me also clearly state that I'm not proud of Freenom, that's also a Dutch company, and is based in the Houthavens district.

 

[zotix]

We like them. We do have domains in other places. I don't agree with the assessment of it being a security issue.

But you are aware, that this is not allowed in some countries, right?
In Germany, there is a quote that is translated as "You don't eat, where you puke."

 

[dirk]

I said earlier in this thread that I'm proud of influential DNS engineers from the Netherlands.

And you should be. Dutch engineers played a significant role in establishing the web as we know it today. And still are.

Remember, .NL was the first cctld outside of the United States.

Let me also clearly state that I'm not proud of Freenom, that's also a Dutch company, and is based in the Houthavens district.

Agreed. Shameful.

 

[dirk]

But you are aware, that this is not allowed in some countries, right?
In Germany, there is a quote that is translated as "You don't eat, where you puke."

It also creates a single point of failure... But what do we know?

They like sav...

The question is... Why?

 

[Future Sensors]

It also creates a single point of failure

I am particularly concerned if more registrars start outsourcing their abuse handling to CleanDNS with their experimental AI. The knowledge will disappear from the registrars and CleanDNS will become a SPOF on its own.

 

[dirk]

I am particularly concerned if more registrars start outsourcing their abuse handling to CleanDNS with their experimental AI. The knowledge will disappear from the registrars and CleanDNS will become a SPOF on its own.

Considering they're working for PIR, it migh just endanger the entire .org namespace.

 

[Future Sensors]

Considering they're working for PIR, it migh just endanger the entire .org namespace.

Jeff Bedser was a PIR.org board member.

 

[dirk]

I am particularly concerned if more registrars start outsourcing their abuse handling to CleanDNS with their experimental AI. The knowledge will disappear from the registrars and CleanDNS will become a SPOF on its own.

They have an interesting history. It seems like they know what they're doing. Some big players using them.

That's why the sav connection seems out of place.

Probably happened when they launched cleandns and sold off the parent.

 

[Future Sensors]

Some big players using them.

There is a great deal of overlap between members of interest groups and major commercial companies in our sector. Many deals are closed this way.

 

[Future Sensors]

For the sake of completeness, I should also mention that people from PIR.org have gone to work for IQ Global, who also do managed abuse handling. In fact it is a far superior product. And there are others that I will not mention atm.

https://iq.global/iq-managed-abuse

 

[Gabriele]

@Gabriele Thank you very much for bringing this to our attention! We have fixed the root issue and have affected the expired/deleted domains being moved to the correct status as we speak. It looks like the root cause was some domains with a duplicate entry in our database caused by a piece of deprecated code that ran about a year ago. We do have a bug bounty program and we would love to issue a reward for bringing this to our attention. Just submit the report here with proof attached that you are @Gabriele from NP and ill keep an eye out for it. https://help.sav.com/hc/en-us/articles/26129438833819-Bug-Bounty-Program

I confirm that the problem is resolved. While I still can see old duplicate listings, I tried changing the nameserver or viewing the auth code and now an error message appears. However, the same error message also appears in the listing of the actual owner, so you might want to include a note in the message to contact support or something similar. I will send the email soon, thank you.

 

[bmugford]

I confirm that the problem is resolved. While I still can see old duplicate listings, I tried changing the nameserver or viewing the auth code and now an error message appears. However, the same error message also appears in the listing of the actual owner, so you might want to include a note in the message to contact support or something similar. I will send the email soon, thank you.

Thanks for pointing this out.

Though, it is alarming that such a major security issue was not noticed by them. It makes me wonder what other security issues there could be.

Of course this could never happen if there were not orphaned listings to begin with.

Brad

 

[Future Sensors]

Thanks for pointing this out.

Though, it is alarming such a major security issue was not noticed by them. It makes me wonder what other security issues there could be.

Of course this could never happen if there were not orphaned listings to begin with.

Exactly. Domain registrars must continue to meet ICANN contractual compliance, also in the area of security of their systems. ICANN audits are regularly performed for this purpose. A registrar can choose to outsource certain processes to external parties to save some costs, but if your core systems are not in order, you will be working on the basis of incorrect data, and the integrity of registrant data (and domains) is at risk.

https://www.icann.org/resources/pages/audits-2012-02-25-en

https://www.icann.org/resources/pages/compliance-reports-2024

https://www.icann.org/en/system/files/files/contractual-compliance-complaint-03sep15-en.pdf

 

[Future Sensors]

Though, it is alarming that such a major security issue was not noticed by them. It makes me wonder what other security issues there could be.

CleanDNS CEO had never seen such good security at any other registrar than Sav in 15 years of being in ICANN circles.

That also says a lot.

 

[Future Sensors]

Who's writing all this PR fluff.

The following job listing is now closed, but here's an overview of what a Marketing Specialist role at CleanDNS entails:

https://www.wayup.com/i-j-CleanDNS-835775051281139/

 

[Future Sensors]

---

Re the legal aspects of blocking/closing Sav customer accounts completely ("this decision is final"), and then unblocking them later (on request) because CleanDNS AI made a mistake.

This slide above is from a 2022 presentation by Mr. Alan Woods on "Trusted Notifiers & gTLD Registries", which also highlighted the CleanDNS product.

Mr. Alan Woods is currently serving as Chief Policy Officer and General Counsel at CleanDNS, Inc.

He previously held the position of Director of Compliance and Policy at Donuts, Inc. (now Identity Digital, Inc.)

The ICANN SAC115 document referenced in the slide is from March 2021, and can be found here:

SAC115: SSAC Report on an Interoperable Approach to Addressing Abuse Handling in the DNS

https://itp.cdn.icann.org/en/files/...dvisory-committee-ssac-reports/sac-115-en.pdf