starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #516] Please add support for the new CAA "validation-methods" + "account-uri" parameters #219

New issue

Closed

opened 2026-03-07 22:50:53 +03:00 by kerem · 14 comments

kerem commented

2026-03-07 22:50:53 +03:00

Owner

Originally created by @Darkspirit on GitHub (Jun 19, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/516

https://community.letsencrypt.org/t/acme-caa-validation-methods-support/63125
https://tools.ietf.org/html/draft-ietf-acme-caa-04

The parameter value is a comma-separated string:
@ CAA 0 issue "letsencrypt.org; validation-methods=dns-01,http-01"

A CA would have to abort if it doesn't support validation-methods:
@ CAA 128 issue "letsencrypt.org; validation-methods=dns-01"

I find the backslash ("letsencrypt.org\; validation-methods=dns-01") in the forum post confusing, maybe because I never used bind?

Current error:

1529411380.946177:ERROR:named:406:could not load zone dev.terrax.net.: error reading zone: "/home/trustdns/dev.terrax.net.zone": proto error

The following non-standard line is accepted by TRust-DNS because it does not contain hyphens or a comma:
@ CAA 0 issue "letsencrypt.org; validationmethods=dns01"

Originally created by @Darkspirit on GitHub (Jun 19, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/516 https://community.letsencrypt.org/t/acme-caa-validation-methods-support/63125 https://tools.ietf.org/html/draft-ietf-acme-caa-04 The parameter value is a comma-separated string: `@ CAA 0 issue "letsencrypt.org; validation-methods=dns-01,http-01"` A CA would have to abort if it doesn't support validation-methods: `@ CAA 128 issue "letsencrypt.org; validation-methods=dns-01"` I find the backslash (`"letsencrypt.org\; validation-methods=dns-01"`) in the forum post confusing, maybe because I never used bind? Current error: > 1529411380.946177:ERROR:named:406:could not load zone dev.terrax.net.: error reading zone: "/home/trustdns/dev.terrax.net.zone": proto error The following non-standard line is accepted by TRust-DNS because it does not contain hyphens or a comma: `@ CAA 0 issue "letsencrypt.org; validationmethods=dns01"`

kerem

2026-03-07 22:50:53 +03:00

closed this issue
added the
enhance

crate:proto
labels

kerem commented

2026-03-07 22:51:09 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 19, 2018):

Thanks for the report.

@bluejekyll commented on GitHub (Jun 19, 2018): Thanks for the report.

kerem commented

2026-03-07 22:51:14 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 19, 2018):

Ok. Looks like the parsers in https://github.com/bluejekyll/trust-dns/blob/master/proto/src/rr/rdata/caa.rs

For the name field is too strict, we’ll need to review the name field restrictions in the RFC and allow for some additional special characters.

@bluejekyll commented on GitHub (Jun 19, 2018): Ok. Looks like the parsers in https://github.com/bluejekyll/trust-dns/blob/master/proto/src/rr/rdata/caa.rs For the name field is too strict, we’ll need to review the name field restrictions in the RFC and allow for some additional special characters.

kerem commented

2026-03-07 22:51:20 +03:00

Author

Owner

@Darkspirit commented on GitHub (Jun 19, 2018):

https://community.letsencrypt.org/t/caa-validation-methods-invalid-format/63804/2

@Darkspirit commented on GitHub (Jun 19, 2018): https://community.letsencrypt.org/t/caa-validation-methods-invalid-format/63804/2

kerem commented

2026-03-07 22:51:25 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 19, 2018):

Gotta love the RFC process. ;)

@bluejekyll commented on GitHub (Jun 19, 2018): Gotta love the RFC process. ;)

kerem commented

2026-03-07 22:51:30 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 21, 2018):

The new RFC doesn't even mention the new parsing changes. Which implies to me that they did the wrong thing by introducing - in keys of the issuer. I'll allow - in the key name, but this will allow non-compliant keys to be introduced in these fields...

@bluejekyll commented on GitHub (Jun 21, 2018): The new RFC doesn't even mention the new parsing changes. Which implies to me that they did the wrong thing by introducing `-` in keys of the issuer. I'll allow `-` in the key name, but this will allow non-compliant keys to be introduced in these fields...

kerem commented

2026-03-07 22:51:35 +03:00

Author

Owner

@Darkspirit commented on GitHub (Jun 21, 2018):

https://github.com/hardenize/hardenize-public/issues/33

Relevant thread: https://www.ietf.org/mail-archive/web/acme/current/msg02785.html

