AutoDNSSEC does not update registrar DS records

[RobinDaugherty]

Describe the bug
The CLOUDNS provider is able to activate AutoDNS, but doing this does not remove existing DS records and may leave the domain with mismatched DS records.

To Reproduce
Steps to reproduce the behavior:

1. Transfer DNSSEC-enabled domain to ClouDNS
2. Configure the domain using dnscontrol to include AUTODNS_ON
3. Push the changes to the domain, observing that the domain nameservers are changed to the ClouDNS ones

Expected behavior
DNSSEC is enabled on the domain and it contains the correct DS record(s).

DNS Provider

• CLOUDNS

Additional context
In the ClouDNS user interface for the domain's DNSSEC status, the old DS record is shown underneath the form. There's a "delete" button next to the old DS record. Deleting it causes DNSSEC to resolve correctly on the domain.

[RobinDaugherty]

After more research I believe this is expected behavior.

I'm going to propose a feature change.

AUTODNSSEC is entirely a DNS provider feature—it enables DNS record signing.
Even for providers that are registrars, AUTODNSSEC does not write generated DS records to the domain registrar.

dnscontrol doesn't support querying or setting DS records at the registrar.
If you use the DS domain modifier in your domain declaration, dnscontrol adds DS records to the DNS zone, not to the registrar.
In fact, only one of the providers that supports DS records even implements registrar functionality.

In order to enable DNSSEC validation, you must get the DS records generated by the DNS service and have your domain registrar add them to your domain. The registrar then sends them to the domain registry, who serves the DS records to form the trust hierarchy.

The desec provider mentions this in its documentation, and helpfully outputs a note along with the DS records at domain creation time.
Some other providers specify that DS records are only supported "at the apex" and some mention that setting DS records would require implementing a different API call.

• https://github.com/StackExchange/dnscontrol/blob/5fe352374e99a79fbc2d71dfe8bb9f42f614d8a9/providers/desec/protocol.go#L263-270

• dnscontrol/providers/gandiv5/gandiv5Provider.go

  Line 59 in 5fe3523

  providers.CanUseDS: providers.Cannot("Only supports DS records at the apex"),

• dnscontrol/providers/inwx/inwxProvider.go

  Line 57 in 5fe3523

  providers.CanUseDS: providers.Unimplemented("DS records are only supported at the apex and require a different API call that hasn't been implemented yet."),

• dnscontrol/providers/rwth/rwthProvider.go

  Line 25 in 5fe3523

  providers.CanUseDS: providers.Unimplemented("DS records are only supported at the apex and require a different API call that hasn't been implemented yet."),

I think the AUTODNSSEC_ON modifier might be misnamed since it really just means "the DNS service provider will generate DS records and signatures" 😬

These capability declarations seem to me like there was intent to support apex DS records that might be stored at the registrar while treating any other DS records differently.

https://github.com/StackExchange/dnscontrol/blob/5fe352374e99a79fbc2d71dfe8bb9f42f614d8a9/pkg/providers/capabilities.go#L59-65

	// CanUseDS indicates that the provider can handle DS record types. This
	// implies CanUseDSForChildren without specifying the latter explicitly.
	CanUseDS

	// CanUseDSForChildren indicates the provider can handle DS record types, but
	// only for children records, not at the root of the zone.
	CanUseDSForChildren

---

ClouDNS API supports the listing and setting of DS records at the registrar level. I'm thinking of implementing registrar-level DS records there.

It seems like applying the existing DS modifier to the domain registrar would be a breaking change.

Proposal

I would like to implement something like the automaticity of domain name servers: the DNS provider gives the list of expected name servers, and the registrar applies those by default.

There's an ability to include a specific number of the nameservers from a DNS provider's list, but I don't think such a feature is needed for DS records, since they are additive.
(The process of switching DS records involves adding a new record and wait for TTL to expire before removing the old one.)
Having deprecated/vestigal DS records at the registrar is preferred over removing them too soon.

So we treat registry DS records as if "no purge" is enabled, and allow registry DS records to be removed only through domain modifiers.

Automatic publishing

Implementation of automatic (additive) DS record publishing.
Whatever DS records the DNS provider reports are added to the registrar.

• New capability CanUseDSAtRegistrar

