Message ID | 20180120162509.7b128413.peter.mueller@link38.eu |
---|---|
State | Accepted |
Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (unknown [172.28.1.200]) by web02.ipfire.org (Postfix) with ESMTP id 777DF60329 for <patchwork@ipfire.org>; Sat, 20 Jan 2018 16:25:20 +0100 (CET) Received: from mail01.ipfire.org (localhost [IPv6:::1]) by mail01.ipfire.org (Postfix) with ESMTP id F39AC4555; Sat, 20 Jan 2018 16:25:19 +0100 (CET) Received: from mx.link38.eu (mx.link38.eu [IPv6:2a03:4000:17:39a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.link38.eu", Issuer "Let's Encrypt Authority X3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id A81544552 for <development@lists.ipfire.org>; Sat, 20 Jan 2018 16:25:16 +0100 (CET) X-Virus-Scanned: ClamAV at mx.link38.eu Received: from mx-fra.brokers.link38.eu (mx-fra.brokers.link38.eu [10.141.75.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.link38.eu (Postfix) with ESMTPS id D129B40127 for <development@lists.ipfire.org>; Sat, 20 Jan 2018 16:25:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx-fra.brokers.link38.eu (Postfix) with ESMTPSA id 500D69F3A8 for <development@lists.ipfire.org>; Sat, 20 Jan 2018 16:25:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=link38.eu; s=201711; t=1516461910; x=1579533910; bh=IJF0d5ZScxpWEr5rlhmgLlrThKKC/q29k4z2hm8eNgA=; h=Date:From:To:Subject:Message-ID:Content-Type:From:To:Subject:Date: Cc; b=Dpx2AsRrmJzr2M09SmcLBXZ0sZUxrHUf+FWjwdTOykuqlAb2rv0xZdwkndiTUTfQZ eqCWmqT7P5lg8lTPi8Urx1SFzVtj5X9gL+0hT7xawoa+7NR1d59OtYcZtxZn1B4+DG FiKBOVfHU0mGwTt9mmiTAza6T+3xRlCfAkgBS8ifl5fcJhD2z6sgYE1u28B/0HXjrw BqBE8wmW2pecwS/xrM703D3VMLq6VlLnX4+Mp9Lnps5vXX9rKwY3KwVUTmXc5DKVfa L/tbyDGgBL+b/E6npZYkd0SYagrRbMVIhJVQjQKHWEkRO5pjO7EaUIYuvMg4hMPqdI p5g9/xO/S0XAQ== Date: Sat, 20 Jan 2018 16:25:09 +0100 From: Peter =?utf-8?q?M=C3=BCller?= <peter.mueller@link38.eu> To: "development@lists.ipfire.org" <development@lists.ipfire.org> Subject: [PATCH] test if nameservers with DNSSEC support return "ad"-flagged data Message-ID: <20180120162509.7b128413.peter.mueller@link38.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <https://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <https://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <https://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
Series |
test if nameservers with DNSSEC support return "ad"-flagged data
|
|
Commit Message
Peter Müller
Jan. 21, 2018, 2:25 a.m. UTC
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.
This makes it easier to detect nameservers which do not fully
comply to the RFCs or try to tamper DNS queries.
See bug #11595 (https://bugzilla.ipfire.org/show_bug.cgi?id=11595) for further details.
Signed-off-by: Peter Müller <peter.mueller@link38.eu>
---
src/initscripts/system/unbound | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Comments
Hi, basically this patch works. But I have a few issues I would like to point out and use as a bit of an exercise for everyone. On Sat, 2018-01-20 at 16:25 +0100, Peter Müller 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. > > This makes it easier to detect nameservers which do not fully > comply to the RFCs or try to tamper DNS queries. > > See bug #11595 (https://bugzilla.ipfire.org/show_bug.cgi?id=11595) for further > details. > > Signed-off-by: Peter Müller <peter.mueller@link38.eu> > --- > src/initscripts/system/unbound | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/src/initscripts/system/unbound b/src/initscripts/system/unbound > index 4e7e63e5f..410631f86 100644 > --- a/src/initscripts/system/unbound > +++ b/src/initscripts/system/unbound > @@ -364,7 +364,12 @@ ns_is_validating() { > local ns=${1} > shift > > - 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 a) Parsing the human-readable output of a tool is always a bad idea. It might change or change just one character and the entire chain doesn't work any more. Let's hope we will notice that before our users do. b) There is no need to use grep here. awk can grep like this: awk /\;\; flags:/ -F: '{ print $2 }' That will save you from calling grep here which increases performance. Using awk and grep is also not really a good idea because every subprocess takes ages to execute. The network code in IPFire 3 doesn't use awk at all and grep in rare cases. https://git.ipfire.org/?p=network.git&a=search&h=HEAD&st=grep&s=grep https://git.ipfire.org/?p=network.git&a=search&h=HEAD&st=grep&s=awk But to not complicate the code too much we can use awk here. But there is no need for grep. > } > > # Checks if we can retrieve the DNSKEY for this domain. Best, -Michael
Hello, > Hi, > > basically this patch works. But I have a few issues I would like to point out > and use as a bit of an exercise for everyone. > > On Sat, 2018-01-20 at 16:25 +0100, Peter Müller 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. > > > > This makes it easier to detect nameservers which do not fully > > comply to the RFCs or try to tamper DNS queries. > > > > See bug #11595 (https://bugzilla.ipfire.org/show_bug.cgi?id=11595) for further > > details. > > > > Signed-off-by: Peter Müller <peter.mueller@link38.eu> > > --- > > src/initscripts/system/unbound | 7 ++++++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/src/initscripts/system/unbound b/src/initscripts/system/unbound > > index 4e7e63e5f..410631f86 100644 > > --- a/src/initscripts/system/unbound > > +++ b/src/initscripts/system/unbound > > @@ -364,7 +364,12 @@ ns_is_validating() { > > local ns=${1} > > shift > > > > - 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 > > a) Parsing the human-readable output of a tool is always a bad idea. It might > change or change just one character and the entire chain doesn't work any more. > 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 clutter in the actual answer data section might cause false-positives. > > b) There is no need to use grep here. awk can grep like this: > > awk /\;\; flags:/ -F: '{ print $2 }' > Thank you, I will send in a second patch. > That will save you from calling grep here which increases performance. Using awk > and grep is also not really a good idea because every subprocess takes ages to > execute. Agreed. > > The network code in IPFire 3 doesn't use awk at all and grep in rare cases. > > https://git.ipfire.org/?p=network.git&a=search&h=HEAD&st=grep&s=grep > https://git.ipfire.org/?p=network.git&a=search&h=HEAD&st=grep&s=awk Wow! I use them virtually everywhere... :-) Best regards, Peter Müller > > But to not complicate the code too much we can use awk here. But there is no > need for grep. > > > } > > > > # Checks if we can retrieve the DNSKEY for this domain. > > Best, > -Michael
diff --git a/src/initscripts/system/unbound b/src/initscripts/system/unbound index 4e7e63e5f..410631f86 100644 --- a/src/initscripts/system/unbound +++ b/src/initscripts/system/unbound @@ -364,7 +364,12 @@ ns_is_validating() { local ns=${1} shift - 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 } # Checks if we can retrieve the DNSKEY for this domain.