On Wed, Feb 05, 2020 at 04:14:41PM +0100, Florian Obser wrote:
> On Tue, Feb 04, 2020 at 11:41:14AM +0000, Raf Czlonka wrote:
> > On Mon, Feb 03, 2020 at 07:29:02PM GMT, Florian Obser wrote:
> > > On Mon, Feb 03, 2020 at 07:58:24PM +0100, Solene Rapenne wrote:
> > > > On Mon, Feb 03, 2020 at 07:52:29PM +0100, Florian Obser wrote:
> > > > > On Mon, Feb 03, 2020 at 06:16:54PM +0100, Solene Rapenne wrote:
> > > > > > I re-enabled unwind today (i was using append instead of prepend in
> > > > > > dhclient.conf) and I got a few issues resolving domains, often the
> > > > > > first
> > > > > > time, if I try again I get a result. I'm pretty sure it's not a
> > > > > > bug, but
> > > > > > I have no idea what's happening here, so maybe log output or
> > > > > > documentation could be enhanced.
> > > > > >
> > > > > >
> > > > > > From /var/log/messages (192.168.1.254 is dns from my dhcp)
> > > > > >
> > > > > > Feb 3 17:55:44 solene unwind[18044]: validation failure
> > > > > > <ocsp.int-x3.letsencrypt.org. A IN>: no signatures from
> > > > > > 192.168.1.254 for key org. while building chain of trust
> > > > > > Feb 3 18:05:10 solene unwind[18044]: validation failure
> > > > > > <google.fr. A IN>: no DNSSEC records from 192.168.1.254 for DS
> > > > > > google.fr. while building chain of trust
> > > > > > Feb 3 18:05:18 solene unwind[18044]: validation failure
> > > > > > <google.it. A IN>: no signatures from 192.168.1.254 for DS it.
> > > > > > while building chain of trust
> > > > > >
> > > > >
> > > > > Looks like your dhcp nameserver strips DNSSEC in a weird way.
> > > > > Can you please show
> > > > >
> > > > > dig @192.168.1.254 +dnssec . SOA
> > > > > and
> > > > > dig @192.168.1.254 org DNSKEY
> > > > >
> > > > > --
> > > > > I'm not entirely sure you are real.
> > > > >
> > > >
> > > > sure :)
> > > >
> > > > solene@t480 ~ $ dig @192.168.1.254 +dnssec . SOA
> > > >
> > > > ; <<>> dig 9.10.8-P1 <<>> @192.168.1.254 +dnssec . SOA
> > > > ; (1 server found)
> > > > ;; global options: +cmd
> > > > ;; Got answer:
> > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63346
> > > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> > > >
> > > > ;; OPT PSEUDOSECTION:
> > > > ; EDNS: version: 0, flags:; udp: 4096
> > > > ;; QUESTION SECTION:
> > > > ;. IN SOA
> > > >
> > > > ;; ANSWER SECTION:
> > > > . 84857 IN SOA a.root-servers.net.
> > > > nstld.verisign-grs.com. 2020020301 1800 900 604800 86400
> > > >
> > > > ;; Query time: 25 msec
> > > > ;; SERVER: 192.168.1.254#53(192.168.1.254)
> > > > ;; WHEN: Mon Feb 03 19:54:35 CET 2020
> > > > ;; MSG SIZE rcvd: 103
> > > >
> > >
> > > for the archives: 192.168.1.254 is stripping rrsigs but unwind thinks
> > > dhcp is validating. This is wrong and we need to figure out why.
> > >
> >
> > Hi all,
> >
> > I've been having similar (the same?) issues since at least mid-to-late
> > December. I hadn't a chance to diagnose it properly hence sending
> > an email only now to confirm Solene's isn't an isolated case.
> >
> > Unlike Solene, I would have to restart unwind to get it resolving.
>
> I'm sure you had(!) a different issue than Solene. unwind correctly
> detects that your dhcp provided nameserver can only do resolving and
> strips dnssec records while the recursor can do validation.
>
> On December 18th I enabled a shared cache for negative answers in
> rev 1.116 of resolver.c.
>
> As kn@ found out the hard way we cannot share a cache with a resolving
> strategy that can only do resolving.
> This has been fixed on January 20th with rev 1.120:
>
> We can not share a cache between validating and resolving strategies.
> The resolving only strategies mess up the negative cache by claiming
> DNSSEC related records do not exist which confuses the validating
> strategies.
> Found the hard way by kn@ and analysed by otto@
> OK kn@
>
> Pretty sure your issue has been resolved with that (The log you are
> showing is certainly from the timeframe where the issue existed).
>
> It's still a bit unclear what Solene's issue was, it looks like the
> dhcp provided nameserver did support dnssec in the past and then
> suddenly stopped. Possibly a change at the isp. unwind failed to
> detect this. I have to think about what to do about it.
Maybe several recursors are behind a single IP, being loadbalanced? I
have seen setups with muliple recursors from different vendors being
used with different settings. In that case the client might see
different result depending on the load balancing changing.
-Otto
>
> >
> > Not sure whether the first line is at all significant - I've seen
> > it only three times since December.
> >
> > Dec 25 05:17:07 rose unwind[83579]: [83579:0] error: outgoing tcp:
> > connect: Permission denied for 194.168.8.100 port 853
> > Dec 26 16:22:44 rose unwind[83579]: validation failure
> > <cdn.openbsd.org. A IN>: key for validation org. is marked as invalid
> > because of a previous validation failure <cdn.openbsd.org. A IN>: no
> > signatures from 194.168.8.100 for key org. while building chain of trust
> > Dec 26 16:22:58 rose unwind[48598]: dhcp: validation failure <. NS IN>:
> > no signatures from 194.168.8.100 for trust anchor . while building chain of
> > trust
> >
> > This is the current status of unwind (yesterday's snapshot):
> >
> > $ unwindctl status
> > 1. recursor validating, 70ms 3. dhcp resolving,
> > 150ms
> > 2. stub resolving, 70ms 4. oDoT-dhcp dead,
> > N/A
> >
> > histograms: lifetime[ms], decaying[ms]
> > <10 <20 <40 <60 <80 <100 <200 <400 <600 <800
> > <1000 >
> > rec 14125 98 1489 1070 667 608 1683 1025 288 176
> > 117 245
> > 95 1 14 7 7 5 12 5 2 2
> > 1 1
> > stub 0 168 378 183 91 75 509 183 46 38
> > 25 53
> > 0 2 5 2 0 1 6 1 0 1
> > 0 0
> > dhcp 20 118 536 288 205 130 854 396 51 43
> > 38 60
> > 0 0 1 2 1 0 5 2 1 0
> > 0 0
> > dhcp* 0 0 0 0 0 0 0 0 0 0
> > 0 0
> > 0 0 0 0 0 0 0 0 0 0
> > 0 0
> >
> > $ unwindctl status memory
> > msg-cache: 192106 / 1048576 (18.32%)
> > rrset-cache: 742342 / 1048576 (70.80%)
> > key-cache: 118824 / 1048576 (11.33%)
> > neg-cache: 54613 / 102400 (53.33%)
> >
> > $ dig @194.168.8.100 +dnssec . SOA
> >
> > ; <<>> dig 9.10.8-P1 <<>> @194.168.8.100 +dnssec . SOA
> > ; (1 server found)
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30608
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags: do; udp: 512
> > ;; QUESTION SECTION:
> > ;. IN SOA
> >
> > ;; ANSWER SECTION:
> > . 7387 IN SOA a.root-servers.net.
> > nstld.verisign-grs.com. 2020020300 1800 900 604800 86400
> >
> > ;; Query time: 13 msec
> > ;; SERVER: 194.168.8.100#53(194.168.8.100)
> > ;; WHEN: Tue Feb 04 11:34:45 GMT 2020
> > ;; MSG SIZE rcvd: 103
> >
> > $ dig @194.168.8.100 org DNSKEY
> >
> > ; <<>> dig 9.10.8-P1 <<>> @194.168.8.100 org DNSKEY
> > ; (1 server found)
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1391
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 512
> >
> > ;; QUESTION SECTION:
> > ;org. IN DNSKEY
> >
> > ;; ANSWER SECTION:
> > org. 900 IN DNSKEY 256 3 7
> > AwEAAckRQFGzYbS2OQXpXbXyQqxq+hQ6duZa7HRI9RWfzyKh+cQHSYl2
> > 1tqYKEvc6+9UFqf/iWnM8w2M4kQdd/hF8FdWfp7gPLzX7KYcdzR7Vgzf
> > pQA184R+GR3T/S4wJggIi97xBO+dptwp40sTyg9ItA1adGVSs+hjRW3C uKvobENn
> > org. 900 IN DNSKEY 256 3 7
> > AwEAAc2YgUjigNpgbsmzLkHyamRd31OOchY1kRkYDhPyufgiM9KiqujZ
> > U53x9qEhq465qf6IgdKxWeYQMk+Glw49IHRx1hvdxjn6Gfjc/96uH5cv
> > khEV38SvuDeZOzbNkJK0BvYo6Hck4lCSjJ1Wl2n1Mjguba0lEo8haWdJ MJS1D603
> > org. 900 IN DNSKEY 257 3 7
> > AwEAAZTjbIO5kIpxWUtyXc8avsKyHIIZ+LjC2Dv8naO+Tz6X2fqzDC1b
> > dq7HlZwtkaqTkMVVJ+8gE9FIreGJ4c8G1GdbjQgbP1OyYIG7OHTc4hv5
> > T2NlyWr6k6QFz98Q4zwFIGTFVvwBhmrMDYsOTtXakK6QwHovA1+83BsU
> > ACxlidpwB0hQacbD6x+I2RCDzYuTzj64Jv0/9XsX6AYV3ebcgn4hL1jI
> > R2eJYyXlrAoWxdzxcW//5yeL5RVWuhRxejmnSVnCuxkfS4AQ485KH2tp
> > dbWcCopLJZs6tw8q3jWcpTGzdh/v3xdYfNpQNcPImFlxAun3BtORPA2r 8ti6MNoJEHU=
> > org. 900 IN DNSKEY 257 3 7
> > AwEAAcMnWBKLuvG/LwnPVykcmpvnntwxfshHlHRhlY0F3oz8AMcuF8gw
> > 9McCw+BoC2YxWaiTpNPuxjSNhUlBtcJmcdkz3/r7PIn0oDf14ept1Y9p
> > dPh8SbIBIWx50ZPfVRlj8oQXv2Y6yKiQik7bi3MT37zMRU2kw2oy3cgr
> > sGAzGN4s/C6SFYon5N1Q2O4hGDbeOq538kATOy0GFELjuauV9guX/431
> > msYu4Rgb5lLuQ3Mx5FSIxXpI/RaAn2mhM4nEZ/5IeRPKZVGydcuLBS8G
> > ZlxW4qbb8MgRZ8bwMg0pqWRHmhirGmJIt3UuzvN1pSFBfX7ysI9PPhSn wXCNDXk0kk0=
> >
> > ;; Query time: 23 msec
> > ;; SERVER: 194.168.8.100#53(194.168.8.100)
> > ;; WHEN: Tue Feb 04 11:35:12 GMT 2020
> > ;; MSG SIZE rcvd: 880
> >
> > Regards,
> >
> > Raf
> >
>
> --
> I'm not entirely sure you are real.
>
