From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] test if nameservers with DNSSEC support return "ad"-flagged data
Date: Mon, 22 Jan 2018 13:51:06 +0000 [thread overview]
Message-ID: <1516629066.3647.190.camel@ipfire.org> (raw)
In-Reply-To: <20180120162509.7b128413.peter.mueller@link38.eu>
[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]
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(a)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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-01-22 13:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-20 15:25 Peter Müller
2018-01-22 13:51 ` Michael Tremer [this message]
2018-01-24 16:49 ` Peter Müller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1516629066.3647.190.camel@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox