[PR #2419] [MERGED] Encode and decode CAA issuer name as ASCII only #3028

New issue

Closed

opened 2026-03-16 11:21:13 +03:00 by kerem · 0 comments

kerem commented

2026-03-16 11:21:13 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/hickory-dns/hickory-dns/pull/2419
Author: @divergentdave
Created: 9/4/2024
Status: ✅ Merged
Merged: 9/5/2024
Merged by: @djc

Base: main ← Head: david/caa-issuer-name-ascii

📝 Commits (1)

45cae16 Encode and decode CAA issuer name as ASCII only

📊 Changes

1 file changed (+25 additions, -2 deletions)

View changed files

📝 crates/proto/src/rr/rdata/caa.rs (+25 -2)

📄 Description

This changes CAA issuer name encoding and decoding to use LabelEncAscii instead of LabelEncUtf8. This allows a couple more characters than the "LDH-Label form" that RFC 8659 prescribes (underscore and asterisk), but it's a lot closer.

This closes #2353 as it fixes the last round-trip failure identified. A minimal reproducer unit test is included. The cause was a bit different than I previously diagnosed, now that I have manually reduced the input. A non-ASCII Unicode character in the label is a prerequisite, because this causes the label to be round-tripped through punycode internally when it's stored as a Label. The IDNA code path for encoding a name to UTF-8 doesn't escape the . characters that were decoded from \. in the input, while Label::write_ascii() does.

The IDNA mapping table says that . is a "valid" code point, but on the other hand, UTS #46 says in its validity criteria that labels must not contain it. The idna crate's to_unicode() method, used in impl Display for Label, is intended for operating on a whole domain at a time, not a label at a time, so it splits the input it receives on dots, applies the validation rules to its view of the labels, and then re-joins them with dots. Separately, it might make sense to add an extra step to the IDNA-to-UTF-8 encoding codepath to encode dots.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/hickory-dns/hickory-dns/pull/2419 **Author:** [@divergentdave](https://github.com/divergentdave) **Created:** 9/4/2024 **Status:** ✅ Merged **Merged:** 9/5/2024 **Merged by:** [@djc](https://github.com/djc) **Base:** `main` ← **Head:** `david/caa-issuer-name-ascii` --- ### 📝 Commits (1) - [`45cae16`](https://github.com/hickory-dns/hickory-dns/commit/45cae164985a5b4476e39e0c99810496aff33621) Encode and decode CAA issuer name as ASCII only ### 📊 Changes **1 file changed** (+25 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `crates/proto/src/rr/rdata/caa.rs` (+25 -2) </details> ### 📄 Description This changes CAA issuer name encoding and decoding to use `LabelEncAscii` instead of `LabelEncUtf8`. This allows a couple more characters than the "LDH-Label form" that RFC 8659 prescribes (underscore and asterisk), but it's a lot closer. This closes #2353 as it fixes the last round-trip failure identified. A minimal reproducer unit test is included. The cause was a bit different than I previously diagnosed, now that I have manually reduced the input. A non-ASCII Unicode character in the label is a prerequisite, because this causes the label to be round-tripped through punycode internally when it's stored as a `Label`. The IDNA code path for encoding a name to UTF-8 doesn't escape the `.` characters that were decoded from `\.` in the input, while `Label::write_ascii()` does. The IDNA mapping table says that `.` is a "valid" code point, but on the other hand, UTS #46 says in its validity criteria that labels must not contain it. The `idna` crate's `to_unicode()` method, used in `impl Display for Label`, is intended for operating on a whole domain at a time, not a label at a time, so it splits the input it receives on dots, applies the validation rules to its view of the labels, and then re-joins them with dots. Separately, it might make sense to add an extra step to the IDNA-to-UTF-8 encoding codepath to encode dots. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>