From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter =?utf-8?q?M=C3=BCller?= <peter.mueller@link38.eu>
To: development@lists.ipfire.org
Subject:
 Re: [PATCH] test if nameservers with DNSSEC support return "ad"-flagged data
Date: Wed, 24 Jan 2018 17:49:32 +0100
Message-ID: <20180124174932.05d0ca9e.peter.mueller@link38.eu>
In-Reply-To: <1516629066.3647.190.camel@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2595923335580654986=="
List-Id: <development.lists.ipfire.org>

--===============2595923335580654986==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello,

> Hi,
>=20
> basically this patch works. But I have a few issues I would like to point o=
ut
> and use as a bit of an exercise for everyone.
>=20
> On Sat, 2018-01-20 at 16:25 +0100, Peter M=C3=BCller wrote:
> > DNSSEC-validating nameservers return an "ad" (Authenticated Data)
> > flag in the DNS response header. This can be used as a negative
> > indicator for DNSSEC validation: In case a nameserver does not
> > return the flag, but failes to look up a domain with an invalid
> > signature, it does not support DNSSEC validation.
> >=20
> > This makes it easier to detect nameservers which do not fully
> > comply to the RFCs or try to tamper DNS queries.
> >=20
> > See bug #11595 (https://bugzilla.ipfire.org/show_bug.cgi?id=3D11595) for =
further
> > details.
> >=20
> > Signed-off-by: Peter M=C3=BCller <peter.mueller(a)link38.eu>
> > ---
> >  src/initscripts/system/unbound | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >=20
> > diff --git a/src/initscripts/system/unbound b/src/initscripts/system/unbo=
und
> > index 4e7e63e5f..410631f86 100644
> > --- a/src/initscripts/system/unbound
> > +++ b/src/initscripts/system/unbound
> > @@ -364,7 +364,12 @@ ns_is_validating() {
> >  	local ns=3D${1}
> >  	shift
> > =20
> > -	dig @${ns} A ${TEST_DOMAIN_FAIL} $@ | grep -q SERVFAIL
> > +	if ! dig @${ns} A ${TEST_DOMAIN_FAIL} $@ | grep -q SERVFAIL; then
> > +		return 1
> > +	else
> > +		# Determine if NS replies with "ad" data flag if DNSSEC
> > enabled
> > +		dig @${ns} +dnssec SOA ${TEST_DOMAIN} $@ | grep "\;\;\
> > flags:" | awk -F\: '{ print $2 }' | awk -F\; '{ print $1 }' | grep -q "\ =
ad"
> > +	fi =20
>=20
> a) Parsing the human-readable output of a tool is always a bad idea. It mig=
ht
> change or change just one character and the entire chain doesn't work any m=
ore.
> Let's hope we will notice that before our users do.
You are right. There seems to be no way how to just get the answer flags out =
of dig,
all we can do is suppressing some data parts unused here:

dig SOA +dnssec +adflag +noanswer +noquestion +nostats ipfire.org

This does not fully solve the problem, but reduces the chance that some clutt=
er
in the actual answer data section might cause false-positives.
>=20
> b) There is no need to use grep here. awk can grep like this:
>=20
>   awk /\;\; flags:/ -F: '{ print $2 }'
>=20
Thank you, I will send in a second patch.
> That will save you from calling grep here which increases performance. Usin=
g awk
> and grep is also not really a good idea because every subprocess takes ages=
 to
> execute.
Agreed.
>=20
> The network code in IPFire 3 doesn't use awk at all and grep in rare cases.
>=20
>   https://git.ipfire.org/?p=3Dnetwork.git&a=3Dsearch&h=3DHEAD&st=3Dgrep&s=
=3Dgrep
>   https://git.ipfire.org/?p=3Dnetwork.git&a=3Dsearch&h=3DHEAD&st=3Dgrep&s=
=3Dawk
Wow! I use them virtually everywhere... :-)

Best regards,
Peter M=C3=BCller
>=20
> But to not complicate the code too much we can use awk here. But there is no
> need for grep.
>=20
> >  }
> > =20
> >  # Checks if we can retrieve the DNSKEY for this domain. =20
>=20
> Best,
> -Michael


--===============2595923335580654986==--