Otto [Fri, 21 May 2021 09:19:05 +0000 (11:19 +0200)]
Start of working DoT to auth/forwarder.
The state engine is a bit strange right now, likely needs rework.
I'm also observing connections that remain in "established state"
while I would expect the handler to be cleaned up and connection
to be closed at that point.
Remi Gacogne [Thu, 10 Jun 2021 13:41:06 +0000 (15:41 +0200)]
dnsdist: Fix the lack of IDState for XFR responses
Since we now detect the end of a XFR and reset the is_XFR flag, we
can't rely on it anymore to skip the insertion of the response into
the ring buffer. Set the type of these responses to AXFR and use that
instead.
A better fix would be to make the IDState available even for XFR
responses, at the cost of doing a copy, and perhaps insert an entry
into the ring buffer for the last message.
Pieter Lexis [Wed, 26 May 2021 12:24:17 +0000 (14:24 +0200)]
Update AX_CHECK_SIGN for autoconf 2.71
When running autoreconf with ax_check_sign.m4, autoconf 2.71 complains
about the use of `AX_TRY_COMPILE`:
```
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:29: warning: The macro `AC_TRY_COMPILE' is obsolete.
configure.ac:29: You should run autoupdate.
./lib/autoconf/general.m4:2847: AC_TRY_COMPILE is expanded from...
lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
m4/ax_check_sign.m4:41: AX_CHECK_SIGN is expanded from...
m4/pdns_check_time_t.m4:1: PDNS_CHECK_TIME_T is expanded from...
configure.ac:29: the top level
```
This updates the macro to use `AC_COMPILE_IFELSE`, which has been present in
autoconf since at least version 2.60, released in 26 Jun 2006 (I did not
check any older releases).
This patch has been [submitted](http://savannah.gnu.org/patch/index.php?10071) [upstream](https://github.com/autoconf-archive/autoconf-archive/pull/225).
Remi Gacogne [Mon, 31 May 2021 15:00:18 +0000 (17:00 +0200)]
rec: Don't follow referral from the parent to the child for DS queries
It happens if the server does not know about the DS special case.
Treat the delegation as a unsigned NODATA answer in that case.
For example for sthc.nordlo.cloud we go from the existing:
```
[1] sthc.nordlo.cloud: Resolved 'nordlo.cloud' NS ns2.zetup.se to: 159.253.27.75
[1] sthc.nordlo.cloud: Trying IP 159.253.27.75:53, asking 'sthc.nordlo.cloud|DS'
[1] sthc.nordlo.cloud: Got 3 answers from ns2.zetup.se (159.253.27.75), rcode=0 (No Error), aa=0, in 35ms
[1] sthc.nordlo.cloud: accept answer 'sthc.nordlo.cloud|NS|ns2.loopia.se.' from 'nordlo.cloud' nameservers? ttl=3600, place=2 YES!
[1] sthc.nordlo.cloud: accept answer 'sthc.nordlo.cloud|NS|ns1.loopia.se.' from 'nordlo.cloud' nameservers? ttl=3600, place=2 YES!
[1] sthc.nordlo.cloud: OPT answer '.' from 'nordlo.cloud' nameservers
[1] sthc.nordlo.cloud: determining status after receiving this packet
[1] sthc.nordlo.cloud: got NS record 'sthc.nordlo.cloud' -> 'ns2.loopia.se.'
[1] sthc.nordlo.cloud: got NS record 'sthc.nordlo.cloud' -> 'ns1.loopia.se.'
[1] sthc.nordlo.cloud: status=did not resolve, got 2 NS, looping to them
[1] sthc.nordlo.cloud.: Nameservers: ns1.loopia.se(37.85ms), ns2.loopia.se(38.26ms)
[1] sthc.nordlo.cloud: Trying to resolve NS 'ns1.loopia.se' (1/2)
[1] Nameserver ns1.loopia.se IPs: 93.188.0.20(37.85ms)
[1] sthc.nordlo.cloud: Resolved 'sthc.nordlo.cloud' NS ns1.loopia.se to: 93.188.0.20
[1] sthc.nordlo.cloud: Trying IP 93.188.0.20:53, asking 'sthc.nordlo.cloud|DS'
```
to:
```
[1] sthc.nordlo.cloud: Resolved 'nordlo.cloud' NS ns2.zetup.se to: 159.253.27.75
[1] sthc.nordlo.cloud: Trying IP 159.253.27.75:53, asking 'sthc.nordlo.cloud|DS'
[1] sthc.nordlo.cloud: Got 3 answers from ns2.zetup.se (159.253.27.75), rcode=0 (No Error), aa=0, in 35ms
[1] sthc.nordlo.cloud: accept answer 'sthc.nordlo.cloud|NS|ns2.loopia.se.' from 'nordlo.cloud' nameservers? ttl=3600, place=2 YES!
[1] sthc.nordlo.cloud: accept answer 'sthc.nordlo.cloud|NS|ns1.loopia.se.' from 'nordlo.cloud' nameservers? ttl=3600, place=2 YES!
[1] sthc.nordlo.cloud: OPT answer '.' from 'nordlo.cloud' nameservers
[1] sthc.nordlo.cloud: determining status after receiving this packet
[1] sthc.nordlo.cloud: got NS record 'sthc.nordlo.cloud' -> 'ns2.loopia.se.'
[1] sthc.nordlo.cloud: got (implicit) negative indication of DS record for 'sthc.nordlo.cloud'
[1] sthc.nordlo.cloud: got NS record 'sthc.nordlo.cloud' -> 'ns1.loopia.se.'
[1] sthc.nordlo.cloud: status=noerror, other types may exist, but we are done (have negative SOA)
[1] : no signatures for sthc.nordlo.cloud, we likely missed a cut between cloud and nordlo.cloud, looking for it
```