@jpmens I moved all my zones over there and manage it using DNSControl. Really like it! https://tobru.ch/authoritative-dns-with-desec-and-dns-control/
@tobru interesting read (and I’ll have to read it again), thanks. I glanced at DNSControl recently when I looked at OctoDNS a bit more closely (https://jpmens.net/2025/02/22/notes-to-self-on-octodns-and-its-providers/). I like that it appears to be of good quality, but the JavaScript-type configuration gives me nightmares. ;) Really, that is one thing I would really need to get used to, and I’m not sure I could.
@jpmens
a quick addition as I skipped through the text: If you add/modify a DNS entry of your zone via the dyndns API you can use it as your own private dyndns, the entry automagically gets a TTL of 60 instead of 3600. Using that is pretty handy :)
Also they helped implement a way to update only one address of a DS entry (e.g. my IPv6 is static as it's a HE test tunnel endpoint whereas my IPv4 is effin changing every day). So I can update v4 without deleting or changing v6. Great job :)
@JeGr thanks for the 1st paragraph; sounds good, and I’ll see if I can reproduce that (though I don’t actually use dyndns).
As to the second paragraph: no comprendo “one address of a DS”; are you sure you’ve got the correct RR type? ;)
@JeGr blog updated with mention of TTL 60 for dyndns; thank you.
@jpmens Ah sorry - bad typing brain today ;)
DS as in dual stack entry. I have a record for a testWAN like test.domain.tld that I wanted to use as DynDns for some VPN tests. IP6 is static from a HEnet tunnel so doesn't need to change, IP4 is damned DSL daily disconnect BS. So needed a way to only change IP4 but leave IP6 alone. The API didn't have that, but after mailing Peter & a Github issue they patched it in via their update URI as a Post param. that can be set. Very nice team & effort! :)
@jpmens
See: https://desec.readthedocs.io/en/latest/dyndns/update-api.html#determine-ip-address-es
the "preserve" parameter is what I've been talking about. That way my poor lab router can update the entry correctly as it was limited to either update v4 or v6 IPs (the software can't handle updating both at the same time). And in some cases that can actually be helpful to split it into two updates.
Was only possible by them being so supportive once the use case was clear. Corner case for others, but I'm now happily donating them :)
@jpmens Hmm... this might be good enough for me to consider shutting down my own public auth servers 
I took a quick look on their site but didn't see any information about hosting a 'frontend server' for them, which I'd want to do (in Canada, not in the US) if I used the service.
@kevin Their service is impressive and everything just seems to work. Also response from Peter T. (inventor extraordinaire) is timely and very good.
What I'd do if i were you is send a proposal/suggestion/offer to support()desec.io
@jpmens Is there a list for which TLDs they support DNSSEC? Or would one have to cross reference the list of supported algorithms with a list like this? https://support.openprovider.eu/hc/en-us/articles/216648838-List-of-TLDs-that-support-DNSSEC
@agowa338 I'm not aware of them not having support for specific TLDs; they will add your zone and sign it (with algorithms=13 (ECDSAP256SHA256))
Whether or not the TLD you choose is signed or not (and thus will cause your domain to validate) is a quite different kettle of fish.
If you have dig(1) installed you can query your TLD, e.g. for COM it would be
dig @1.1.1.1 com DNSKEY +nocrypto
If you get an ANSWER section you should be good to go. (Or ask me to check if you prefer. )
@jpmens If they only support algorithm 13 then they don't work with a bunch of tlds. See the link in my former post. Not every TLD that supports DNSSEC also has algorithm 13.
Why I ask is because I've currently a .de domain at NameCheap and they just don't support DNSSEC for .de domains. They never provided a reason (besides claiming the de-TLD itself wouldn't support DNSSEC, even though it does). I suspect the real reason is either politics or the algorithms
@jpmens Using your command it looks like the list in my first post is also outdated by now, as for the de-TLD it shows that only algorithm 3 is supported right now.
Edit: Ups your command checks for the DNSKEY and not the DS record. Quering the right record however also shows that de-TLDs by now only support a single algorithm. However it's 8 and not 3 as i at first thought.
@agowa338 no, that's not quite right.
the (3) you mention is the protocol field and means DNSSEC (there is no other protocol there).
More interesting is the (8) next to it: that's the algorithm (RSASHA256) for THEIR (i.e. .DE's) keys.
Just because .DE signs with algorithms 8 does not mean you cannot have a zone signed with algorithm 13.
In fact, dns-xfr.de (registered just for the demo for the blog post) is algo 13:
The AD flag means it validates.
In short: no problems for a .DE zone
@agowa338 I hope my last toot clarifies on this.
Your .DE domain will work perfectly after getting it set up at deSEC, provided you then ensure that your public DNSKEY is submitted to DeNIC via your registry.
@jpmens My registry for that domain currently is also Namecheap, so that's probably where it breaks down then. Do you by change know if the de-TLD (and also the eu-TLD) have some shitty API for submitting this compared to e.g. the FYI and info TLDs?
@agowa338 de-TLD doesn't, and eu-TLD I don't know.
BTW, what you could do if you want to invest the bit of effort, is to transfer out of Namecheap to, say, an EU-based shop. One that comes to mind is https://www.inwx.de/de You'll want to look for "Providerwechsel" (https://kb.inwx.com/en-us/16-transfer/10-how-can-i-transfer-a-domain-to-inwx)
@agowa338 Peter T. (of deSEC) reminds me I should probably have mentioned that DE and EU expect a public DNSKEY record and not a DS; from the former they generate the DS they need.
Note, please, DNSKEY is the public key; the private key, used e.g. by deSEC's servers to sign DNS data, is (very rightly!) not available to us.
@jpmens yea, maybe should consider moving them somewhere else anyway. However don't know if it'll be inwx in the end or something else. However that's nothing I'll be doing ad-hoc.