Retiring ns.ripe.net

Reverse DNS provisioning process

LIRs request reverse DNS delegation by creating “domain” objects in the RIPE Database. The domain objects must contain “nserver” attributes, defining the name servers for a given reverse DNS zone. When a domain object is submitted for creation or modification, the RIPE Database invokes the RIPE NCC’s instance of Zonemaster, which performs pre-delegation checks. If the checks pass, then the object is created or updated. The RIPE Database feeds the stream of domain objects to a provisioning programme, which updates the parent zones with the delegations and publishes them.

LIRs with large allocations currently may specify “ns.ripe.net” as a name server in one of the “nserver” attributes. When such an object is submitted into the RIPE Database, the pre-delegation checks are run, but Zonemaster is configured to ignore errors pertaining to the name server “ns.ripe.net”. That is because the name server will not have been configured with the reverse DNS zone yet. If all the other checks pass, then the object is updated. After this, the provisioning program notices that one of the requested name servers is “ns.ripe.net” and does extra work to figure out the primary server(s) of the zone, and adds the zone to the configuration of “ns.ripe.net”.

Issues with the service

Unfair for LIRs with small allocations

Originally, this service was designed for LIRs with large allocations. Back in the day, it was not easy to have a diverse DNS infrastructure, and the uninterrupted operation of large reverse DNS zones was considered essential. ns.ripe.net ensured they had a stable DNS service in case of outages. Even if the LIR’s DNS servers were unreachable, the RIPE NCC DNS service would allow resolution of these zones.

Due to a bug in RIPE Database logic, for some time, members with smaller allocations than intended could also create delegations in the database that were then accepted. This bug has now been fixed, but those delegations that were already added have continued to receive the service. This is unfair to newer members who now want to use the service but cannot.

Today, the situation is quite different from when we created this service. There are many companies providing secondary DNS as a service, some for free and others for a fee. Large LIRs are more likely to have resources to operate a diverse DNS infrastructure. It is the smaller LIRs who are less likely to have resources for such an infrastructure. Therefore, the RIPE NCC secondary DNS service can also be seen as unfair to smaller LIRs.

Competition with RIPE NCC members

Many companies provide secondary DNS services these days. Some of them are also RIPE NCC members. This means the RIPE NCC’s free secondary DNS service is competing with its own membership. People interested in these alternatives can ask about them on the DNS Working Group or the DNS Operations mailing list.

Provisioning

One problem we see is that many LIRs forget to allow transfers of their zone(s) to the RIPE NCC’s transfer servers. This means that ns.ripe.net fails to load these zones and responds with a SERVFAIL response code when queried. In other cases, a zone may initially be fine, but goes stale at a later point in time because of configuration changes by the LIR, during which they forgot about the RIPE NCC server.

There is also no way to specify a shared secret to configure TSIG keys. The RIPE NCC transfer servers could be fed incorrect data by someone who manages to hijack one of the IP addresses of the primaries.

Unpredictable zone sizes

Normally, the operator of a secondary DNS service wants to know the size of the zones they are configuring on their server. This is to ensure that the server has enough memory to load the zones. But with this service, the RIPE NCC has no way of knowing this in advance. As a consequence, we have been in the unfortunate situation in the past where an LIR configured several large reverse zones, which exhausted the RAM on a number of our smaller servers. This required emergency adjustments to allow the service to continue uninterrupted.

Irrecoverable situations

Sometimes an operator’s zone gets into a bad state, causing fatal errors in the Zonemaster pre-delegation check. If the zone is being secondaried by the RIPE NCC, and the RIPE NCC can no longer transfer the zone, then pre-delegation checks will fail even when the operator tries to update their domain object, a situation not even the operator can fix.

One example we’ve seen involved an operator with a DNSSEC issue who tried to turn off DNSSEC for their zone by deleting the DS record via a domain object update. The pre-delegation checks failed on DNSSEC checks because the DS record was still present, but the zone had no signatures. The Zonemaster service we use, while quite flexible in many ways, was not able to handle this situation, and we had to intervene.

Strain on RIPE NCC DNS infrastructure

Many zones in the RIPE NCC configuration are broken in some way or another. Some zones were never provisioned properly, and others started off fine, but are now broken because the LIR changed configuration and denied the RIPE NCC access. Every such broken zone is a strain on resources. First, the transfer servers have to keep trying to refresh them, and denying refresh resources for other working zones. Then the RIPE NCC servers have to continue answering with SERVFAIL responses for these zones, thus wasting resources (CPU, bandwidth, etc.).

In the graph below, you can see some statistics on the number of broken delegations and affected LIRs.

Proposal for retiring the ns.ripe.net service

We proposed to retire this service at RIPE 72 in 2016. At that time, the consensus was that we should continue providing the service. However, we are now 8 years further along and the problems with the service are still present, and in some cases, even more obvious.

We have considered the best way forward and weighed the pros and cons of trying to address all of these issues. While this service is useful for some of our members, the amount of work needed to address the technical problems we have encountered seems to outweigh the benefit to our membership overall. On top of this, we cannot solve the inherent problems that the service gives preferential treatment to larger LIRs and competes with our own members’ services. So we now have two options - either we stop the service, or we accept the above issues and continue as is. Our preference would be to stop the service, but we are eager to hear from our community what they believe is the best way forward and welcome suggestions for an alternative solution.

The process of discontinuing ns.ripe.net would involve the publication of a detailed procedure for LIRs so that they could discontinue the use of RIPE NCC servers in a safe way. The RIPE NCC would also send emails to all operators with links to this procedure. We anticipate there would be some instances where we would have to intervene to help some operators update their domain objects. The RIPE NCC would also stop accepting updates to domain objects requesting secondary DNS service from us.

If the community supports our proposal to sunset ns.ripe.net, we would implement this approach according to the timeline below:

1. From 1 July 2024: Stop accepting ns.ripe.net in newly created or updated domain objects and tell users to stop using ns.ripe.net
2. July - December 2024: Efforts to contact users who are continuing to use the service
3. 31 December 2024: Remove any delegations still pointing to ns.ripe.net

By taking these steps, we want to increase the stability and security of our Authoritative DNS service (and that of our members), stop competing with our membership and stop giving unfair advantage to holders of large blocks of addresses.

We want to know what you think. If you see any problems with this approach, please share your feedback with us on the DNSWG mailing list (dns-wg@ripe.net) by 16 May 2024. Please also let us know if you agree with our recommendation or have your own suggestions about the way forward. We will then discuss this in the DNS Working Group session at RIPE 88 on 22 May 2024 (Wednesday morning).