Hi all,
we are using dynamic updates for solving ACME challenges. My goal is to
restrict the key used for this as much as possible. However, I find it a
bit difficult to do so while keeping the required flexibility. Maybe
someone has some good recommendations for this?
The key is already restricted to TXT records, so that's good.
In a nutshell, I'd like to allow only "_acme-challenge.example.com" and
"_acme-challenge.*.example.com". However, the latter cannot be expressed
in the current config format.
I would be fine allowing "*.example.com", if I could just deny a select
few names (SPF, DKIM). But AFAICT, the "deny" option only works on
action, key, and address, now owner matching. Is there any other way to
achieve something like this?
Thanks a lot,
Conrad
Hi,
I do have the following example zone files definitions:
$ORIGIN example.tld.
$INCLUDE ___TTL_SOA___
and so on
My ___TTL_SOA___ looks as follows:
$TTL 30m ; default expiration time of all resource records without their own TTL value
;
@ IN SOA ns1.example.tld. hostmaster.example.tld. (
2024042100 ; serial (increase after each change)
4h ; refresh (recommended >= 4h)
1h ; retry (recommended >= 1h)
14d ; expire (recommended between 7d and 14d)
600 ; negative caching (former minimum, recommended between 5m and 1d)
)
Note: All of my subsequent $INCLUDDE files do *not* have TTL values set explicitly!
But: I do end up in a mix of TTL values of 1800 and 3600 for my resource records. You can check that using my domain in my email address.
I found the following thread about this issue at https://gitlab.nic.cz/knot/knot-dns/-/issues/751 and https://datatracker.ietf.org/doc/html/rfc2308#section-4 cited therein:
"All resource records appearing after the directive, and which do not explicitly include a TTL value, have their TTL set to the TTL given in the $TTL directive."
In my understanding Knot's behaviour has been set to follow this standard track. Thus, I do expect that all of my resource records should have a TTL set to my $TTL directive of 1800 seconds.
I might have well overlooked something, though.
Any feedback is highly appreciated,
Michael
as yaml seems to vary widely, i worry that i may have over-induced knot
yaml re address lists, see
https://www.knot-dns.cz/docs/3.3/singlehtml/index.html#description
remote:
- id: foo
address: 1.2.3.4
address: 2.3.4.5
address: 3.4.5.6
address: 6.7.8.9
is said to be the same as
remote:
- id: bar
address: [1.2.3.4, 2.3.4.5, 3.4.5.6, 6.7.8.9]
but is it also the same as
remote:
- id: feen
address: [1.2.3.4, 2.3.4.5]
address: [3.4.5.6, 6.7.8.9]
feen does not result in a `knotc conf-check` syntax error, so i hope it
is indeed equivalent.
randy
Hi,
is there a functionality that identifies orphaned key in the kasp database and optionally deletes those?
I had had a couple of orphaned pem files. I managed to identify and remove those with the help of 'keymgr' and Unix little helpers, though.
Thus I am asking just out of curiosity, because I might have missed such a functionality.
Thanks and regards,
Michael
knot fails to keep this zone updated. so i tested by hand
```
rip.psg.com:/home/randy# dig f.e.e.b.d.a.e.d.1.3.0.0.8.9.8.0.2.0.a.2.ip6.arpa @94.142.241.91 axfr
; <<>> DiG 9.18.24-1-Debian <<>> f.e.e.b.d.a.e.d.1.3.0.0.8.9.8.0.2.0.a.2.ip6.arpa @94.142.241.91 axfr
;; global options: +cmd
;; Warning: cannot represent 'xn--center-dla.test.globnix.net.' in the current localedig: Cannot represent 'xn--ls8h.test.globnix.net.' in the current locale nor ascii (string contains a disallowed character), use +noidnout or a different locale
```
`+noidnout` does fix it, but i am not sure i can get knot's axfr to do
that
the owner of the primary says
Okay, this is the zone with a whole bunch of records designed to
stress-test DNS implementations with things which are technically
allowed in DNS at the protocol level but which apps might not handle
well.
Zonefile top comment:
; This is the /80 reverse DNS used for test entries which should never be
; assigned to hosts. This is </48-prefix>:DEAD:BEEF::/80
Those particular records were added on 2013-04-05 per `git blame`:
233c7992 (Phil Pennock 2013-04-05 00:08:22 +0000 64) 0.6 PTR mid\194\183dle.test.globnix.net.
233c7992 (Phil Pennock 2013-04-05 00:08:22 +0000 65) 1.6 PTR xn--center-dla.test.globnix.net.
233c7992 (Phil Pennock 2013-04-05 00:08:22 +0000 66) 2.6 PTR \240\159\146\169.test.globnix.net.
233c7992 (Phil Pennock 2013-04-05 00:08:22 +0000 67) 3.6 PTR xn--ls8h.test.globnix.net.
so, `noidnout` is not in knot doc html file. clue bat, please.
randy
i have had a fun day chasing diags of the form
```
2024-06-22T18:32:57.305472+00:00 ns knotd[24354]: info: [foo.com.] control, received command 'zone-reload'
2024-06-22T18:32:57.307532+00:00 ns knotd[24354]: info: [foo.com.] zone file parsed, serial 1719081134
2024-06-22T18:32:57.307669+00:00 ns knotd[24354]: warning: [foo.com.] zone file changed with decreased SOA serial
2024-06-22T18:32:57.307828+00:00 ns knotd[24354]: error: [foo.com.] zone event 'load' failed (value is out of range)
```
i have the following hypothesis:
- `serial-policy: unixtime` is configured in `/etc/knot/knot.conf`.
- emacs dns-mode sets the SOA serial to the current unixtime when one
saves the zone file
- a few seconds later, i do `knotc zone sign` and `knotc zone-reload`
- knot then says "you have manually specified a new serial, but it is
less than the current unixtime; i.e. you are trying to go backward.
bad geek!"
- i.e. knot did not like me mucking with the SOA serial in the zone
file when `serial-policy: unixtime` was configured.
i tested this hypothesis by putting the serial from the server's current
SOA in the zone file and doing sign & reload. it succeeded, and the new
zone in all servers is the unixtime of the signing, not of the zone
file.
my current conclusion is: do not have both emacs dns-mode with
`serial-policy: unixtime`; use only one or t'other.
especially if doing RFC 1982 serial stepping, remember to first turn off
`serial-policy: unixtime` and `knotc reload`.
does this make sense?
randy
