[GH-ISSUE #1712] How do I implement a programmatical update/insert + sign of the records? #744

Open
opened 2026-03-16 00:06:57 +03:00 by kerem · 4 comments
Owner

Originally created by @dRAT3 on GitHub (May 25, 2022).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1712

I would like to update the dns-records and re-sign the zones/records programmatically, i.e. no sig0 request but from inside the server/program itself. I've looked a bit at the code, but can't figure out how to do it safely? Any push in the right direction?

Originally created by @dRAT3 on GitHub (May 25, 2022). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1712 I would like to update the dns-records and re-sign the zones/records programmatically, i.e. no sig0 request but from inside the server/program itself. I've looked a bit at the code, but can't figure out how to do it safely? Any push in the right direction?
Author
Owner

@bluejekyll commented on GitHub (May 26, 2022):

I think some of the way that this works today is worth revisiting. But you can look at this method as an example for how a zone is resigned in the InMemoryAuthority: github.com/bluejekyll/trust-dns@df82c60b34/crates/server/src/store/in_memory/authority.rs (L651)

<!-- gh-comment-id:1138083573 --> @bluejekyll commented on GitHub (May 26, 2022): I think some of the way that this works today is worth revisiting. But you can look at this method as an example for how a zone is resigned in the `InMemoryAuthority`: https://github.com/bluejekyll/trust-dns/blob/df82c60b341115e5b9117959cd022d5172461377/crates/server/src/store/in_memory/authority.rs#L651
Author
Owner

@dRAT3 commented on GitHub (May 27, 2022):

Okay thanks for your quick reply.. So how i understand it is I should self.find() in the catalog, retrieve the AuthorityObject then call authority.upsert() and then call secure_zone_mut() correct?

Now my second question is, if I have a subdomain with a bunch of sub-subdomains how can I make sure each subdomain has it's own zone so signing doesn't need to sign the whole domain only the current subdomain. For example i have en.domain.com, fr.domain.com, it.domain.com and so on. All domains have 100 sub-subdomains each. Now I want to change subsubdomain1.fr.domain.com's A and AAAA records and sign the zone. Without having to sign all the records on all the subdomains. How do I keep them all in separate zones? Preferably I would like to only sign subsubdomain1 instead of the whole subdomain. Is this possible? How would one go about it?

I will be upserting records in rapid tempo and don't want to overload the server. Sorry I'm new to DNS and rust but would like to learn.

<!-- gh-comment-id:1139748818 --> @dRAT3 commented on GitHub (May 27, 2022): Okay thanks for your quick reply.. So how i understand it is I should `self.find()` in the catalog, retrieve the `AuthorityObject` then call `authority.upsert()` and then call `secure_zone_mut()` correct? Now my second question is, if I have a subdomain with a bunch of sub-subdomains how can I make sure each subdomain has it's own zone so signing doesn't need to sign the whole domain only the current subdomain. For example i have en.domain.com, fr.domain.com, it.domain.com and so on. All domains have 100 sub-subdomains each. Now I want to change subsubdomain1.fr.domain.com's A and AAAA records and sign the zone. Without having to sign all the records on all the subdomains. How do I keep them all in separate zones? Preferably I would like to only sign subsubdomain1 instead of the whole subdomain. Is this possible? How would one go about it? I will be upserting records in rapid tempo and don't want to overload the server. Sorry I'm new to DNS and rust but would like to learn.
Author
Owner

@bluejekyll commented on GitHub (Jun 6, 2022):

hm, the DNSSEC implementation in trust-dns might not be ideal for what you're describing. I think what we need for a rapidly changing zone is more of an online signing model, where the NSEC records are generated at runtime rather than today's function.

But to answer your question, you'd create a new zone for each of those subzones. The primary zone would contain NS records to the subzones.

<!-- gh-comment-id:1147622525 --> @bluejekyll commented on GitHub (Jun 6, 2022): hm, the DNSSEC implementation in trust-dns might not be ideal for what you're describing. I think what we need for a rapidly changing zone is more of an online signing model, where the NSEC records are generated at runtime rather than today's function. But to answer your question, you'd create a new zone for each of those subzones. The primary zone would contain NS records to the subzones.
Author
Owner

@thedeadliestcatch commented on GitHub (Oct 8, 2024):

Even if this is a very niche use case, I would really like to see a standalone example of this. :-)

<!-- gh-comment-id:2399572536 --> @thedeadliestcatch commented on GitHub (Oct 8, 2024): Even if this is a very niche use case, I would really like to see a standalone example of this. :-)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/hickory-dns#744
No description provided.