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
