Skip to content

BUGFIX: Make OPENPGPKEY records functional.#4139

Open
gucci-on-fleek wants to merge 2 commits intoStackExchange:mainfrom
gucci-on-fleek:openpgpkey
Open

BUGFIX: Make OPENPGPKEY records functional.#4139
gucci-on-fleek wants to merge 2 commits intoStackExchange:mainfrom
gucci-on-fleek:openpgpkey

Conversation

@gucci-on-fleek
Copy link
Contributor

I'm unable to get DNSControl to create an OPENPGPKEY record that gpg or openpgpkey will 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, both gpg and openpgpkey accept the OPENPGPKEY record 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 OPENPGPKEY documentation, and fixed a small bug with the --debug argument. Full commit messages:


BUGFIX: Make OPENPGPKEY records functional.

Previously, #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.


BUGFIX: Make --debug not print the version.

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.

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.
tlimoncelli
tlimoncelli previously approved these changes Mar 8, 2026
Copy link
Collaborator

@tlimoncelli tlimoncelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants