29 Bře
2025
29 Bře
'25
14:22
Hi,
given the case that a ip6/xy block might be delegated to me by my ISP, I began
investigating Knot DNS' functionality with regard to ip6.arpa.
Hereby I stumbled over the module synthrecord and do not really understand what it is used
for.
From
https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#synthrecord-automati…
"Records are synthesized only if the query can't be satisfied from the
zone."
Please excuse my ignorance, but why would/should/must one return something else than the
following for hosts not in the zone?
kbn> host 2001:dead:beef::1
Host 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.e.e.b.d.a.e.d.1.0.0.2.ip6.arpa not
found: 3(NXDOMAIN)
Any feedback is highly appreciated, thanks.
Regards,
Michael
29 Bře
29 Bře
19:10
Hey,
On ds., març 29 2025, Michael Grimm via knot-dns-users wrote:
those are PTR records and are essential for things like email
(learndmarc.com is a good resource that checks for this)
It can also be useful to generate such records under a domain of
the ISP itself, any network tool that uses DNS to resolve
hostnames will show that and it can help separate your own network
from external networks.
As a quick example from this mailing list:
$ host lists.nic.cz
lists.nic.cz has address 217.31.204.208
lists.nic.cz has IPv6 address 2001:1488:800:400::2:208
lists.nic.cz mail is handled by 10 mail.nic.cz.
$ host 2001:1488:800:400::2:208
8.0.2.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.8.0.8.8.4.1.1.0.0.2.ip6.arpa
domain name pointer mailman.nic.cz.
8.0.2.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.8.0.8.8.4.1.1.0.0.2.ip6.arpa
domain name pointer lists.nic.cz.
Cheers,
--
Evilham
20:20
Evilham via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
On ds., març 29 2025, Michael Grimm via knot-dns-users
wrote:
> given the case that a ip6/xy block might be
delegated to me by my ISP, I began investigating Knot DNS' functionality with regard
to ip6.arpa.
The "might be" can be modified into "has been" delegated. Thus I am
currently setting up my PTRs, and I have to learn the Knot way ;-) (10+ years ago I did
this with bind)
Thanks, but my question was more about that:
> "Records are synthesized only if the query
can't be satisfied from the zone."
Why would/should/must one return something like (from the link above) …
kdig -x 2620:0:b61::1
...
;; QUESTION SECTION:
;; 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.6.b.0.0.0.0.0.0.2.6.2.ip6.arpa. IN PTR
;; ANSWER SECTION:
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.6.b.0.0.0.0.0.0.2.6.2.ip6.arpa. 400 IN PTR
dynamic-2620-0-b61--1.test.
… if "the query can't be satisfied from the zone."
Thanks and regards,
Michael
30 Bře
30 Bře
13:23
Hi Michael,
I guess the sentence "only if the query can't be satisfied from the
zone" means that the zone file takes precedence (and overrides)
automatically generated records. So if you create your reverse zone with
_some_ names in it, synthrecord will generate only for the other names.
Anyway, an alternative to using synthrecord module is to generate the
reverse zone with
https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#reverse-generate
. This method is more offline, so it can be combined with traditional
DNSSEC signing (synthrecord has to be chained with onlinesign to achieve
DNSSEC).
Libor
On 29. 03. 25 20:20, Michael Grimm via knot-dns-users wrote:
14:39
Hi Libor
Libor Peltan via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
Understood and thanks.
Anyway, an alternative to using synthrecord module is
to generate the reverse zone with
https://www.knot-dns.cz/docs/3.4/singlehtml/index.html#reverse-generate .
This is very important information for me, because I was wondering of how would secure a
reverse zone by DNSSEC.
From your link:
| This option triggers the automatic generation of reverse PTR records based on A/AAAA
records in the specified zone. The
| entire generated zone is automatically stored in the journal.
Does that mean that:
#) if I do host a given number of zone files, and
#) if all those zones use AAAA records of the same IPv6 reverse zone,
#) I don't even need to create and maintain an ip6.arpa zone file?
Correct?
This method is more offline, so it can be combined
with traditional DNSSEC signing
Does that mean that I do only need to include ...
| - domain: b.0.0.0.a.0.0.0.f.e.e.b.d.a.e.d.ip6.arpa"
| dnssec-signing: on
… in knot.conf and my reverse zone is signed. Correct?
But what about KSK for my reverse zone and DNSKEY "upload to the registrar"?
I do have the feeling I am missing an important part here ;-)
Any feedback is highly appreciated.
Thanks and regards,
Michael
31 Bře
31 Bře
12:30
Hi Michael,
#) if I do host a given number of zone files, and
Unfortunately, this feature has a limitation that the given number of
(forward) zones must be only 1 (for each reverse zone). But we might be
working on relaxing this limitation for future versions of Knot.
#) if all those zones use AAAA records of the same
IPv6 reverse zone,
This is not even necessary, the AAAA records from a single
(forward)
zone might be in multiple reverse zones, provided that you configure
them all (or all that you want to have generated).
#) I don't even need to create and maintain an
ip6.arpa zone file?
You still need to create the reverse zone as usual, including
the zone
file with some skeleton (SOA, NS, ....), but the PTR records will be
filled in by Knot.
Yes, you still might need to
configure some more stuff (zone transfers,
zone file, journal, DNSSEC policy), but basically it's as easy as for
normal zones. And don't forget the key option which is "reverse-generate".
Uploading your KSKs to your registrar is out of scope for us (unless the
registry supports RFC 7344), because every registrar has this different.
But the process is equivalent for normal and reverse zones.
Libor
12 Dub
12 Dub
17:51
Libor Peltan via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
> #) if I do host a given number of zone files, and
Unfortunately, this feature has a limitation that the
given number of (forward) zones must be only 1 (for each reverse zone). But we might be
working on relaxing this limitation for future versions of Knot.
Looks like 3.4.6 is already capable of relaxing this limitation ;-)
> But what about KSK for my reverse zone and DNSKEY
"upload to the registrar"?
> I do have the feeling I am missing an important part here ;-)
Uploading your KSKs to your registrar is out of scope
for us (unless the registry supports RFC 7344), because every registrar has this
different. But the process is equivalent for normal and reverse zones.
My registrar doesn't provide a way to upload KSKs, and their own reverse zone
isn't secured either.
Thus I have to stick with an unsecured ip6.arpa reverse zone for the time being.
Thanks for your help and regards,
Michael
13 Dub
13 Dub
21:28
On 3/31/25 12:30, Libor Peltan via knot-dns-users wrote:
Or RFC 9615:
https://www.knot-dns.cz/docs/3.4/html/modules.html#authsignal-automatic-aut…
Cheers,
Peter
--
https://desec.io/
21:59
Peter Thomassen via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
On 3/31/25 12:30, Libor Peltan via knot-dns-users
wrote:
>> But what about KSK for my reverse zone and
DNSKEY "upload to the registrar"?
>> I do have the feeling I am missing an important part here ;-)
> Uploading your KSKs to your registrar is out of
scope for us (unless the registry supports RFC 7344), because every registrar has this
different. But the process is equivalent for normal and reverse zones.
Interesting, thanks.
Now I need to find out, if that's possible with an ip6.arpa zone …
Regards,
Michael
22:01
Hi Michael,
On 4/13/25 21:59, Michael Grimm via knot-dns-users wrote:
In general it's possible if the parent operator supports it. I'm not aware of any
DNS operators support it as a parent operator (only some registrars/registries, see
https://github.com/oskar456/cds-updates).
Cheers,
Peter
--
https://desec.io/
22:17
Hi Peter
Peter Thomassen via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
On 4/13/25 21:59, Michael Grimm via knot-dns-users
wrote:
Oh, that list includes RIPE NCC [1]. Does that mean: it is possible to bootstrap DNSSEC
for my ip6.arpa zone?
Sorry for that newbie question, but that is absolutely new for me.
Thanks and regards,
Michael
[1]
https://docs.db.ripe.net/Database-Support/Configuring-Reverse-DNS/#automate…
22:31
Hi Michael,
On 4/13/25 22:17, Michael Grimm via knot-dns-users wrote:
Oh, that list includes RIPE NCC [1]. Does that mean:
it is possible to bootstrap DNSSEC for my ip6.arpa zone?
[...]
The way I read their docs is that they only use RFC 7344, which means you can use
CDS/CDNSKEY records in your zone to *update* your pre-existing DS records.
For configuring DS records for the first time ("bootstrap"), they would need to
support RFC 8078 and/or RFC 9615, but apparently they don't do that (yet?).
All of this of course only applies if your zone is delegated directly from a parent zone
run by RIPE. If it's delegated from an intermediate zone run by someone else,
you'll have to ask that operator.
Cheers,
Peter
--
https://desec.io/
22:47
Hi Peter
Peter Thomassen via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
On 4/13/25 22:17, Michael Grimm via knot-dns-users
wrote:
Thanks for your feedback.
Then it seems, that I do have to stick with an unsecured ip6.arpa zone, because OVH
doesn't support that for the time being. Even their own ip6.arpa zone isn't
secured [1], if I am not mistaken.
Thanks again and regards,
Michael
[1] https://dnsviz.net/d/0.d.1.4.1.0.0.2.ip6.arpa/dnssec/
103
days inactive
118
days old
12 comments
4 participants
participants (4)
-
Evilham -
Libor Peltan -
Michael Grimm -
Peter Thomassen