Feedback DNSSec

[Jordi Kroon]

Hi there,

Tested out DNSSec today, but faced a couple of issues.

DS Key. When trying to add the DS key to the DNS zone, nothing happens. I get an error 400 in the background. See error below:

   "code": 400,

    "message": "Invalid value for 'entity.change.additions[0]': 'DS'"

DNSSEC Key. I tested transfer state. I was able to add the DNSKey to my zone, but deleting the DNSSec key is causing issues. See image below.

Because I have a DNSSec key set that I can't delete, I'm unable to fully remove DNSSec and thus had to fallback to the parent DNS Server instead. Would be great if you could remove it manually for me instead.

Would be great if you could update me on future changes in the DNSSec feature. Love helping you guys out.

Kind regards,

Jordi Kroon

[Jordi Kroon]

It'd be handy if I included some details like project ids I guess? Here they are:

Project id: idyllic-lotus-156921

Zone that's broken right now: jordikroon

Account owner email: jordik...@gmail.com

Kind regards,

Jordi Kroon

[Richard Woodbury]

Hi, Jordi. Thanks for trying out Cloud DNS DNSSEC.

Regarding the DS: Normally, the DS is not placed in your Cloud DNS zone, but is given to your registrar to be placed at the registry (in your case, .nl). If you try to place a DS in your zone at the apex (i.e., a DS named jordikroon.nl), you will get an error, because it is never appropriate for a DS to be placed in the zone apex. If you are trying to delegate to another DNSSEC-signed zone, then you would place a DS (obtained from the delegated zone) at the delegation name (e.g., subdomain.jordikroon.nl), but I don't think that's what you're trying to do here.

Regarding transfer state and deleting DNSSEC keys: You cannot delete the DNSKEYs that the system provides. These don't appear in the API. You can provide your own public (not private) DNSKEYs while in transfer state, and delete them later. But the system-managed DNSKEYs always persist, and are the only ones used to sign the zone. I don't see anything in your zone other than the system-provided keys, so it appears you successfully deleted your user-provided public keys.

I appreciate that you're attempting to test the transfer state. I'm happy to help however I can. It is meant to be used with the "Double-DS" method described in RFC 6781 Appendix D. Here's a quick overview on how it should work (caveat emptor: This is OTTOMH, and may have an omission which breaks your zone. Refer to the RFC.)

1. Put the Cloud DNS zone in "transfer" state.
2. Add the public KSK DNSKEY from the old zone into the Cloud DNS zone.
3. Add the public KSK DNSKEY from the Cloud DNS zone to the old zone. Your old provider must support this.
4. Give the DS (or sometimes the KSK DNSKEY) from the Cloud DNS zone to your registrar. Your registrar should now have two DS records, one for your old zone and one for your Cloud DNS zone. Your zone will break if you delete your old DS record! Make sure you're adding, not overwriting.
5. Wait for all the TTLs for all of the above records to expire (particularly note the TTL on the DS, which you don't control because it is served by your registry).
6. Update the delegation with your registrar to point to the Cloud DNS nameservers for your zone.
7. Wait for the NS TTLs to expire (which, again, you don't control; take the larger of the TTL of the NS records in your zone and the NS glue records at the registry).
8. At your registrar, remove the DS for your old zone. Be careful not to delete the DS record for your Cloud DNS zone, or your zone will break!
9. Wait for the DS TTL to expire (again, you don't control this).
10. Remove the extra DNSKEYs from your Cloud DNS zone that you added before.
11. Put the Cloud DNS zone in "on" state (leaving "transfer" state).

Easy, right? ;) Unfortunately, changing DNS operators while maintaining DNSSEC is one of the trickier things to do. Some users may prefer to disable DNSSEC temporarily and change operators in the conventional manner, but that does put their domain at risk for a period.