On Wed, Jul 29, 2020 at 05:42:16PM +0200, Florian Obser wrote:
> > First you mention fallback to DHCP-learned resolvers. Those you should
> > probably not trust indeed, but it looks like unwind(8) attempts to use
> > them to perform its own validation. So the value of the AD flag in
> > unwind(8)'s response should be trustworthy. At least that's what I see
> > when I test unwind with "preference { dhcp }".
> >
>
> unwind always does its own validation or decides it can't do
> validation. In both cases you can trust the AD flag.
> The AD flag is set if and only if unwind did a successful validation.
>
> You cannot trust the RCODE (and answer) when AD is *NOT* set. That
> seems like a strange and obvious statement but it is the main
> difference to validating unbound. When you enable validation in
> unbound and someone messes with your packets you will get a SERVFAIL.
Hi all,
I just put unwind on my own forwarding dns server and you can see what it does
in the following logs (I like it!):
--- here I restarted unwind, it looks up the root zone ---
Jul 29 18:06:19 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.291ms) for "." \
type=NS(2) class=1, edns0, dnssecok, answering "FORWARD" (28/83)
Jul 29 18:06:19 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.486ms) for "." \
type=DNSKEY(48) class=1, edns0, dnssecok, answering "FORWARD" (28/83)
Jul 29 18:06:19 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.286ms) for "." \
type=DNSKEY(48) class=1, edns0, dnssecok, answering "FORWARD" (28/83)
---- it now has the anchor keys to check that these dnskeys are right ----
---- at this point I did a ping of centroid.eu -----
Jul 29 18:07:00 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.347ms) for \
"centroid.eu." type=A(1) class=1, edns0, dnssecok, answering "FORWARD" (40/83)
--- it then proceeds to check the eu. DS and DNSKEY to do DNSSEC validation ---
Jul 29 18:07:00 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.358ms) for "eu." \
type=DS(43) class=1, edns0, dnssecok, answering "FORWARD" (31/83)
Jul 29 18:07:00 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.289ms) for "eu." \
type=DNSKEY(48) class=1, edns0, dnssecok, answering "FORWARD" (31/83)
Jul 29 18:07:00 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.292ms) for \
"centroid.eu." type=DS(43) class=1, edns0, dnssecok, answering "FORWARD" (40/83)
Jul 29 18:07:00 eta delphinusdnsd[56662]: request on descriptor 16 interface \
"cnmac1" from 192.168.177.2 (ttl=64, region=255, tta=1.346ms) for \
"centroid.eu." type=DNSKEY(48) class=1, edns0, dnssecok, answering "FORWARD" \
(40/83)
--- at this point the DNSSEC validation reverse walk is complete ----
Here is the unwind .conf file I used on my network:
forwarder 192.168.177.1
preference forwarder
And here is some attempt at explaining the delphinusdnsd log format:
https://delphinusdns.org/blog/c?article=1568367256
The log FORWARD is new, it just means that delphinusdnsd gives off the
question to its own forwarding engine that forwards the request. My setup
is as follows (in terms of dns servers):
unwind[1]->delphinusdnsd forwarder[2]->delphinusdnsd forwarder[3]->unbound[4]
The path between [2] and [3] is a secure TSIG channel on another port than 53.
[2] has a cache, [3] does not.
I assume unwind also has a cache?
Unbound does give the AD bit back here, though that's not in my logs. I know
this though because of dnssecok and edns0 bits on the question in delphinusdnsd
it is passed forwards. I know also that unwind would get the AD flag here,
It is just like Florian describes it. unwind does validation despite the AD
flag. This is awesome!
I think I'll keep this setup for a while it can't hurt. Ultimately I'd love
to get rid of [3] and [4] in this setup and have [2] use the ISP's powerdns
nameservers. But [2] sits at my gateway (a little octeon USG) and can't get
the nameservers from the pppoe0 without a patch. Because maintaining patches
that don't come with OpenBSD get discarded and overrun eventually I can only
point to the patch I sent about a month ago to tech@ that brings Gerhard
Roth's patch up to the times (but I broke it in some way, so it would need to
be fixed up a little). I would really like to see this functionality in
OpenBSD for modifying this little setup above, *pretty please?* :)
Thanks guys for the great work and interesting discussion!
-peter
