starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-24 18:55:55 +03:00

[GH-ISSUE #798] Multiple records in single update? #295

New issue

Open

opened 2026-03-07 23:18:40 +03:00 by kerem · 5 comments

kerem commented

2026-03-07 23:18:40 +03:00

Owner

Originally created by @dsvensson on GitHub (Jun 17, 2019).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/798

Seems like it's not possible to combine multiple updates in the same DDNS command. As the function accepts a RecordSet, it ought to be possible, but I can't get it to work.

Something equivalent of the following nsupdate script:

update add test0.foo. 600 txt "a"
update add test1.foo. 600 txt "b"
update add test2.foo. 600 txt "c"
send

nsupdate will send foo. as a SOA record in the zone section (looking at wireshark), followed by the three updates in the same packet.

Originally created by @dsvensson on GitHub (Jun 17, 2019). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/798 Seems like it's not possible to combine multiple updates in the same DDNS command. As the function accepts a RecordSet, it ought to be possible, but I can't get it to work. Something equivalent of the following `nsupdate` script: ``` update add test0.foo. 600 txt "a" update add test1.foo. 600 txt "b" update add test2.foo. 600 txt "c" send ``` `nsupdate` will send `foo.` as a SOA record in the zone section (looking at wireshark), followed by the three updates in the same packet.

kerem added the

enhance

crate:client

has workaround

labels

2026-03-07 23:18:40 +03:00

kerem commented

2026-03-07 23:18:51 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 17, 2019):

If I remember correctly update is restricted to operating over a single label. You can send a record-set, which is a single label with many RDATAs, but you can’t send many record-sets.

It sounds like nsupdate is splitting this into 3 different requests for you for each label. The trust-dns client is pretty dumb, in that you’ll need to perform this split across the different labels manually.

@bluejekyll commented on GitHub (Jun 17, 2019): If I remember correctly update is restricted to operating over a single label. You can send a record-set, which is a single label with many RDATAs, but you can’t send many record-sets. It sounds like nsupdate is splitting this into 3 different requests for you for each label. The trust-dns client is pretty dumb, in that you’ll need to perform this split across the different labels manually.

kerem commented

2026-03-07 23:18:56 +03:00

Author

Owner

@dsvensson commented on GitHub (Jun 17, 2019):

No, nsupdate does not split it. As observed in wireshark, it's in the same DNS packet, which is a great way of reducing overhead when performing a huge number of updates.

@dsvensson commented on GitHub (Jun 17, 2019): No, nsupdate does _not_ split it. As observed in wireshark, it's in the same DNS packet, which is a great way of reducing overhead when performing a huge number of updates.

kerem commented

2026-03-07 23:19:01 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 17, 2019):

Ah, I misread your comment.

I’d need to go back and read the 2136 RFC. If we want to support this in trust-dns it would need to be added. The interface would be a little awkward for some of the conditional replacement functions...

@bluejekyll commented on GitHub (Jun 17, 2019): Ah, I misread your comment. I’d need to go back and read the 2136 RFC. If we want to support this in trust-dns it would need to be added. The interface would be a little awkward for some of the conditional replacement functions...

kerem commented

2026-03-07 23:19:06 +03:00

Author

Owner

@dsvensson commented on GitHub (Jun 17, 2019):

Yeah, perhaps better to just craft the message and send it separately, which should be possible right? Haven't come to send() yet.

@dsvensson commented on GitHub (Jun 17, 2019): Yeah, perhaps better to just craft the message and send it separately, which should be possible right? Haven't come to send() yet.

kerem commented

2026-03-07 23:19:12 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 17, 2019):

Ok, yeah. Trust-dns is more restrictive than the rfc requires: https://tools.ietf.org/html/rfc2136

If we want/need this, I think we’ll need a more complex api for it. It would need to expose the prerequisites section, and the update sections, separately. We’d probably want to build functions for generating the proper record-sets for each of those sections as well.

But yes, I don’t think the client supports this directly right now. You could create the message manually for now and not use the higher level api the client provides.

@bluejekyll commented on GitHub (Jun 17, 2019): Ok, yeah. Trust-dns is more restrictive than the rfc requires: https://tools.ietf.org/html/rfc2136 If we want/need this, I think we’ll need a more complex api for it. It would need to expose the prerequisites section, and the update sections, separately. We’d probably want to build functions for generating the proper record-sets for each of those sections as well. But yes, I don’t think the client supports this directly right now. You could create the message manually for now and not use the higher level api the client provides.

kerem referenced this issue

2026-03-15 22:27:38 +03:00

[GH-ISSUE #295] doesn't work with futures 0.1.13 #432

kerem referenced this issue

2026-03-16 02:01:53 +03:00

[PR #297] [MERGED] update futures to 0.1.17 #1351