RFC2136

[ryphon]

Hey there,

I don't actually run DNS in the cloud, but I do have DNS servers that support RFC2136 and work with external-dns now. I like the idea of having dedicated CRDs for my DNS rather than relying on magic annotations, but I want to support the providers that support RFC2136 as a standard.

Thanks, Dylan

https://datatracker.ietf.org/doc/html/rfc2136

[ainsey11]

@pier-oliviert I'm happy to take this one on as a project once I've got my logging code into a better place if you'd like me to? I too have this requirement (running a bind9 cluster at home) and it's the final thing for me to give external-dns the boot

[pier-oliviert]

@ainsey11 By all means! I started looking at this earlier today but I had to check other things. The only thing really that I'm not set on, is. how much work/changes are required to make Phonebook support RFC2136.

Basically the questions I have regarding the implementation is:

• Are there any fundamental changes to how Phonebook operates now that needs to happen?
• Will it require inbound connection (Like be a server of some sort)?
• Can it/Should it be isolated from the main controller?

Depending on how big the changes are, it might be better to try to split the work in a few PRs so each of the changes can be worked in isolation.

A quick look at external-dns' implementation makes me think it handle DNS changes from outside requests. For security purposes, it means that this server will need to be its own deployment with a different service account and less privileges.

I'm not saying I don't want to implement this, I just want to make sure I understand what we're building :)

[ainsey11]

@pier-oliviert it certainly won't be easy, I think we'll need to start off small and sensible first, ie not going down the rabbit warren of GSS-TSIG

From what I can tell, it shouldn't require any inbound connection into phonebook, I certainly don't have any provisioned for external-dns on my home K8s cluster

Ideally, I'd like to implement it in the same structure as the providers, just as a "generic" provider, with variables for the host/port/secret like we do for the others

The code in external-dns's implementation looks fairly straight forward, with no real craziness in it, 90% of it is crafting the right packets to send to the DNS server itself, in a format that the server will accept as a dynamic update into itself

I'll do some more research and PoC before I go too strong into it, just to make sure we're on the same page and happy with what we're adding in

[pier-oliviert]

Oh wow, I completely read the RFC/code backward, I thought it was receiving DNS packet, not sending. But yeah, I like your approach and looking forward to seeing it take shape.

[ainsey11]

@ryphon can I just ask if you'd need the RFC2136 provider to be able to send the DNS updates to multiple DNS servers or a single one?

Normally if you have multiple servers covering a TLD, they would replicate the zone change between them, rather than the application needing to know about every DNS server for that TLD, so my head is saying it only needs to support one endpoint, but wanted to reach out to check first

Edit - external-dns only supports 1 host so I feel we should probably stick to the same

[ryphon]

Personally just one. For my use case, just a simple RFC2136 compliant DNS server that serves my local zone. For the 'external' dns, I'm just using tunnels like cloudflared or something, so those dns updates are rare. It's the internal dns that may change consistently that I would want to be CRD'd.

Agree on your edit, it keeps complexity quite a bit lower too.

[ainsey11]

Still very early days, but I have a working PoC RFC2136 DNS Creation provider working:

At the moment it only works with insecure updates (because was the fastest way to test some basic logic), and creates Deletes/Updates and secure updates not implemented just yet

I also need to juggle some of the code around as wary that it's not the prettiest, but I feel like I'm getting somewhere positive at least

Updates can be seen on this branch: https://github.com/pier-oliviert/phonebook/tree/RFC2136