Author

admin

Browsing

Until recently, the Danish registry used to only verify contact information for registrants with an address in Denmark. In theory foreigners could also be verified, but this hardly ever happened. Any Danish registrant wanting to by-pass the verification, just needed to select a different country when registering their domain name.

While that old way of working was absurd, the Danish registry now made a complete U-turn which in practice can make a new domain name registration under .dk impossible for foreigners living in a non-English (or Danish) speaking country.
On top of that, foreign registrants might at any time loose their existing and active .dk domain names.

DK-Hostmaster makes a risk-based assessment to decide if they’ll request ID-verification from the owner or not. They do this with every new registration, but they might at any time also request you to proof your identity for existing domain names. Once they requested you to proof your contact details (including address information), they will no longer accept small rectifications to the information they have on file for you.

You have only once chance to supply the correct paperwork, before your domain name goes off-line. If you also fail to send in documents that are satisfactory to DK-Hostmaster in a second attempt, you completely loose all your .dk domain name registrations.

For foreigners, the biggest issue however is that the .dk-registry demands to receive documents either in English or Danish. For many non-English speaking countries, getting a bank statement or utility bill in English is simply impossible. While they refuse to give support related to a concrete case, .dk does (off the record) indicate that documents in an other language might also be accepted, if the verification agent decides they’re sufficiently comprehensible.

This means that a document that is accepted for one verification might be refused for the next verification. Causing all .dk domain names for that owner to instantly go off-line. Even domain names that have previously been successfully verified using the exact same documents. Simply because the verification happened to be carried out by a verification agent who wasn’t in the right mood to understand a document in Dutch or French or German or….

Seemingly at random verifications get refused with as only explanation “the documentation is not in English or Danish”. For new registrations this means the registration fee is lost and typically the registrant will decide to move on to an other extension. For existing domain names, the effects can be devastating as e-mails stop arriving and the website becomes unreachable.

In a response to our article, DK-Hostmaster informed us that they indeed only accept documents in English or Danish language, “to ensure a consistent decision-making process“. It seems that they achieved the exact opposite by this.
They also indicate that, if no English documents can be obtained, a legally certified (apostille) translation will also be accepted.
They aren’t yet considering eIDAS (e-ID) to be able to complete verifications. This is currently already very successfully used by a number of European registries for ID-verification (amongst others .ee, .be, .eu and .bg). But DK-Hostmaster currently finds the system too immature.

Since the launch of the ID verification by DK-hostmaster in 2017, their system was internationally often mentioned as an example of “how not to implement ID-verification”. In the lead up to NIS2 legislation, which will require some sort of verification to be carried out by all European registrars, the Danish seem to be eager to hold on to that status.

As we reported earlier, the takeover by Elon Musk of Twitter clearly was the straw that broke the camel’s back and eventually caused an exodus of twitter-users towards Mastodon.

Mastodon is very much different from how Twitter works. Contrary to having one centralized system to control everything, Mastodon works via many independent nodes that magically interconnect to each other (just like the internet itself). Everybody can run and control their own Mastodon server.

This means that, just like having an e-mail address under your own domain name, you can also have a mastodon account under your own domain name.

Clearly: this is what we wanted and we wouldn’t settle for less!

First step: register our own address. We selected a .social domain name because this points out that it’s a social media account. And… hey: there’s a promo ongoing for the .social extension. But any domain name extension can be used. You can even create a sub-domain under your existing domain name and use that.

We then started looking for an existing provider that would allow us to connect our own domain name to their services.

Apparently it’s currently not possible to share a Mastodon server. The current version of the server software available, assumes you’ll have one domain name per server.

So no “shared hosting”. A dedicated instance is required if you want to use your own domain. This is an existing business model already offered by a couple of providers. Because we were looking for a solution at the peak of the exodus, some of the providers however were closed for new subscriptions. The remaining providers were, according to our feeling, either too expensive or didn’t offer the control we hoped to have.

This made us eager to get our hands dirty and actually run our own instance. Joinmastodon.org has a nice overview of what is needed for this. But quickly we noticed almost every singly software used by Mastodon turned out to be a competing solution compared to what we were comfortable to work with. Maybe we didn’t want our hands to get this dirty after all.

Eventually we came about the possibility of installing Mastodon through Cloudron. So let’s dig in!

We rented a cheap Ubuntu 20.04 machine. Not the Linux distribution we’re used to work with, but we’re reasonably comfortable with it and eventually Cloudron will manage this for us.
Installing Cloudron is just three lines of code

wget https://cloudron.io/cloudron-setup
chmod +x ./cloudron-setup
./cloudron-setup

