BUGFIX: Make OPENPGPKEY records functional.#4139
Open
gucci-on-fleek wants to merge 2 commits intoStackExchange:mainfrom
Open
BUGFIX: Make OPENPGPKEY records functional.#4139gucci-on-fleek wants to merge 2 commits intoStackExchange:mainfrom
OPENPGPKEY records functional.#4139gucci-on-fleek wants to merge 2 commits intoStackExchange:mainfrom
Conversation
Previously, StackExchange#3718 introduced support for `OPENPGPKEY` records. However, that PR assumed that the `OPENPGPKEY` key data was hex-encoded. [RFC 7929 §2.3] states that when in "Presentation Format", `OPENPGPKEY` record data must be base64-encoded instead. Since most hex-encoded data can be parsed as base64, DNS providers would not reject a hex-encoded key, but they would instead parse it as base64, leading to a corrupt result. Additionally, the previous PR also unconditionally lower-cased the key data, making it impossible to use base64-encoded keys. Once again, lowercased base64-encoded data can usually be parsed as base64, but the result will be corrupted. This current PR fixes both of these issues by instead treating the key as base64-encoded data, and by no longer lower-casing the key data. To maintain backwards compatibility with existing hex-encoded keys, the code attempts to detect keys that appear to be hex-encoded, and decodes them as hex before re-encoding them as base64. [RFC 7929 §2.3]: https://datatracker.ietf.org/doc/html/rfc7929#section-2.3
Currently, using the `--debug` command-line argument just prints the DNSControl version and exits. This is because the long option `--debug` is mapped to the short option `-v`, but `-v` is used for `--version`, so the parser gets confused. This commit remaps the long option `--version` to the short option `-V`, which prevents the parser from getting confused and makes `--debug` work again.
b068798 to
5179a4c
Compare
tlimoncelli
previously approved these changes
Mar 8, 2026
tlimoncelli
reviewed
Mar 8, 2026
Collaborator
tlimoncelli
left a comment
There was a problem hiding this comment.
Hello friend!
Thanks for spotting this and making a PR to fix it.
The new encoding makes a test fail. Can you please take a look at this?
$ cd ~/git/dnscontrol/pkg/js
$ go test ./...
# Test 056 fails. The actual results are in parse_tests/056-openpgpkey.json.ACTUAL
# If they are correct...
$ cp parse_tests/056-openpgpkey.json.ACTUAL parse_tests/056-openpgpkey.json
$ cd ../..
$ bin/generate-all.sh
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I'm unable to get DNSControl to create an
OPENPGPKEYrecord thatgpgoropenpgpkeywill accept. From what I can tell, it looks like DNSControl always corrupts or misinterprets the input, meaning that there is no possible input that will produce a valid result. But if I build DNSControl with this PR applied, bothgpgandopenpgpkeyaccept theOPENPGPKEYrecord without any complaints.I'm probably just misunderstanding something though, since I wouldn't expect for the current code to not work at all.
I've also expanded the
OPENPGPKEYdocumentation, and fixed a small bug with the--debugargument. Full commit messages:BUGFIX: Make
OPENPGPKEYrecords functional.Previously, #3718 introduced support for
OPENPGPKEYrecords. However, that PR assumed that theOPENPGPKEYkey data was hex-encoded. RFC 7929 §2.3 states that when in "Presentation Format",OPENPGPKEYrecord data must be base64-encoded instead. Since most hex-encoded data can be parsed as base64, DNS providers would not reject a hex-encoded key, but they would instead parse it as base64, leading to a corrupt result.Additionally, the previous PR also unconditionally lower-cased the key data, making it impossible to use base64-encoded keys. Once again, lowercased base64-encoded data can usually be parsed as base64, but the result will be corrupted.
This current PR fixes both of these issues by instead treating the key as base64-encoded data, and by no longer lower-casing the key data. To maintain backwards compatibility with existing hex-encoded keys, the code attempts to detect keys that appear to be hex-encoded, and decodes them as hex before re-encoding them as base64.
BUGFIX: Make
--debugnot print the version.Currently, using the
--debugcommand-line argument just prints the DNSControl version and exits. This is because the long option--debugis mapped to the short option-v, but-vis used for--version, so the parser gets confused. This commit remaps the long option--versionto the short option-V, which prevents the parser from getting confused and makes--debugwork again.