How to add CAA record?

Software SW help
,
1

Hi,

I need to add a CAA record to knot resolver for https://lab-ca.net/

I cannot find anything in the GUI. How to add records to knot?

2

Can you explain why you’d add CAA locally? The authoritative servers for that name should add it.

1 Like
3

Well, then who is the authoritative server for home.arpa? That’s the local domain I configured for my internal hostnames. The issuing CA is boulder, running locally on my Proxmox. home.arpa is the domain Knot adds to all my DHCP hostnames, so it should be authoritative for it?

From LabCA documentation:

When issuing a certificate, LabCA/boulder checks for CAA (Certification Authority Authorization) records in DNS, which specify what CAs are allowed to issue certificates for the domain.

The only server in my network who ist able to resolve my home.arpa hostnames is knot.

4

Afaik the absence of a CAA record should not impede the issuance of a certificate.

5

I do receive errors because of a missing CAA entry.

Checked CAA records for labca.home.arpa, [Present: false, Account ID: 1, Challenge: http-01, Valid for issuance: true, Found at: ""] Response=""

So are we not able to add records to knot? Which would be a working alternative DNS server for Omnia then?

6

As far as I know on Turris you only run kresd RESOLVER not fully fledged Knot DNS. But I might be wrong. But thanks for pointing me to LabCA project

Edit: So for this what you want to achieve run your own DNS and point Omnia to use it. Could be Knot DNS and like that you may add whatever records you like.

7

Ok, so I added some configuration to my upstream Unbound:

server:
    local-zone: "home.arpa." static
    local-data: 'home.arpa. 3600 IN CAA 0 issue "jwgn Root CA"'

When I query Unbound directly, I get the record:

root@omnia:~# dig CAA home.arpa @192.168.100.50

; <<>> DiG 9.18.24 <<>> CAA home.arpa @192.168.100.50
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6652
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;home.arpa.                     IN      CAA

;; ANSWER SECTION:
home.arpa.              3600    IN      CAA     0 issue "jwgn Root CA"

;; Query time: 0 msec
;; SERVER: 192.168.100.50#53(192.168.100.50) (UDP)
;; WHEN: Wed Nov 06 20:25:19 CET 2024
;; MSG SIZE  rcvd: 69

But when I query knot, there is no record in the answer:

root@omnia:~# dig CAA home.arpa @127.0.0.1

; <<>> DiG 9.18.24 <<>> CAA home.arpa @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56969
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;home.arpa.                     IN      CAA

;; AUTHORITY SECTION:
home.arpa.              60      IN      SOA     prisoner.iana.org. hostmaster.root-servers.org. 1 604800 60 604800 604800

;; Query time: 430 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Nov 06 20:25:22 CET 2024
;; MSG SIZE  rcvd: 115

Instead, there is some SOA record I never added.

So why does knot not retrieve the CAA record from the upstream server?

8

Because RFCs say that home.arpa shouldn’t be forwarded upstream by default.

I’m not sure about the whole use case. I guess you could create certificates under home.arpa (I haven’t studied standards relevant to that), but given that the name is local by definition, the certificate will also be local by definition (not recognized by normal CAs). So then the purpose of a CAA record is… what? Maybe my brain is tired now anyway.

9

The purpose of all this is just to get valid certificates for my local domains. And a way for my services to automatically obtain and refresh these certificates via ACME.

That means the solution from @AreYouLoco cannot work? The CAA record has to be setup in knot, not in the upstream resolver? But how?

Or can I lift this restriction somehow? Who is responsible for not forwarding the record, knot or Unbound?

11

Knot Resolver. But you’re only adding the Unbound layer because of this? The easiest way of adding CAA in Knot Resolver should be through an RPZ file, I think.

12

No, I use Unbound anyway as knot does not support RFC 8806.

As described here? Query policies — Knot Resolver 5.7.4 documentation

I already have a policy in place to allow home.arpa domain:

policy.add(policy.suffix(policy.PASS, {todname(‘home.arpa.’)}))

What would be the correct syntax for adding the CAA record?

13

While I don’t use boulder myself, I’m still not convinced a CAA record is needed.

If boulder would not issue certfcates to domains without CAA records, presumably Let’s Encrypt would not either, that is clearly not the case.

It looks like Boulder is trying to behave according to the RFCs as much as possible, and where not, its clearly documented. I could not see anything anywhere that said a CAA record is mandatory.

From what I see on GitHub, there are or where issues in handling CAA DNS queries not returning expected answers.

The way I understand it, the validation code in Boulder checks CAA records, it they are ‘not present’, or ‘present but invalid’ or ‘present and valid’. If they are ‘invalid’ and additional error message is logged, in the two otther cases it just moves on.

Could it be, this is was just an informational message and the failure happens later on because of other issues?

1 Like
14

Why not set your unbound as resolver for your Boulder setup?
The Boulder deployment guide event recommends this to avoid public or ISP controlled resolvers:

The VA config has a list of DNS resolvers (dnsResolvers) to use when looking up validation hostnames, TXT records, and CAA records. You’ll want to change this to your own set of authoritative resolvers. Note that DNS is completely critical to certificate validation, so you should ensure these resolvers are controlled by you and have good security settings. For instance, it may be tempting to set these to public resolvers like 8.8.8.8 but this is unwise because (a) you don’t control that resolver, and (b) the network path between your Boulder instance and that resolver may be unsafe.

If your Knot resolver is using an upstream, that would be against their recommendation.

15

Maybe, most likely you are right. But even if it’s just a warning, I want to fix it. And the knowledge of how to add records might be advantageous for future scenarios.

Because Unbound does not know anything about my internal home.arpa domains. It’s just the Upstream resolver for knot, to compensate knot’s missing features.

It’s not. It works as a recursive resolver with a locally cached root zone.