The installation will take some time. Once you have Cloudron on your server, Mastodon is just one click (and some more patience) away.

We’re now all ready and set with our own branded Mastodon account. So let’s meet at https://bnamed.social/@bnamed!

The registry behind .org, .ong and .ngo is getting ready to also launch the .giving domain. Just as their other TLD’s, the .giving extension is targetting the “do good” community. Both non-profit organisations doing a fund-raising and for-profit organisations who want to highlight the work they do in their community can register a .giving domain name.

When launching a new extension, registries go through different launch phases. The sunrise phase is mandatory and needs to be carried out according to ICANN guidelines. PIR (registry behind .giving) however has mixed procedures of two types of sunrises in a controversial way. They’ll be running an “end-date” sunrise. This type of sunrise is specifically designed to NOT be first-come first-served and because of this needs to be announced only 30 days up front.
The .giving sunrise is announced as end-date sunrise (so not first-come first-served), yet at the end of the sunrise, the domain names will be awarded to the applicant who requested it first (so… it’s first-come first-served).

Also for the landrush phase, it seems the registry has had to make a creative compromise. The only requirement to already apply for your domain name during landrush and not wait for Go-live, is that you have considered using the (free) services of justgiving.com. You don’t have to actually sign up with them. But you need to have thought about signing up.
It’s unclear how this will be enforced, but the registry does make clear that, if have not thought about justgiving.com before registering your .giving domain name, they are allowed to revoke your registration.

The complete .cd zone (country code for the Democratic Republic of the Congo) is off-line since at least yesterday, because the .cd-registry forgot to renew the .net domain name under which all nameservers for .cd are hosted.

The .cd-registry uses 3 nameservers which seem to be correctly located in independent locations. But all are subdomains of the same domain name scpt-network.net. And that domain name expired a couple of days ago.

To complicate things even further, it seems the domain name is registered through a reseller of eNom who doesn’t have an active website.

We reached out to both the current registrar and reseller of this domain name to offer assistance with restoring the .cd zone, but are waiting for their response.

The .cd extension has had a somewhat turbulent history lately. The extension was originally run by a Congolese citizen who moved to South Africa and hosted the registry system on the network of a South African university. Because the Congolese government wanted to keep the .cd extension within Congo, in 2017 they kicked out the foreign administrator. Since that time, no new registrations or even updates were possible. Existing domain names however remained active. A message promising those services to be restored any time soon has been on the registry website for at least 4 year since.

The .cd-registry clearly isn’t very good at renewing their most crucial domain name. Last year they had this exact same issue. At that time, they used scpt-network.com for their nameservers and let that one expire. The .cd zone then didn’t go down completely, because they also had nameservers under a different domain name which they rented from a large African network provider. But scpt-network.com was later re-registered by a white hat hacker who tried to give it back to the .cd-registry. Read more about how Fredrik Nordber Almroth’s “hijacked a top-level domain”

Update: shortly after our post, the .cd-registry renewed the domain name scpt-network.net and .cd domain names started working again.

Every 3 months a special ceremony takes place in which new cryptographic “Zone Signing Keys” are being signed, which will be used the next quarter to secure the root DNS zone. These DNSSEC keys are the basis of every DNSSEC-protected domain name. A copy of the “Key Signing Key” required for this, is kept at two secure locations in the US. In order to be able to use it, multiple steps need to be taken during a lengthy ceremony, including the opening of two safes by IANA/ICANN staff. February 12th such a ceremony should have taken place. Since the expected life time of the safes had been reached, IANA had scheduled for them to be replaced. For one of the safes, the expected life time turned out to be extremely accurate: while trying to open it, the lock mechanism refused to cooperate.

Sectigo (formerly known as Comodo) is one of the leading providers for certificates. Such certificates are used to encrypt internet traffic going to websites and mailservers. Sectigo is now recalling almost 6000 certificates, all of which were issued to companies from The Netherlands. The recall action was announced Wednesday. Affected clients have less than one week to install a new certificate. On January 28 the old certificates will be revoked and websites on which the certificate has not been replaced will refuse to load.

Last week over 350.000 .uk domain names have (finally) been claimed by their rightful owner. Over the last 3 weeks combined, there were even well over one million .uk domain names registered. That’s much more than for example the 271.000 .uk names registered during the 52 weeks of 2018.

Almost exactly 5 years ago, direct registrations under .uk were launched. Prior to that time, only registrations under subdomains like .co.uk or .org.uk were possible. Owners of a .co.uk (or .org.uk, .net.uk,…) however had their name reserved for them free of charge for the first 5 years. Because of this, most stuck with their .co.uk domain name and didn’t bother registering (and starting to pay for) the same name under .uk.