Let's Encrypt still has it in staging, not production. Maybe it was good to ask around what should be done now, maybe they find a better solution?

@Darkspirit commented on GitHub (Jun 21, 2018): https://github.com/hardenize/hardenize-public/issues/33 > Relevant thread: https://www.ietf.org/mail-archive/web/acme/current/msg02785.html Let's Encrypt still has it in staging, not production. Maybe it was good to ask around what should be done now, maybe they find a better solution?

kerem commented

2026-03-07 22:51:40 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 21, 2018):

ok #517 has the fix, this test case should validate these options:

github.com/bluejekyll/trust-dns@7315ae1644/proto/src/rr/rdata/caa.rs (L915-L930)

@bluejekyll commented on GitHub (Jun 21, 2018): ok #517 has the fix, this test case should validate these options: https://github.com/bluejekyll/trust-dns/blob/7315ae1644933d226923a93c30dd0459f775fe8e/proto/src/rr/rdata/caa.rs#L915-L930

kerem commented

2026-03-07 22:51:45 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 21, 2018):

Maybe it was good to ask around what should be done now, maybe they find a better solution?

I think it's clear that discussion is already happening. Anyone that strictly implemented the original RFC6844 will also need to upgrade and patch their software, so I suspect they'll want to support something without these additions.

@bluejekyll commented on GitHub (Jun 21, 2018): > Maybe it was good to ask around what should be done now, maybe they find a better solution? I think it's clear that discussion is already happening. Anyone that strictly implemented the original RFC6844 will also need to upgrade and patch their software, so I suspect they'll want to support something without these additions.

kerem commented

2026-03-07 22:51:50 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 21, 2018):

@Darkspirit, I think that #517 is good, not sure if you want to test it before I merge into master.

@bluejekyll commented on GitHub (Jun 21, 2018): @Darkspirit, I think that #517 is good, not sure if you want to test it before I merge into master.

kerem commented

2026-03-07 22:51:55 +03:00

Author

Owner

@Darkspirit commented on GitHub (Jun 21, 2018):

@Darkspirit, I think that #517 is good, not sure if you want to test it before I merge into master.

Thank you! But I don't want to ask you to merge something unstable you might be uncomfortable with, and which could be fixed, since this is still in staging and got attention from some more people now.

https://www.ietf.org/mail-archive/web/acme/current/threads.html#02785
(It sounds like they'd ask to fix it by removing hyphens from labels but keeping them in values?)

@Darkspirit commented on GitHub (Jun 21, 2018): > @Darkspirit, I think that #517 is good, not sure if you want to test it before I merge into master. Thank you! But I don't want to ask you to merge something unstable you might be uncomfortable with, and which could be fixed, since this is still in staging and got attention from some more people now. https://www.ietf.org/mail-archive/web/acme/current/threads.html#02785 (It sounds like they'd ask to fix it by removing hyphens from labels but keeping them in values?)

kerem commented

2026-03-07 22:52:00 +03:00

Author

Owner

@Darkspirit commented on GitHub (Jun 21, 2018):

test it

PowerDNS and TRust-DNS now behave the same.

@Darkspirit commented on GitHub (Jun 21, 2018): > test it [PowerDNS](https://www.hardenize.com/report/terrax.net/1529597993#domain_caa) and [TRust-DNS](https://www.hardenize.com/report/dev.terrax.net/1529597672#domain_caa) now behave the same.

kerem commented

2026-03-07 22:52:06 +03:00

Author

Owner

@Darkspirit commented on GitHub (Jun 21, 2018):

It has been fixed:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-acme-caa-05.txt
https://github.com/letsencrypt/boulder/pull/3772/files

@Darkspirit commented on GitHub (Jun 21, 2018): It has been fixed: https://tools.ietf.org/rfcdiff?url2=draft-ietf-acme-caa-05.txt https://github.com/letsencrypt/boulder/pull/3772/files

kerem commented

2026-03-07 22:52:11 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 21, 2018):

So I think that at least part of the PR is still needed as the value field was too strict before and didn’t support the url characters.

I think I might just allow the -... I’ll think about it.

@bluejekyll commented on GitHub (Jun 21, 2018): So I think that at least part of the PR is still needed as the value field was too strict before and didn’t support the url characters. I think I might just allow the `-`... I’ll think about it.

kerem commented

2026-03-07 22:52:16 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 22, 2018):

Ok, merging this in.

@bluejekyll commented on GitHub (Jun 22, 2018): Ok, merging this in.

kerem referenced this issue

2026-03-15 22:18:29 +03:00

[GH-ISSUE #219] Run deckard test suite #399