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:
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?
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
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.
20:20
Evilham via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
Thanks, but my question was more about that:
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)
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?
those are PTR records and are essential for things like email (learndmarc.com is a good
resource that checks for this) > "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:
Evilham via knot-dns-users
<knot-dns-users(a)lists.nic.cz> wrote:
Thanks,
but my question was more about that:
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)
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?
those are PTR records and are essential for
things like email (learndmarc.com is a good resource that checks for this) > "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
--
14:39
Hi Libor
Libor Peltan via knot-dns-users <knot-dns-users(a)lists.nic.cz> wrote:
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.
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.
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?
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".
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.
Libor
4
days inactive
6
days old
5 comments
3 participants
participants (3)
-
Evilham -
Libor Peltan -
Michael Grimm