• New domain modifier DNSSEC_AUTO_PUBLISH_ON. Enabling it requires CanUseDSAtRegistrar capability on the registrar provider.

  • When enabled, DS records are gotten from the results returned by GetZoneRecords.
  • To support DNS providers that need to make a separate API call to get apex DS records (such as ClouDNS), a new interface ApexDSLister with function ListDSRecords which would be favored over (or in addition to?) GetZoneRecords
  • Internal change to dnscontrol similar to DetermineNameServers and generateDelegationCorrections that concatenate the apex DS records.
  • When enabled, GetRegistrarCorrections detects DS record missing from the registrar and adds a correction to add new DS records to the registrar.

• New domain modifiers DNSSEC_AUTO_SIGN_ON and DNSSEC_AUTO_SIGN_OFF that are aliases to the existing AUTODNSSEC_ON and AUTODNSSEC_OFF respectively. Eventually the old names could be deprecated.

Manual DS records

Allow the DS record declarations to alter the registrar DS records.

• Records created by the DS domain modifier are appended to the registry list when their target is @.

• Records with the ENSURE_ABSENT_REC() modifier are removed from the registrar.
  This is the only way that DS records would be deleted.

[tlimoncelli]

CC @eliheady who is also interested in improving DS features

[eliheady]

Better DS handling would be great.

As I began implementing DS handling for INWX (for registry) and deSEC (for children) (as yet unpublished), I found it cumbersome to have to filter DS records based on the provider operating mode. If the service only supports DS in downward delegations (like deSEC) then the provider code has to filter records to look for use at apex and ignore it. The registrar/providers that don't support DS in-zone have to filter for apex only usage.

I suspect the reason we have both NS and NAMESERVER is because a similar challenge appeared early on: like is this particular NS record for a child zone or to be inserted into the parent? So we have NAMESERVER instead of NS('@', ...). At first I thought maybe we need a DELEGATIONSIGNER or some such record handler that would be for managing DS in the parent. Now I think a bigger overhaul of registry support could be a good idea.

Anyway, I am not so sure about making it difficult to remove manual DS records. The need to use ENSURE_ABSENT_REC for manual maintenance makes me think we should have a different device for managing DS in the parent, whether something like DELEGATIONSIGNER or a new registrar interface.

[RobinDaugherty]

At first I thought maybe we need a DELEGATIONSIGNER or some such record handler that would be for managing DS in the parent.

I went through the same thought process—it felt like would be cleaner not to touch the existing DS declarations. I also considered a modifier that could be applied to DS declarations that would cause them to also apply to the registrar, but that seems a bit too complex. I tried to come up with a scenario where apex DS records added to the DNS zone would not also be desired in the parent domain, but I couldn't think of one. Am I missing something? Is it enough of an edge case that it could be covered by another modifier e.g. EXCLUDE_FROM_PARENT applied to the DS record?

I am not so sure about making it difficult to remove manual DS records.

I agree, it feels cumbersome to me. I dislike the idea of keeping around negative declarations forever in the dnsconfig. Maybe a new command that would delete old DS records from the registrar? Then we could just keep firm on the "no parent DS deletions" policy for preview/push commands but anyone that wants to clean up old DS records could run delete-old-parent-ds-records command? Or is the project moving away from distinct commands like this?

[tlimoncelli]

Disclaimer: I don't know how DS works. I'm reading your comments and guessing what might be helpful.

It sounds like it would be sufficient to have the user specify DS records like normal, but we need a way to tell the registrar what to do with them.

Let's start with the user-visible aspects and work backwards. (Yes, @RobinDaugherty, your suggestions about how to implement this are good. Though, CanUseDSAtRegistrar should be set automatically based on which interface is completed).

Here are some (fictional) syntax options that we could implement:

D("example.com", REG_MYREG,
    DELEGATIONSIGNER(true, false);   // requires the user to know the proper order
    DS("example.com", 2371, 13, 2, "ABCDEF"),
);

or

D("example.com", REG_MYREG,
    DS("example.com", 2371, 13, 2, "ABCDEF", { update_parent: true, remove_old_records: true),
);

or

D("example.com", REG_MYREG,
    DS_CONFIG({
         update_parent: true,
         remove_old_records: true,
         something_else: true,
    }),
    DS("example.com", 2371, 13, 2, "ABCDEF"),
);