Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: EDNS EXPIRE (RFC 7314) #274

Open
anandb-ripencc opened this issue Mar 30, 2023 · 9 comments
Open

Feature request: EDNS EXPIRE (RFC 7314) #274

anandb-ripencc opened this issue Mar 30, 2023 · 9 comments
Assignees

Comments

@anandb-ripencc
Copy link
Contributor

anandb-ripencc commented Mar 30, 2023

Hi. Long chains of XFR servers can lead to a situation where a zone's expiry is extended well beyond what's in the SOA record. We have recently had this situation with some of our zones, where the secondary kept serving a zone with expired RRSIGs.

Would you consider implementing RFC 7314 in Knot DNS NSD, both when providing XFR as well as requesting XFR, and honouring the expiry from the EDNS EXPIRE option instead of the SOA record?

@anandb-ripencc
Copy link
Contributor Author

I copy+pasted from the same request to the Knot DNS folk... oops, haha.

s/Knot DNS/NSD/ :)

@anandb-ripencc
Copy link
Contributor Author

It turns out that Knot DNS has implemented this since version 3.2. It has been in BIND for even longer. I would love to see this in NSD, so that we can make use of it uniformly. Other than in XFR, it also helps when you issue a SOA query, because you can quickly know how far a zone is from expiry, and could use it as a monitoring aid.

@k0ekk0ek
Copy link
Contributor

k0ekk0ek commented Jun 1, 2023

Hi @anandb-ripencc! I'll start looking into this.

@anandb-ripencc
Copy link
Contributor Author

Hi @k0ekk0ek. Any update on this issue?

@k0ekk0ek
Copy link
Contributor

Hi @anandb-ripencc. I'm sorry, not yet. It got sidetracked. I'll see if I can start work on this again soon (#278, or simdzone, is keeping me busy, but a first release is close).

@k0ekk0ek
Copy link
Contributor

@anandb-ripencc, #278 turned out to take (way) more time. I'm sorry it took so long. I'll get started on this feature later this week.

@k0ekk0ek
Copy link
Contributor

k0ekk0ek commented May 1, 2024

I've been working out how to fit this into NSD. The problem is that the processes serving the data do not keep track of zone administration as that is done by xfrd. The initial idea was to use a shared memory segment containing an expire timer per zone. As multiple versions might be served (current version, plus version after reload), that is not as straightforward as I hoped it'd be. Anyway, just a quick update to indicate this is top of my list.

@anandb-ripencc
Copy link
Contributor Author

Thanks for this update Jeroen. Perhaps you can try to solve this issue in 2 parts. It would already be useful if XFRD were to ask for, and honour the EXPIRE option in XFR queries. This would solve the problem where we have multiple chains of XFR servers, and the zone expiry time is extended beyond the operator's intention. This is my main motivation for wanting EXPIRE support in NSD, because we have actually faced this issue.

Later, you can try to figure out a way of passing on the expiry timer information to the child processes.

@k0ekk0ek
Copy link
Contributor

k0ekk0ek commented May 2, 2024

That's most certainly less complicated, I'll see if I can split it up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants