On Fri, 18 Apr 2025, Philip Homburg wrote:
If I were using .internal names, I would configure them in unbound
exactly the same way that I configure the rDNS for 192.168/16 and
onion and the other zones it's preconfigured to serve. If you ask
for DNSSEC, it says it's unsigned.
If someone is about to say but then if I do my own DNSSEC checks
in my end device it won't work.
That's too simple. If you do your own DNSSEC checks and forward to a local
recursor then home.arpa. will work because it is an insecure delegation.
As it stands today, internal is not delegated so it only works on the
recursor where internal is configured but not on any other DNSSEC validator.
In my opinion, that's quite a big difference.
I use unbound, which by default serves empty stubs for all these zones,
along with the RFC1918 rDNS. In practice it works fine.
# By default, for a number of zones a small default 'nothing here'
# reply is built-in. Query traffic is thus blocked. If you
# wish to serve such zone you can unblock them by uncommenting one
# of the nodefault statements below.
# You may also have to use domain-insecure: zone to make DNSSEC work,
# unless you have your own trust anchors for this zone.
# local-zone: "localhost." nodefault
# local-zone: "127.in-addr.arpa." nodefault
# local-zone: "onion." nodefault
# local-zone: "test." nodefault
# local-zone: "invalid." nodefault
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
