RE: dnssec-validation?

[David Carvalho via bind-users]

Hi and thanks for the reply.

"Do you have an overly restrictive firewall?" - yes. Tried to reach the network 
guy but he won't be here this week. But it is unlikely, because dns2 is working 
fine and, from what I've been told, they are in the same ACL group.

-
This is my output:
rndc managed-keys status

view: _default
next scheduled event: Thu, 13 Apr 2023 10:18:05 GMT

name: .
keyid: 0
algorithm: 0
flags: (none)
next refresh: Thu, 26 Jan 2023 16:05:04 GMT
no trust
---
dig +cd +dnssec +multi . DNSKEY

; <<>> DiG 9.11.36-RedHat-9.11.36-5.el8_7.2 <<>> +cd +dnssec +multi . DNSKEY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39638
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 01c1387577eb12360100643910a2f6b0163c1001c9b2 (good)
;; QUESTION SECTION:
;.  IN DNSKEY

;; ANSWER SECTION:
.   92475 IN DNSKEY 257 3 8 (
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN
7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5
LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8
efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7
pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY
A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws
9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
) ; KSK; alg = RSASHA256 ; key id = 20326
.   92475 IN DNSKEY 256 3 8 (
AwEAAbF1LAxEQPtClEQno48k6u7JjCOfVfwdENOxQUrX
0JbpN5DnKGMAKIfdiWa5oDeKQ3OoQ58yCC8vjtaaGFDg
pJxoLwqzhBYHPGFgins5HIERcCQPGAJKWu/ku4XLh+Fu
7UyBubDCelxKTbnj26EwbochltRqGIE8hbwSXEzRNo4g
+NXkaRMq2FFbaBtEE82yTmZUgFRYAFUvfGTPWblyZGtk
epVuHyNb0w/u24dpsz+uyCZZR04cHfRrWOKvqD3lDOwC
4+sqd6f7F841R0N2tqSh/WDUZzWdvPBaBOz0FWFLb9po
rIeZ3Jm08tAMHa+3SGRXfK4RAmxVCmIQQypGabE=
) ; ZSK; alg = RSASHA256 ; key id = 60955
.   92475 IN RRSIG DNSKEY 8 0 172800 (
2023050200 2023041100 20326 .
ID/zjsZ8MPaJMm4Ilw9PESU92a/MvPFKlKkE8d2qAbDV
fMGYQikmls8z0fIorVfoGECgiEey42+Y4Bk99qTEFxPr
Cml12/xyJcmzQICQcr28djuMMA+yY7w57GuRLkE+LTnl
5IdlucNf52gS/eKSBIjKH3hNYElH6BwIbTHKV5Jh1ZJg
FTo+FRtrniR4HlhhHaydDVLc2A8FG3Whl1kyATDlqcLr
F6yqbjAhNR0+Ak26gd5BkY9kwOYCMZ2KQ1RBKRmG3Dbk
tohYVHbH2j6B6kfIjooRwY5hWyNQnBZP6LOHQLyfYrUT
R3EK438G9VW0tXvNqL3ssDhuxhbFy7x3hw== )

;; Query time: 0 msec
;; SERVER: 193.136.66.1#53(193.136.66.1)
;; WHEN: Fri Apr 14 09:36:50 WEST 2023
;; MSG SIZE  rcvd: 893

Outside tests also seem to be ok. Didn't find anything yet in the logs.
 I will compare (again) my named.conf on the primary and secondary server to 
find why dnssec-validation needs to be off on the primary.

Thanks!
David



-Original Message-
From: Mark Andrews  
Sent: 14 April 2023 02:35
To: David Carvalho 
Cc: Evan Hunt ; bind-users@lists.isc.org
Subject: Re: dnssec-validation?



> On 13 Apr 2023, at 19:23, David Carvalho via bind-users 
>  wrote:
> 
> Hello and thank you for the reply.
> My domain is "di.ubi.pt". The parent domain "ubi.pt" recently 
> configured DNSSEC (BIND 9.11) so it was time again for me to try to 
> set it up for my domain.
> 
> A few months ago I updated both dns servers to Oracle Linux 8, running 
> BIND
> 9.16.23 to prepare for this.
> They seem to be working fine as previously, running as both recursive 
> and authoritative for di.ubi.pt.
> 
> DNS2 has still "dnssec-validation auto;" on its  /etc/named.conf.
> I've found out that if I wanted my primary server to start answering 
> my internal requests for outside "di.ubi.pt" I had to change 
> dnssec-validation to "no".
> I still don't understand why, to be honest.

Look at your logs.  If named is having problems it will be logging error 
messages.

What does "rndc managed-keys status” report?

% rndc managed-keys status
view: secure
next scheduled event: Fri, 14 Apr 2023 02

Re: dnssec-validation?

[Mark Andrews]

> On 13 Apr 2023, at 19:23, David Carvalho via bind-users 
>  wrote:
> 
> Hello and thank you for the reply.
> My domain is "di.ubi.pt". The parent domain "ubi.pt" recently configured
> DNSSEC (BIND 9.11) so it was time again for me to try to set it up for my
> domain.
> 
> A few months ago I updated both dns servers to Oracle Linux 8, running BIND
> 9.16.23 to prepare for this.
> They seem to be working fine as previously, running as both recursive and
> authoritative for di.ubi.pt.
> 
> DNS2 has still "dnssec-validation auto;" on its  /etc/named.conf.
> I've found out that if I wanted my primary server to start answering my
> internal requests for outside "di.ubi.pt" I had to change dnssec-validation
> to "no".
> I still don't understand why, to be honest.

Look at your logs.  If named is having problems it will be logging
error messages.

What does "rndc managed-keys status” report?

% rndc managed-keys status
view: secure
next scheduled event: Fri, 14 Apr 2023 02:04:19 GMT

name: .
keyid: 20326
algorithm: RSASHA256
flags: SEP
next refresh: Sat, 15 Apr 2023 00:53:04 GMT
trusted since: Fri, 11 Aug 2017 01:07:03 GMT

view: forward
next scheduled event: Fri, 14 Apr 2023 02:04:19 GMT

name: .
keyid: 20326
algorithm: RSASHA256
flags: SEP
next refresh: Sat, 15 Apr 2023 00:53:04 GMT
trusted since: Tue, 10 May 2022 05:09:01 GMT

view: external
next scheduled event: Fri, 14 Apr 2023 03:04:19 GMT

name: .
keyid: 20326
algorithm: RSASHA256
flags: SEP
next refresh: Fri, 14 Apr 2023 03:04:19 GMT
trusted since: Thu, 10 Aug 2017 13:01:30 GMT
% 

Are you using a forwarder?  Does the forwarder support DNSSEC?

Do you have an overly restrictive firewall?

What does “dig +cd +dnssec +multi . DNSKEY” return?

% dig +cd +dnssec +multi . DNSKEY
;; BADCOOKIE, retrying.

; <<>> DiG 9.19.11-dev <<>> +cd +dnssec +multi . DNSKEY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10255
;; flags: qr rd ra ad cd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 9c2f2034f253efff01006438ad22999ed76ba1835477 (good)
;; QUESTION SECTION:
;. IN DNSKEY

;; ANSWER SECTION:
. 88321 IN DNSKEY 257 3 8 (
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN
7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5
LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8
efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7
pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY
A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws
9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
) ; KSK; alg = RSASHA256 ; key id = 20326
. 88321 IN DNSKEY 256 3 8 (
AwEAAbF1LAxEQPtClEQno48k6u7JjCOfVfwdENOxQUrX
0JbpN5DnKGMAKIfdiWa5oDeKQ3OoQ58yCC8vjtaaGFDg
pJxoLwqzhBYHPGFgins5HIERcCQPGAJKWu/ku4XLh+Fu
7UyBubDCelxKTbnj26EwbochltRqGIE8hbwSXEzRNo4g
+NXkaRMq2FFbaBtEE82yTmZUgFRYAFUvfGTPWblyZGtk
epVuHyNb0w/u24dpsz+uyCZZR04cHfRrWOKvqD3lDOwC
4+sqd6f7F841R0N2tqSh/WDUZzWdvPBaBOz0FWFLb9po
rIeZ3Jm08tAMHa+3SGRXfK4RAmxVCmIQQypGabE=
) ; ZSK; alg = RSASHA256 ; key id = 60955
. 88321 IN RRSIG DNSKEY 8 0 172800 (
2023050200 2023041100 20326 .
ID/zjsZ8MPaJMm4Ilw9PESU92a/MvPFKlKkE8d2qAbDV
fMGYQikmls8z0fIorVfoGECgiEey42+Y4Bk99qTEFxPr
Cml12/xyJcmzQICQcr28djuMMA+yY7w57GuRLkE+LTnl
5IdlucNf52gS/eKSBIjKH3hNYElH6BwIbTHKV5Jh1ZJg
FTo+FRtrniR4HlhhHaydDVLc2A8FG3Whl1kyATDlqcLr
F6yqbjAhNR0+Ak26gd5BkY9kwOYCMZ2KQ1RBKRmG3Dbk
tohYVHbH2j6B6kfIjooRwY5hWyNQnBZP6LOHQLyfYrUT
R3EK438G9VW0tXvNqL3ssDhuxhbFy7x3hw== )

;; Query time: 0 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Fri Apr 14 11:32:18 AEST 2023
;; MSG SIZE  rcvd: 892

% 

> Yesterday I set dnssec-validation to auto on my primary server, but as I
> wrote before, although outside tools showed everything was fine, my server
> kept answering "SERVFAIL" to my client queries. I don't think I tested
> dnssec-validation to no when dnssec was enabled, nor if this makes much
> sense, but I can try.
> 
> Kind regards
> David 
> 
> 
> 
> 
> 
> 
> On Wed, Apr 12, 2023 at 05:41:33PM +0100, David Carvalho via bind-users
> wrote:
>> After reverting my primary dns configuration, and asking my provider 
>> to remove the DNSKEY, I had to include dnssec-validation no; otherwise 
>> it would keep answering with SERVFAIL
>> 
>> I noticed the server was constantly trying to reach top domain dns
> servers.
>> 
>> Is this dnssec-validation mandatory? Any help appreciated.
> 
> dnssec-validation can be set three ways:
> - "no" (validation is never performed)
> - "yes" (validation *may* be performed, but only if you have also
>   configured a trust anchor in named.conf)
> - "auto" (validation will be performed using the standard root zone
>   trust anchor, which is built in to BIND and doesn't need to be
>   configured by hand).
> 
> The default is "auto". When it's set to that, your server will query the
> root name servers in order to confirm that the automatically-configured
> trust anchor is correct.  You said it was "trying to" reach the root, 

RE: dnssec-validation?

[David Carvalho via bind-users]

Hello and thank you for the reply.
Problem 1 - I'll have to investigate further.

As for problem 2 ... it's weird.
I was working on another thing and now I was checking permissions by your
suggestion, when I noticed the files have new timestamp from a while ago.
I compared the contents of the updated files with a previous backup and they
seem the same.

Tests such as https://dnssec-analyzer.verisignlabs.com/di.ubi.pt
also seem to be still fine. 

So, my conclusion is: 
Named changes the Kdi.ubi.pt** timestamps according to some criteria.

If I do a systemctl restart named-chroot or rdnc reload, the contents also
change (and according to a response I got earlier this is a bug solved in
version 9.16.30)
I've been told to upgrade to version 9.18 and I'm setting a test server to
do this. 
In the meantime, if there is a way to avoid the keys to be rewritten every
time I reconfigure and reload, I would stick with this version.

Regards
David



-Original Message-
From: Evan Hunt  
Sent: 13 April 2023 18:08
To: David Carvalho 
Cc: bind-users@lists.isc.org
Subject: Re: dnssec-validation?

On Thu, Apr 13, 2023 at 11:38:15AM +0100, David Carvalho wrote:
> Problem number 1: Dnssec seems to be running on "di.ubi.pt", but 
> dnssec-validation still needs to be set to no; Will this cause troubles?
> Dns2 is set to auto and runs fine.

>From here, di.ubt.pt appears to be properly signed and everything's 
>working
from here. Turning off validation won't have any affect on that. Your only
problem is with local recursive service.

> Problem number 2: How can I avoid the key regeneration (using version
> 9.16.23) every named restart?

I'm not certain what you mean by key regeneration.

Taking a stab in the dark: Check that the working directory for named is
writable. If named can't write files, then it can't save trust anchor status
across restarts and it has to reinitialize each time.

If that doesn't turn out to be the problem, then can show me the relevant
lines from your log file so I can see what you're referring to by "key
regeneration"?

--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-validation?

[Evan Hunt]

On Thu, Apr 13, 2023 at 11:38:15AM +0100, David Carvalho wrote:
> Problem number 1: Dnssec seems to be running on "di.ubi.pt", but
> dnssec-validation still needs to be set to no; Will this cause troubles?
> Dns2 is set to auto and runs fine.

>From here, di.ubt.pt appears to be properly signed and everything's working
from here. Turning off validation won't have any affect on that. Your only
problem is with local recursive service.

> Problem number 2: How can I avoid the key regeneration (using version
> 9.16.23) every named restart?

I'm not certain what you mean by key regeneration.

Taking a stab in the dark: Check that the working directory for named
is writable. If named can't write files, then it can't save trust anchor
status across restarts and it has to reinitialize each time.

If that doesn't turn out to be the problem, then can show me the
relevant lines from your log file so I can see what you're referring to
by "key regeneration"?

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: dnssec-validation?

[David Carvalho via bind-users]

Hello again.

Problem number 1: Dnssec seems to be running on "di.ubi.pt", but
dnssec-validation still needs to be set to no; Will this cause troubles?
Dns2 is set to auto and runs fine.
Problem number 2: How can I avoid the key regeneration (using version
9.16.23) every named restart?


Kind regards,
David Carvalho


-Original Message-
From: Evan Hunt  
Sent: 12 April 2023 18:08
To: David Carvalho 
Cc: bind-users@lists.isc.org
Subject: Re: dnssec-validation?

On Wed, Apr 12, 2023 at 05:41:33PM +0100, David Carvalho via bind-users
wrote:
> After reverting my primary dns configuration, and asking my provider 
> to remove the DNSKEY, I had to include dnssec-validation no; otherwise 
> it would keep answering with SERVFAIL
> 
> I noticed the server was constantly trying to reach top domain dns
servers.
> 
> Is this dnssec-validation mandatory? Any help appreciated.

dnssec-validation can be set three ways:
 - "no" (validation is never performed)
 - "yes" (validation *may* be performed, but only if you have also
   configured a trust anchor in named.conf)
 - "auto" (validation will be performed using the standard root zone
   trust anchor, which is built in to BIND and doesn't need to be
   configured by hand).

The default is "auto". When it's set to that, your server will query the
root name servers in order to confirm that the automatically-configured
trust anchor is correct.  You said it was "trying to" reach the root, which
suggests it wasn't succeeding?  If so, that would explain why everything
that wasn't locally authoritative would return SERVFAIL.

Note that this is related to *recursive* queries, that is, queries for zones
that are not served by your secondary server.  It should have nothing to do
with whether your own domain is signed, or whether there's a DS record for
it in the parent zone. My guess is, you had the authoritative configuration
working fine (otherwise presumably dnssec-analyzer would've complained), but
recursive isn't working.

Unfortunately, since you haven't provided any configuration info or even the
name of the domain you were trying to set up, I can't make any more educated
guesses than that.

--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: dnssec-validation?

[David Carvalho via bind-users]

Hello and thank you for the reply.
My domain is "di.ubi.pt". The parent domain "ubi.pt" recently configured
DNSSEC (BIND 9.11) so it was time again for me to try to set it up for my
domain.

A few months ago I updated both dns servers to Oracle Linux 8, running BIND
9.16.23 to prepare for this.
They seem to be working fine as previously, running as both recursive and
authoritative for di.ubi.pt.

DNS2 has still "dnssec-validation auto;" on its  /etc/named.conf.
I've found out that if I wanted my primary server to start answering my
internal requests for outside "di.ubi.pt" I had to change dnssec-validation
to "no".
I still don't understand why, to be honest.

Yesterday I set dnssec-validation to auto on my primary server, but as I
wrote before, although outside tools showed everything was fine, my server
kept answering "SERVFAIL" to my client queries. I don't think I tested
dnssec-validation to no when dnssec was enabled, nor if this makes much
sense, but I can try.

Kind regards
David 






On Wed, Apr 12, 2023 at 05:41:33PM +0100, David Carvalho via bind-users
wrote:
> After reverting my primary dns configuration, and asking my provider 
> to remove the DNSKEY, I had to include dnssec-validation no; otherwise 
> it would keep answering with SERVFAIL
> 
> I noticed the server was constantly trying to reach top domain dns
servers.
> 
> Is this dnssec-validation mandatory? Any help appreciated.

dnssec-validation can be set three ways:
 - "no" (validation is never performed)
 - "yes" (validation *may* be performed, but only if you have also
   configured a trust anchor in named.conf)
 - "auto" (validation will be performed using the standard root zone
   trust anchor, which is built in to BIND and doesn't need to be
   configured by hand).

The default is "auto". When it's set to that, your server will query the
root name servers in order to confirm that the automatically-configured
trust anchor is correct.  You said it was "trying to" reach the root, which
suggests it wasn't succeeding?  If so, that would explain why everything
that wasn't locally authoritative would return SERVFAIL.

Note that this is related to *recursive* queries, that is, queries for zones
that are not served by your secondary server.  It should have nothing to do
with whether your own domain is signed, or whether there's a DS record for
it in the parent zone. My guess is, you had the authoritative configuration
working fine (otherwise presumably dnssec-analyzer would've complained), but
recursive isn't working.

Unfortunately, since you haven't provided any configuration info or even the
name of the domain you were trying to set up, I can't make any more educated
guesses than that.

--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-validation?

[Evan Hunt]

On Wed, Apr 12, 2023 at 05:41:33PM +0100, David Carvalho via bind-users wrote:
> After reverting my primary dns configuration, and asking my provider to
> remove the DNSKEY, I had to include dnssec-validation no; otherwise it would
> keep answering with SERVFAIL
> 
> I noticed the server was constantly trying to reach top domain dns servers.
> 
> Is this dnssec-validation mandatory? Any help appreciated.

dnssec-validation can be set three ways:
 - "no" (validation is never performed)
 - "yes" (validation *may* be performed, but only if you have also
   configured a trust anchor in named.conf)
 - "auto" (validation will be performed using the standard root zone
   trust anchor, which is built in to BIND and doesn't need to be
   configured by hand).

The default is "auto". When it's set to that, your server will query the
root name servers in order to confirm that the automatically-configured
trust anchor is correct.  You said it was "trying to" reach the root, which
suggests it wasn't succeeding?  If so, that would explain why everything
that wasn't locally authoritative would return SERVFAIL.

Note that this is related to *recursive* queries, that is, queries for
zones that are not served by your secondary server.  It should have nothing
to do with whether your own domain is signed, or whether there's a DS
record for it in the parent zone. My guess is, you had the authoritative
configuration working fine (otherwise presumably dnssec-analyzer would've
complained), but recursive isn't working.

Unfortunately, since you haven't provided any configuration info or even
the name of the domain you were trying to set up, I can't make any more
educated guesses than that.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation via AD bit?

[Petr Špaček]

On 31. 01. 22 11:50, Tony Finch wrote:

2. Should sendmail not be trusting the AD bit in replies from the admin
configured (i.e., trusted by admin) resolvers?

It's dangerous territory. Sendmail isn't alone: for example, OpenSSH also
relies on the AD bit to validate SSHFP records. But using AD is only safe
if the validating resolver is running on localhost. Unfortunately the
portable subset of the resolver API doesn't allow programs to check their
recursive server addresses, so they just have to hope that they have been
configured by a careful person. (On a mail server there are also
performance reasons for running a local resolver, so I guess you are OK in
this respect.)


Let me add one more detail. To make this more explicit, glibc since 2.31 
added "options trust-ad" into resolv.conf. See 
https://man7.org/linux/man-pages/man5/resolv.conf.5.html and search for 
trust-ad.


I hope it helps.

--
Petr Špaček  @  Internet Systems Consortium
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation via AD bit?

[Tony Finch]

Gregory Shapiro via bind-users  wrote:
>
> Two questions:

Slightly expanding on Mark's answers...

> 1. Is there a reason when BIND is running as both a recursive server and
> an authoritative server for a domain, it doesn't set the AD bit when
> answering resolver queries for one of its authoritative domains?

AD means "I validated this" and AA means "I am authoritative for this".
In almost all cases, authoritative servers don't validate the zones they
serve - as Mark said, it's unnecessary. Because they don't validate it
would be wrong to set AD. (But note that BIND's "mirror" zones do validate
authoritative zones and the AD/AA bits change accordingly.)

> 2. Should sendmail not be trusting the AD bit in replies from the admin
> configured (i.e., trusted by admin) resolvers?

It's dangerous territory. Sendmail isn't alone: for example, OpenSSH also
relies on the AD bit to validate SSHFP records. But using AD is only safe
if the validating resolver is running on localhost. Unfortunately the
portable subset of the resolver API doesn't allow programs to check their
recursive server addresses, so they just have to hope that they have been
configured by a careful person. (On a mail server there are also
performance reasons for running a local resolver, so I guess you are OK in
this respect.)

As Mark says, ideally these programs would do their own validation, but to
get good performance the program should ideally be able to make concurrent
queries for the chain of trust, and once again the standard resolver makes
it difficult. Or the program can hope the recursive server is running on
localhost so it doesn't matter too much if the queries are serialized.

There are workarounds for your AA problem. You might try using mirror
zones instead of secondary zones. Or you can ensure that queries for your
secondary zones go through a validating resolver. This is a bit like the
common pairing of NSD and Unbound on the same server, but with BIND you
can do it in one process. The trick is to use two views: one is
authoritative-only, and has your secondary zone configurations. The other
is recursive-only, but it has static-stub zone configurations for all your
secondary zones, pointing at localhost. Then you arrange for these
self-queries to be handled by the authoritative view. I have used this
setup for a while on my workstation for testing / experimental purposes,
but I never put it into serious production because it's too far along the
mad science spectrum.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Thames: Northwest 7 to severe gale 9, backing west 5 to 7. Slight or
moderate in southwest, otherwise rough or very rough, becoming
moderate. Rain. Good, occasionally moderate.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation via AD bit?

[Mark Andrews]

> On 31 Jan 2022, at 10:45, Gregory Shapiro via bind-users 
>  wrote:
> 
> sendmail's implementation of DANE determines whether DNSSEC validation was 
> successful based on the presence of the AD bit in the response to the DANE 
> record lookup.  
> 
> An equivalent dig lookup would be:
> 
>% dig TLSA _25._tcp.smtp.gshapiro.net.
>...
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 160
>;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>...
>; ANSWER SECTION:
>_25._tcp.smtp.gshapiro.net. 5   IN  TLSA3 1 1 
> 8B2B0BF34A1D650A91399A28D5E6BBF377FB5319E9850078538164F5 557CD5BA
> 
> As you can see above the flags returned include "ad".
> 
> However, if sendmail is run on a server that lists the authoritative 
> nameserver for a domain as a resolver (/etc/resolv.conf), the AD bit is not 
> returned for lookups of those authoritative domains.  For example, when 
> running the above dig command pointing at ns.gshapiro.net (running BIND 
> 9.16.24), the AD bit is not returned:
> 
>> dig TLSA _25._tcp.smtp.gshapiro.net. @ns.gshapiro.net
>...
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45940
>;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>...
>;; ANSWER SECTION:
>_25._tcp.smtp.gshapiro.net. 120 IN  TLSA3 1 1 
> 8B2B0BF34A1D650A91399A28D5E6BBF377FB5319E9850078538164F5 557CD5BA
> 
> Two questions:
> 
> 1. Is there a reason when BIND is running as both a recursive server and an 
> authoritative server for a domain, it doesn't set the AD bit when answering 
> resolver queries for one of its authoritative domains?

Because it is not required.  Validation really should be performed by the 
application as well as the resolver.

You can use views to have named return AD for locally served zones.

> 2. Should sendmail not be trusting the AD bit in replies from the admin 
> configured (i.e., trusted by admin) resolvers?  I.e., should sendmail be 
> doing something different for DANE DNSSEC validation?  Note that DANE doesn't 
> allow for treating the authoritative server differently so I don't believe we 
> can use the AA bit as a substitute for the AD bit.

It should be performing its own validation.  DNSSEC validation was intended to 
be done by applications from the very beginning.  Also look at all the caveats 
about using AD.  Are you using transport security to protect the AD state?  
Have you checked that AD is not being copied from the request to the reply as 
there are lots of broken DNS servers that do this.  AD is a useful diagnostic 
signal but really shouldn’t be used for much more.

> Thanks!
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Dnssec-validation auto

[Ismael Suarez]

resolv.conf has only itself as dns server

When using dnssec-validation AUTO, and turning on debug, the following is shown 
when I nslookup from my PC towards the server.



13-Nov-2020 11:09:18.998 client @0x7f7fb41d6b20 xxx.xxx.xxx.252#30201: request 
is not signed

13-Nov-2020 11:09:18.998 client @0x7f7fb41d6b20 xxx.xxx.xxx.252#30201: 
recursion available

13-Nov-2020 11:09:18.998 client @0x7f7fb41d6b20 xxx.xxx.xxx.252#30201 
(www.popularsba.com): query: www.popularsba.com IN A + (xxx.xxx.xxx.152)

13-Nov-2020 11:09:18.998 client @0x7f7fb41d6b20 xxx.xxx.xxx.252#30201 
(www.popularsba.com): query (cache) 'www.popularsba.com/A/IN' approved

13-Nov-2020 11:09:18.998 fetch: www.popularsba.com/A

13-Nov-2020 11:09:18.999 fetch: ha1.markmonitor.zone/A

13-Nov-2020 11:09:18.999 fetch: ha2.markmonitor.zone/A

13-Nov-2020 11:09:18.999 fetch: ha3.markmonitor.zone/A

13-Nov-2020 11:09:18.999 fetch: ha4.markmonitor.zone/A

13-Nov-2020 11:09:24.000 client @0x7f7fb41f3a40 xxx.xxx.xxx.252#30201: request 
is not signed

13-Nov-2020 11:09:24.000 client @0x7f7fb41f3a40 xxx.xxx.xxx.252#30201: 
recursion available

13-Nov-2020 11:09:24.000 client @0x7f7fb41f3a40 xxx.xxx.xxx.252#30201 
(www.popularsba.com): query: www.popularsba.com IN A + (xxx.xxx.xxx.152)

13-Nov-2020 11:09:24.000 client @0x7f7fb41f3a40 xxx.xxx.xxx.252#30201 
(www.popularsba.com): query (cache) 'www.popularsba.com/A/IN' approved

13-Nov-2020 11:09:24.000 fetch: www.popularsba.com/A

13-Nov-2020 11:09:24.000 client @0x7f7fb41f3a40 xxx.xxx.xxx.252#30201 
(www.popularsba.com): request failed: duplicate query

13-Nov-2020 11:09:27.051 fetch: popularsba.com/DS



On my client I get:

** server can't find www.popularsba.com: SERVFAIL



masked the IP just in case



-Original Message-
From: Petr Menšík 
mailto:petr%20%3d%3futf-8%3fq%3fmen%3dc5%3da1%3dc3%3dadk%3f%3d%20%3cpemen...@redhat.com%3e>>
To: Ismael Suarez 
mailto:ismael%20suarez%20%3cismael_sua...@coqui.com%3e>>,
 bind-users@lists.isc.org 
mailto:%22bind-us...@lists.isc.org%22%20%3cbind-us...@lists.isc.org%3e>>
Subject: Re: Dnssec-validation auto
Date: Fri, 13 Nov 2020 14:19:47 +0100


I would check what nameservers are in /etc/resolv.conf, and try to

direct delv or dig to its address.


for H in $(awk '$1 == "nameserver" { print $2 }' /etc/resolv.conf); do

dig +dnssec @$H

<http://www.popularsba.com>

www.popularsba.com

; done


Check every server returns reliable and the same results. I had one

NOERROR and one SERVFAIL from our instrastructure. The second server

provides more servers in ADDITIONAL section. Second retry was successful.


It might take a bit more time to fetch and verify addresses of all

authoritative servers of gslb.siteforce.com. domain. Six seems a lot.



; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8 <<>> +dnssec @10.5.30.45

<http://www.popularsba.com>

www.popularsba.com


; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43145

;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 6, ADDITIONAL: 13


;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags: do; udp: 4096

;; QUESTION SECTION:

;www.popularsba.com.IN  A


;; ANSWER SECTION:

<http://www.popularsba.com>

www.popularsba.com

.   262 IN  CNAME

<http://www.popularsba.com.00d1n02kxqqua0.live.siteforce.com>

www.popularsba.com.00d1n02kxqqua0.live.siteforce.com

.

<http://www.popularsba.com.00d1n02kxqqua0.live.siteforce.com>

www.popularsba.com.00d1n02kxqqua0.live.siteforce.com

. 262 IN CNAME

4.0p13m008e6qcaq.00d1n02kxqqua0.gslb.siteforce.com.

4.0p13m008e6qcaq.00d1n02kxqqua0.gslb.siteforce.com. 82 IN A

13.109.220.200


;; AUTHORITY SECTION:

gslb.siteforce.com. 55886   IN  NS  dns05.salesforce.com.

gslb.siteforce.com. 55886   IN  NS  dns01.salesforce.com.

gslb.siteforce.com. 55886   IN  NS  dns02.salesforce.com.

gslb.siteforce.com. 55886   IN  NS  dns04.salesforce.com.

gslb.siteforce.com. 55886   IN  NS  dns06.salesforce.com.

gslb.siteforce.com. 55886   IN  NS  dns03.salesforce.com.


;; ADDITIONAL SECTION:

dns01.salesforce.com.   53547   IN  A   204.74.108.235

dns02.salesforce.com.   53547   IN  A   204.74.109.235

dns04.salesforce.com.   53547   IN  A   199.7.69.235

dns03.salesforce.com.   53547   IN  A   199.7.68.235

dns06.salesforce.com.   53547   IN  A   204.74.115.235

dns05.salesforce.com.   53547   IN  A   204.74.114.235

dns01.salesforce.com.   53547   IN  RRSIG   A 13 3 86400 20201130021251

20201001013506 2317 salesforce.com.

fUb+1uVGcdeVSsjTj1O++bcNLZwapzTvLcHLP+tykm3y3ziCSIHtxfCp

3kZqdBQtB3nGd7ySGPEblvBJA4ZHUA==

dns02.salesforce.com.   53547   IN  RRSIG   A 13 3 86400 20201130021251

20201001013506 2317 salesforce.com.

QOVhwrJ0dwkHRHLr/ytEzmZ04bY

Re: Dnssec-validation auto

[Petr Menšík]

I would check what nameservers are in /etc/resolv.conf, and try to
direct delv or dig to its address.

for H in $(awk '$1 == "nameserver" { print $2 }' /etc/resolv.conf); do
dig +dnssec @$H www.popularsba.com; done

Check every server returns reliable and the same results. I had one
NOERROR and one SERVFAIL from our instrastructure. The second server
provides more servers in ADDITIONAL section. Second retry was successful.

It might take a bit more time to fetch and verify addresses of all
authoritative servers of gslb.siteforce.com. domain. Six seems a lot.


; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8 <<>> +dnssec @10.5.30.45
www.popularsba.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43145
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 6, ADDITIONAL: 13

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.popularsba.com.IN  A

;; ANSWER SECTION:
www.popularsba.com. 262 IN  CNAME
www.popularsba.com.00d1n02kxqqua0.live.siteforce.com.
www.popularsba.com.00d1n02kxqqua0.live.siteforce.com. 262 IN CNAME
4.0p13m008e6qcaq.00d1n02kxqqua0.gslb.siteforce.com.
4.0p13m008e6qcaq.00d1n02kxqqua0.gslb.siteforce.com. 82 IN A
13.109.220.200

;; AUTHORITY SECTION:
gslb.siteforce.com. 55886   IN  NS  dns05.salesforce.com.
gslb.siteforce.com. 55886   IN  NS  dns01.salesforce.com.
gslb.siteforce.com. 55886   IN  NS  dns02.salesforce.com.
gslb.siteforce.com. 55886   IN  NS  dns04.salesforce.com.
gslb.siteforce.com. 55886   IN  NS  dns06.salesforce.com.
gslb.siteforce.com. 55886   IN  NS  dns03.salesforce.com.

;; ADDITIONAL SECTION:
dns01.salesforce.com.   53547   IN  A   204.74.108.235
dns02.salesforce.com.   53547   IN  A   204.74.109.235
dns04.salesforce.com.   53547   IN  A   199.7.69.235
dns03.salesforce.com.   53547   IN  A   199.7.68.235
dns06.salesforce.com.   53547   IN  A   204.74.115.235
dns05.salesforce.com.   53547   IN  A   204.74.114.235
dns01.salesforce.com.   53547   IN  RRSIG   A 13 3 86400 20201130021251
20201001013506 2317 salesforce.com.
fUb+1uVGcdeVSsjTj1O++bcNLZwapzTvLcHLP+tykm3y3ziCSIHtxfCp
3kZqdBQtB3nGd7ySGPEblvBJA4ZHUA==
dns02.salesforce.com.   53547   IN  RRSIG   A 13 3 86400 20201130021251
20201001013506 2317 salesforce.com.
QOVhwrJ0dwkHRHLr/ytEzmZ04bYaAzN2ooDfJOVJXDCinYGFuNTRmPhs
uFawDGlRlFja8OyiIyJXIFvwXKGSxg==
dns04.salesforce.com.   53547   IN  RRSIG   A 13 3 86400 20201130021251
20201001013506 2317 salesforce.com.
DXOOYz5odrnY7SkWNvU0NiGOZEWalNT+0VYCYgd7wl6Rj0cOR4slFrvR
ADj5eAgFLybADvTviia/xbqz4u7ueQ==
dns03.salesforce.com.   53547   IN  RRSIG   A 13 3 86400 20201130021251
20201001013506 2317 salesforce.com.
Rkzv/z9vhnURB8hueZgkQrKFffLB9Zj423ZPHoPXtoECxNVk/ZV/ODv4
BQZLT8+t8W7cLILNyXVVpEjG2ejE9Q==
dns06.salesforce.com.   53547   IN  RRSIG   A 13 3 86400 20201218220609
20201019213201 2317 salesforce.com.
YcTDijezumyiv+WZcvZqFk/yOJ2r7WdxZ5XFwIjt5R6iDOSQNChxhQ3G
dhR28sLna+rM9yVehyyEyCh4iJUeHg==
dns05.salesforce.com.   53547   IN  RRSIG   A 13 3 86400 20201130021251
20201001013506 2317 salesforce.com.
gmzIaK0lTolbkUaIGfHTLl2+TzUYQUtxHJ5yevEzdLmaE8z0AW7JBVXf
07osroe/7LxRQO38ZCxNZHVXfQnMHA==

;; Query time: 45 msec
;; SERVER: 10.5.30.45#53(10.5.30.45)
;; WHEN: Fri Nov 13 08:12:49 EST 2020
;; MSG SIZE  rcvd: 1076


It seems to me, only dns0?.salesforce.com. hosts are in DNSSEC signed
domain. Try debuging salesforce.com. domain verification instead.

On 11/13/20 1:59 PM, Ismael Suarez wrote:
> With "dnssec-validation AUTO;" I get:
> 
> # delv +cd www.popularsba.com
> ;; resolution failed: timed out
> 
> 
> With "dnssec-validation NO;" I get:
> 
> # delv +cd www.popularsba.com
> ;; resolution failed: timed out
> ; unsigned answer
> www.popularsba.com. 279 IN  CNAME   
> www.popularsba.com.00d1n02kxqqua0.live.siteforce.com.
> 
> 
> CAPS just to show the difference in .conf
> 
> 
> --
> 
> Ismael Suárez Maldonado | UNIX ADM | Coqui.Net Corp / ClaroTV
> ismael_sua...@coqui.com<mailto:ismael_sua...@coqui.com> | T: 787-793-0001 x 
> 4007
> 
> -Original Message-
> From: Petr Menšík 
> mailto:petr%20%3d%3futf-8%3fq%3fmen%3dc5%3da1%3dc3%3dadk%3f%3d%20%3cpemen...@redhat.com%3e>>
> To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
> Subject: Re: Dnssec-validation auto
> Date: Fri, 13 Nov 2020 11:26:17 +0100
> 
> 
> Hi Ismael,
> 
> 
> easiest way to check validation is using delv tool from BIND 9.11+. It
> 
> uses the same algorithm as BIND server does. If you get SERVFAIL from
> 
> your recursive server, try adding +cd parameter to delv or dig. When it
> 
> works with +cd

Re: Dnssec-validation auto

[Ismael Suarez]

With "dnssec-validation AUTO;" I get:

# delv +cd www.popularsba.com
;; resolution failed: timed out


With "dnssec-validation NO;" I get:

# delv +cd www.popularsba.com
;; resolution failed: timed out
; unsigned answer
www.popularsba.com. 279 IN  CNAME   
www.popularsba.com.00d1n02kxqqua0.live.siteforce.com.


CAPS just to show the difference in .conf


--

Ismael Suárez Maldonado | UNIX ADM | Coqui.Net Corp / ClaroTV
ismael_sua...@coqui.com<mailto:ismael_sua...@coqui.com> | T: 787-793-0001 x 4007

-Original Message-
From: Petr Menšík 
mailto:petr%20%3d%3futf-8%3fq%3fmen%3dc5%3da1%3dc3%3dadk%3f%3d%20%3cpemen...@redhat.com%3e>>
To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: Re: Dnssec-validation auto
Date: Fri, 13 Nov 2020 11:26:17 +0100


Hi Ismael,


easiest way to check validation is using delv tool from BIND 9.11+. It

uses the same algorithm as BIND server does. If you get SERVFAIL from

your recursive server, try adding +cd parameter to delv or dig. When it

works with +cd, validation is responsible somewhere in recursive servers

chain.


It shows just unsigned to me, today.


$ delv +cd

<http://www.popularsba.com>

www.popularsba.com


; unsigned answer

<http://www.popularsba.com>

www.popularsba.com

.   282 IN  CNAME

<http://www.popularsba.com.00d1n02kxqqua0.live.siteforce.com>

www.popularsba.com.00d1n02kxqqua0.live.siteforce.com

.

<http://www.popularsba.com.00d1n02kxqqua0.live.siteforce.com>

www.popularsba.com.00d1n02kxqqua0.live.siteforce.com

. 282 IN CNAME

4.0p13m008e6qcaq.00d1n02kxqqua0.gslb.siteforce.com.

4.0p13m008e6qcaq.00d1n02kxqqua0.gslb.siteforce.com. 102 IN A

161.71.31.253


Cheers,

Petr


On 11/13/20 5:26 AM, Ismael Suarez wrote:

Hi all


The following domain (

<http://www.popularsba.com>

www.popularsba.com

) does not resolve with dnssec validation set to auto, but when I change the 
validation off it works.


Why is this? How can I check this validation?


Using bind 9.12


Thanks to all

___

Please visit

<https://lists.isc.org/mailman/listinfo/bind-users>

https://lists.isc.org/mailman/listinfo/bind-users

 to unsubscribe from this list


ISC funds the development of this software with paid support subscriptions. 
Contact us at

<https://www.isc.org/contact/>

https://www.isc.org/contact/

 for more information.



bind-users mailing list

<mailto:bind-users@lists.isc.org>

bind-users@lists.isc.org


<https://lists.isc.org/mailman/listinfo/bind-users>

https://lists.isc.org/mailman/listinfo/bind-users




___

Please visit

<https://lists.isc.org/mailman/listinfo/bind-users>

https://lists.isc.org/mailman/listinfo/bind-users

 to unsubscribe from this list


ISC funds the development of this software with paid support subscriptions. 
Contact us at

<https://www.isc.org/contact/>

https://www.isc.org/contact/

 for more information.



bind-users mailing list

<mailto:bind-users@lists.isc.org>

bind-users@lists.isc.org


<https://lists.isc.org/mailman/listinfo/bind-users>

https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Dnssec-validation auto

[Petr Menšík]

Hi Ismael,

easiest way to check validation is using delv tool from BIND 9.11+. It
uses the same algorithm as BIND server does. If you get SERVFAIL from
your recursive server, try adding +cd parameter to delv or dig. When it
works with +cd, validation is responsible somewhere in recursive servers
chain.

It shows just unsigned to me, today.

$ delv +cd www.popularsba.com
; unsigned answer
www.popularsba.com. 282 IN  CNAME
www.popularsba.com.00d1n02kxqqua0.live.siteforce.com.
www.popularsba.com.00d1n02kxqqua0.live.siteforce.com. 282 IN CNAME
4.0p13m008e6qcaq.00d1n02kxqqua0.gslb.siteforce.com.
4.0p13m008e6qcaq.00d1n02kxqqua0.gslb.siteforce.com. 102 IN A
161.71.31.253

Cheers,
Petr

On 11/13/20 5:26 AM, Ismael Suarez wrote:
> Hi all
> 
> The following domain (www.popularsba.com) does not resolve with dnssec 
> validation set to auto, but when I change the validation off it works.
> 
> Why is this? How can I check this validation?
> 
> Using bind 9.12
> 
> Thanks to all
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


OpenPGP_0x4931CA5B6C9FC5CB_and_old_rev.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation via DLV

[Mark Elkins]

That I understand. Use me (Posix) then, full DNSSEC support. 
https://vweb.co.za. If you like, run your DNS wherever you want, just 
use me at the Registrar.
Unfortunately, very few Registrars in ZA-Land have implemented DNSSEC 
support - despite ZA having a very high percentage of DNSSEC resolver 
support (about 50% of all queries hit a DNSSEC aware recursive resolver!)


On 2019/07/19 01:57, p...@vspace.co.za wrote:

By all means, not a difficult process at all. I have DNSSEC enabled and fully 
operational on .com domains.

Problem being, no options exist as to export the DS record of co.za, com.au or 
net.au domains to the respective registrars, being namecheap.com and 
axxess.co.za.

Noted that namecheap.com does accept the DS records for .com domains, yet not 
for .au domains.

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mal via 
bind-users
Sent: Thursday, 18 July 2019 10:22 PM
To: m...@posix.co.za; bind-users@lists.isc.org
Subject: Re: DNSSEC validation via DLV


Not a difficult process really..

-Configure a DNSSEC enabled name server
-Create a some zone keys (dnssec-keygen) -Sign your zone (dnssec-signzone) 
-Update your nameserver configuration to point to the signed zone file -Export 
your DS records (dsset) to the domain registration company (EPP).

Confirm the chain..   http://dnsviz.net/d/apnic.com.au/dnssec/

Mal



On 18/07/2019 4:46 pm, Mark Elkins wrote:

I  can't comment on com.au (but looking up the Nameservers, I see the
AD bit set - so DNSSEC appears to be in use..

However, co.za (and net.oza, org.za & web.za) which are managed by the
ZACR (and DNS) - they are all signed and I personally have domains
under these second levels - all running DNSSEC. The DS records are
added to the parents using EPP - and it works perfectly. I used to
present free (to the community) DNS classes to the community (the ZACR
paid me) and this (DNSSEC) was taught to attendees. Unfortunately, no
more classes for now.

DNSSEC in CO.ZA became live at about the time DLV stopped running. The
other SLD's had already been running for about a year.

For the record, EDU.ZA is also signed and can accept DS records -
albeit via a Web interface.

@peek - you are most welcome to chat to me.


On 2019/07/18 04:34, p...@vspace.co.za wrote:


With DLV (DNSSEC Lookaside Validation) having been decommissioned,
though zones still exists that does not provide a fully signed path
from root to zone, i.e. .com.au , co.za etc, how would an
administrator enable / implement DNSSEC validation for these zones ?


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


--
Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation via DLV

[Mal via bind-users]

On 19/07/2019 9:27 am, p...@vspace.co.za wrote:
> 
> Problem being, no options exist as to export the DS record of co.za, com.au 
> or net.au domains to the respective registrars, being namecheap.com and 
> axxess.co.za.
> 

Change registry right ?

Crazy domains supports them for the ".com.au" zone.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: DNSSEC validation via DLV

[peek]

By all means, not a difficult process at all. I have DNSSEC enabled and fully 
operational on .com domains.

Problem being, no options exist as to export the DS record of co.za, com.au or 
net.au domains to the respective registrars, being namecheap.com and 
axxess.co.za.

Noted that namecheap.com does accept the DS records for .com domains, yet not 
for .au domains.

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mal via 
bind-users
Sent: Thursday, 18 July 2019 10:22 PM
To: m...@posix.co.za; bind-users@lists.isc.org
Subject: Re: DNSSEC validation via DLV


Not a difficult process really..

-Configure a DNSSEC enabled name server
-Create a some zone keys (dnssec-keygen) -Sign your zone (dnssec-signzone) 
-Update your nameserver configuration to point to the signed zone file -Export 
your DS records (dsset) to the domain registration company (EPP).

Confirm the chain..   http://dnsviz.net/d/apnic.com.au/dnssec/

Mal



On 18/07/2019 4:46 pm, Mark Elkins wrote:
> I  can't comment on com.au (but looking up the Nameservers, I see the 
> AD bit set - so DNSSEC appears to be in use..
> 
> However, co.za (and net.oza, org.za & web.za) which are managed by the 
> ZACR (and DNS) - they are all signed and I personally have domains 
> under these second levels - all running DNSSEC. The DS records are 
> added to the parents using EPP - and it works perfectly. I used to 
> present free (to the community) DNS classes to the community (the ZACR 
> paid me) and this (DNSSEC) was taught to attendees. Unfortunately, no 
> more classes for now.
> 
> DNSSEC in CO.ZA became live at about the time DLV stopped running. The 
> other SLD's had already been running for about a year.
> 
> For the record, EDU.ZA is also signed and can accept DS records - 
> albeit via a Web interface.
> 
> @peek - you are most welcome to chat to me.
> 
> 
> On 2019/07/18 04:34, p...@vspace.co.za wrote:
> 
>> With DLV (DNSSEC Lookaside Validation) having been decommissioned, 
>> though zones still exists that does not provide a fully signed path 
>> from root to zone, i.e. .com.au , co.za etc, how would an 
>> administrator enable / implement DNSSEC validation for these zones ?
>>
>>
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation via DLV

[Mal via bind-users]

Not a difficult process really..

-Configure a DNSSEC enabled name server
-Create a some zone keys (dnssec-keygen)
-Sign your zone (dnssec-signzone)
-Update your nameserver configuration to point to the signed zone file
-Export your DS records (dsset) to the domain registration company (EPP).

Confirm the chain..   http://dnsviz.net/d/apnic.com.au/dnssec/

Mal



On 18/07/2019 4:46 pm, Mark Elkins wrote:
> I  can't comment on com.au (but looking up the Nameservers, I see the AD
> bit set - so DNSSEC appears to be in use..
> 
> However, co.za (and net.oza, org.za & web.za) which are managed by the
> ZACR (and DNS) - they are all signed and I personally have domains under
> these second levels - all running DNSSEC. The DS records are added to
> the parents using EPP - and it works perfectly. I used to present free
> (to the community) DNS classes to the community (the ZACR paid me) and
> this (DNSSEC) was taught to attendees. Unfortunately, no more classes
> for now.
> 
> DNSSEC in CO.ZA became live at about the time DLV stopped running. The
> other SLD's had already been running for about a year.
> 
> For the record, EDU.ZA is also signed and can accept DS records - albeit
> via a Web interface.
> 
> @peek - you are most welcome to chat to me.
> 
> 
> On 2019/07/18 04:34, p...@vspace.co.za wrote:
> 
>> With DLV (DNSSEC Lookaside Validation) having been decommissioned,
>> though zones still exists that does not provide a fully signed path
>> from root to zone, i.e. .com.au , co.za etc, how would an
>> administrator enable / implement DNSSEC validation for these zones ?
>>
>>
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation via DLV

[Mark Elkins]

I  can't comment on com.au (but looking up the Nameservers, I see the AD 
bit set - so DNSSEC appears to be in use..


However, co.za (and net.oza, org.za & web.za) which are managed by the 
ZACR (and DNS) - they are all signed and I personally have domains under 
these second levels - all running DNSSEC. The DS records are added to 
the parents using EPP - and it works perfectly. I used to present free 
(to the community) DNS classes to the community (the ZACR paid me) and 
this (DNSSEC) was taught to attendees. Unfortunately, no more classes 
for now.


DNSSEC in CO.ZA became live at about the time DLV stopped running. The 
other SLD's had already been running for about a year.


For the record, EDU.ZA is also signed and can accept DS records - albeit 
via a Web interface.


@peek - you are most welcome to chat to me.


On 2019/07/18 04:34, p...@vspace.co.za wrote:

With DLV (DNSSEC Lookaside Validation) having been decommissioned, 
though zones still exists that does not provide a fully signed path 
from root to zone, i.e. .com.au , co.za etc, how would an 
administrator enable / implement DNSSEC validation for these zones ?



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


--
Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-validation auto vs yes

[Warren Kumari]

On Wed, Jun 12, 2019 at 8:25 PM Evan Hunt  wrote:
>
> On Wed, Jun 12, 2019 at 11:40:27PM +, Shawn Zhou via bind-users wrote:
> > The default BIND9 installation for CentOS7 has dnssec-validation set to
> > "yes" and it also includes managed-keys as well. Do those managed-keys
> > get updated automatically?
>
> Yes, if the "managed-keys" statement is in named.conf (or included in
> it via an "include" statement) then the keys will be updated automatically.
... assuming that named can write to the directory. This is definitely
worth double-checking.

W

> Based on what you copy-pasted, that appears to be the case.
>
> "dnssec-validation auto" causes named to use its built-in key for the root
> zone, so you don't have to put your own "managed-keys" statement into
> named.conf, but otherwise it's the same as "dnssec-validation yes".
>
> (BTW, a note in passing: we're changing the command from "managed-keys" to
> "dnssec-keys" over the next few years. The new syntax will be available in
> BIND 9.15.1, which should be out next week; the old syntax will be
> phased out later.)
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-validation auto vs yes

[Tony Finch]

Shawn Zhou via bind-users  wrote:

>  Thanks Even. Sounds like "dnssec-validation auto" is a more
>  future-proof option for what want it. I will use that instead.

My recommendation is to avoid configuring or installing root trust
anchors, and let named handle all that itself. In BIND 9.14 and later
you don't need any configuration for working DNSSEC validation :-)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty, Forth: Cyclonic 5 to 7, occasionally gale 8 at first in
Forth, becoming south or southeast 5 or 6 later. Moderate or rough. Rain, fog
patches except in Forth. Moderate, occasionally very poor except in Forth.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-validation auto vs yes

[Shawn Zhou via bind-users]

 Thanks Even. Sounds like "dnssec-validation auto" is a more future-proof 
option for what want it. I will use that instead.


On Wednesday, June 12, 2019, 5:25:51 PM PDT, Evan Hunt  
wrote:  
 
 On Wed, Jun 12, 2019 at 11:40:27PM +, Shawn Zhou via bind-users wrote:
> The default BIND9 installation for CentOS7 has dnssec-validation set to
> "yes" and it also includes managed-keys as well. Do those managed-keys
> get updated automatically?

Yes, if the "managed-keys" statement is in named.conf (or included in
it via an "include" statement) then the keys will be updated automatically.
Based on what you copy-pasted, that appears to be the case.

"dnssec-validation auto" causes named to use its built-in key for the root
zone, so you don't have to put your own "managed-keys" statement into
named.conf, but otherwise it's the same as "dnssec-validation yes".

(BTW, a note in passing: we're changing the command from "managed-keys" to
"dnssec-keys" over the next few years. The new syntax will be available in
BIND 9.15.1, which should be out next week; the old syntax will be
phased out later.)

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
  ___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-validation auto vs yes

[Evan Hunt]

On Wed, Jun 12, 2019 at 11:40:27PM +, Shawn Zhou via bind-users wrote:
> The default BIND9 installation for CentOS7 has dnssec-validation set to
> "yes" and it also includes managed-keys as well. Do those managed-keys
> get updated automatically?

Yes, if the "managed-keys" statement is in named.conf (or included in
it via an "include" statement) then the keys will be updated automatically.
Based on what you copy-pasted, that appears to be the case.

"dnssec-validation auto" causes named to use its built-in key for the root
zone, so you don't have to put your own "managed-keys" statement into
named.conf, but otherwise it's the same as "dnssec-validation yes".

(BTW, a note in passing: we're changing the command from "managed-keys" to
"dnssec-keys" over the next few years. The new syntax will be available in
BIND 9.15.1, which should be out next week; the old syntax will be
phased out later.)

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation

[SIMON BABY]

Thanks Evan for answering my questions. I will look more into getdns-api or
libunbund library for the client side resolve.

Rgds
Simon

On Tue, Feb 13, 2018 at 3:00 PM, Evan Hunt  wrote:

> On Tue, Feb 13, 2018 at 01:33:10PM -0800, SIMON BABY wrote:
> > 1. Assume if I use an external recursive resolver and if that resolver
> does
> > not support DNSSEC, how can I validate the signature?
>
> Depends what you mean by supporting DNSSEC; see below.
>
> > 2. If I use an external resolver and if a hacker sits in between my
> > system and the external resolver, will it detect ?
>
> That's exactly what DNSSEC is for. If someone alters the answer,
> the signatures won't validate.
>
> > 3. When the external resolver resolve a query and when it response back
> to
> > the client, will it strip off the signatures? I assume the validation is
> > already done at the recursive resolver.
>
> The resolver doesn't have to do DNSSEC validation itself (though of course
> it's a good idea). It just needs to pass along signatures on request. If
> you're using a resolver that doesn't do that... well, use a different one.
>
> You can run a resolver as a separate local process, listening on the
> localhost address. This ensures you have the resolver features you need
> and also makes it quite a lot harder to mount a man-in-the-middle attack.
>
> > 4. Can I integrate dnsmasq option with my client application? Any
> reference.
>
> If you need it to be built in to your application, I'm not sure.  Warren's
> suggestion of using getdns-api was a better idea anyway.
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation

[Evan Hunt]

On Tue, Feb 13, 2018 at 01:33:10PM -0800, SIMON BABY wrote:
> 1. Assume if I use an external recursive resolver and if that resolver does
> not support DNSSEC, how can I validate the signature?

Depends what you mean by supporting DNSSEC; see below.

> 2. If I use an external resolver and if a hacker sits in between my
> system and the external resolver, will it detect ?

That's exactly what DNSSEC is for. If someone alters the answer,
the signatures won't validate.

> 3. When the external resolver resolve a query and when it response back to
> the client, will it strip off the signatures? I assume the validation is
> already done at the recursive resolver.

The resolver doesn't have to do DNSSEC validation itself (though of course
it's a good idea). It just needs to pass along signatures on request. If
you're using a resolver that doesn't do that... well, use a different one.

You can run a resolver as a separate local process, listening on the
localhost address. This ensures you have the resolver features you need
and also makes it quite a lot harder to mount a man-in-the-middle attack.

> 4. Can I integrate dnsmasq option with my client application? Any reference.

If you need it to be built in to your application, I'm not sure.  Warren's
suggestion of using getdns-api was a better idea anyway.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation

[SIMON BABY]

Thanks Warren. I will look into   https://getdnsapi.net/ .

Rgds
simon

On Tue, Feb 13, 2018 at 2:07 PM, Warren Kumari  wrote:

> On Tue, Feb 13, 2018 at 3:42 PM, SIMON BABY  wrote:
> > Hello Evan,
> >
> > Thank you so much for the quick response.
> >
> > My requirement is to implement only the recursive resolve and validation
> > part of the DNSSEC in my client application. Our CPU and memory are very
> > limited. So I am not sure I can go and use BIND 9.
> >
>
> I get that this is bind-users, but have you looked at
> https://getdnsapi.net/ ?
>
> W
>
> > With BIND 9, can I integrate the library in my application to send
> queries
> > and validate the answer in my client code itself. Can you please point if
> > any sample code.
> >
> >
> > Rgds
> > Simon
> >
> >
> >
> > On Tue, Feb 13, 2018 at 12:26 PM, Evan Hunt  wrote:
> >>
> >> On Tue, Feb 13, 2018 at 12:08:18PM -0800, SIMON BABY wrote:
> >> > I am trying to implement the full recursive resolver with libbind
> >> > library
> >> > in my client code. I am not using resolv.conf in my implementation.
> Can
> >> > anyone please help to point any sample code for this.
> >>
> >> Not even BIND uses libbind anymore.
> >>
> >> What's the purpose of this? Why not just use BIND 9, or some other
> >> existing resolver?
> >>
> >> --
> >> Evan Hunt -- e...@isc.org
> >> Internet Systems Consortium, Inc.
> >
> >
> >
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> > unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation

[Warren Kumari]

On Tue, Feb 13, 2018 at 3:42 PM, SIMON BABY  wrote:
> Hello Evan,
>
> Thank you so much for the quick response.
>
> My requirement is to implement only the recursive resolve and validation
> part of the DNSSEC in my client application. Our CPU and memory are very
> limited. So I am not sure I can go and use BIND 9.
>

I get that this is bind-users, but have you looked at https://getdnsapi.net/ ?

W

> With BIND 9, can I integrate the library in my application to send queries
> and validate the answer in my client code itself. Can you please point if
> any sample code.
>
>
> Rgds
> Simon
>
>
>
> On Tue, Feb 13, 2018 at 12:26 PM, Evan Hunt  wrote:
>>
>> On Tue, Feb 13, 2018 at 12:08:18PM -0800, SIMON BABY wrote:
>> > I am trying to implement the full recursive resolver with libbind
>> > library
>> > in my client code. I am not using resolv.conf in my implementation. Can
>> > anyone please help to point any sample code for this.
>>
>> Not even BIND uses libbind anymore.
>>
>> What's the purpose of this? Why not just use BIND 9, or some other
>> existing resolver?
>>
>> --
>> Evan Hunt -- e...@isc.org
>> Internet Systems Consortium, Inc.
>
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation

[SIMON BABY]

Hello Evan,

Thanks you so much for answering my questions. Inline my comments.

But why do you need your application to contain a recursive resolver?

1. Assume if I use an external recursive resolver and if that resolver does
not support DNSSEC, how can I validate the signature?

2. If I use an external resolver and if a hacker sits in between my system
and the external resolver, will it detect ?

3. When the external resolver resolve a query and when it response back to
the client , will it strip off the signatures? I assume the validation is
already done at the recursive resolver.

4. Can I integrate dnsmasq option with my client application? Any reference.

Thanks once again for your help and time.

Rgds
Simon

On Tue, Feb 13, 2018 at 1:11 PM, Evan Hunt  wrote:

> On Tue, Feb 13, 2018 at 12:42:26PM -0800, SIMON BABY wrote:
> > My requirement is to implement only the recursive resolve and validation
> > part of the DNSSEC in my client application. Our CPU and memory are very
> > limited. So I am not sure I can go and use BIND 9.
>
> But why do you need your application to contain a recursive resolver?
>
> I can understand why you'd want a built-in validator, but you don't need
> to do full recursive resolution for that; you can send queries to an
> external resolver and then validate the responses.
>
> > With BIND 9, can I integrate the library in my application to send
> queries
> > and validate the answer in my client code itself. Can you please point if
> > any sample code.
>
> If you're content to do as I suggested above - send queries to an external
> resolver, validate the responses - then see the command 'delv' in the
> BIND 9 source tree; it does that.
>
> Implementing a full resolver with a library is possible in BIND 9.12,
> in which we spun off a lot of the name server code into a new libns
> library.  I can't point you to any sample code other than named itself,
> though.
>
> Given what you said about limited CPU and memory, I can't really recommand
> either solution. I'd probably just use dnsmasq and turn on its DNSSEC
> validation option.
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation

[Evan Hunt]

On Tue, Feb 13, 2018 at 12:42:26PM -0800, SIMON BABY wrote:
> My requirement is to implement only the recursive resolve and validation
> part of the DNSSEC in my client application. Our CPU and memory are very
> limited. So I am not sure I can go and use BIND 9.

But why do you need your application to contain a recursive resolver?

I can understand why you'd want a built-in validator, but you don't need
to do full recursive resolution for that; you can send queries to an
external resolver and then validate the responses.

> With BIND 9, can I integrate the library in my application to send queries
> and validate the answer in my client code itself. Can you please point if
> any sample code.

If you're content to do as I suggested above - send queries to an external
resolver, validate the responses - then see the command 'delv' in the
BIND 9 source tree; it does that.

Implementing a full resolver with a library is possible in BIND 9.12,
in which we spun off a lot of the name server code into a new libns
library.  I can't point you to any sample code other than named itself,
though.

Given what you said about limited CPU and memory, I can't really recommand
either solution. I'd probably just use dnsmasq and turn on its DNSSEC
validation option.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation

[SIMON BABY]

Hello Evan,

Thank you so much for the quick response.

My requirement is to implement only the recursive resolve and validation
part of the DNSSEC in my client application. Our CPU and memory are very
limited. So I am not sure I can go and use BIND 9.

With BIND 9, can I integrate the library in my application to send queries
and validate the answer in my client code itself. Can you please point if
any sample code.


Rgds
Simon



On Tue, Feb 13, 2018 at 12:26 PM, Evan Hunt  wrote:

> On Tue, Feb 13, 2018 at 12:08:18PM -0800, SIMON BABY wrote:
> > I am trying to implement the full recursive resolver with libbind library
> > in my client code. I am not using resolv.conf in my implementation. Can
> > anyone please help to point any sample code for this.
>
> Not even BIND uses libbind anymore.
>
> What's the purpose of this? Why not just use BIND 9, or some other
> existing resolver?
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation

[Evan Hunt]

On Tue, Feb 13, 2018 at 12:08:18PM -0800, SIMON BABY wrote:
> I am trying to implement the full recursive resolver with libbind library
> in my client code. I am not using resolv.conf in my implementation. Can
> anyone please help to point any sample code for this.

Not even BIND uses libbind anymore.

What's the purpose of this? Why not just use BIND 9, or some other
existing resolver?

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation without current time

[Dave Warren via bind-users]

On 2017-12-18 06:44, Timothe Litt wrote:


On 18-Dec-17 01:07, Dave Warren wrote:

On 2017-12-15 06:23, Petr Menšík wrote:


Dne 15.12.2017 v 13:06 G.W. Haywood via bind-users napsal(a):

Hi there,

On Fri, 15 Dec 2017, Petr Men??k wrote:


... current time is not available or can be inaccurate.


ntpdate?


Sure, of course. What would be default host after installation, that can
be used in default installation image without manual configuration? And
how does it resolve that name, when date of the system is 1970-1-1 or
something a only a bit more accurate?

Current pool.ntp.org adresses are unsigned now, so that would work
anyway. If I want spoof protection, what should I do?


Do two passes. First: Use DNS without DNSSEC validation to obtain a 
list of NTP servers, and thereby determine the current time. Second: 
Use DNS with DNSSEC to obtain a list of (trusted) NTP servers, and 
verify the time.


The second pass might detect the list of IPs has changed and bypass 
the second NTP pass as we now know the previous IPs were valid, but 
you must be prepared for DNS to return different IPs from a pool and 
to therefore re-verify the time -- We don't care if the IP list has 
changed, only that the time is valid.


The only real challenge is to avoid letting anything else trust the 
time received in phase 1 until it has been validated by phase 2.




This proposal is involved, but doesn't seem to robustly solve the problem.

  * Pass 1 obtains "current time".  But you don't trust that the IP
addresses of the NTP servers were correctly resolved.  So you don't
trust this time.  However, you need a reasonably trustworthy time to
bootstrap DNSSEC.  (On the order of minutes).  Else DNSSEC
validation can fail.


Right, this is the whole point and why it works. If either DNS or NTP is 
malicious, pass 2's DNSSEC validation fails and we know we don't yet 
have valid time.




  * If you're using the pools (and they resolve correctly), you're
pretty much guaranteed that any two queries will produce a different
set of servers.  So IP addresses will change.


DNS caching may provide the same IP addresses. It is irrelevant as this 
is just an optimization which fails gracefully, or can be skipped entirely.




  * Pass 2 requires "trusted" NTP servers.  If you have that list, why
not resolve those names without validation in the first place?  You
could assume that a hostile actor knows which names you resolve, and
assume that they will substitute bad timekeepers.  But if they can
do that, they can do the same for the pools' names.


I think that this is the whole point -- There is no hardcoded list of 
trusted NTP servers. We need to obtain the list from DNS (pass 1) and 
verify that the list can be trusted using DNSSEC (pass 2).

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation without current time

[Sten Carlsen]

On 18/12/2017 14:44, Timothe Litt wrote:
>
> On 18-Dec-17 01:07, Dave Warren wrote:
>> On 2017-12-15 06:23, Petr Menšík wrote:
>>>
>>> Dne 15.12.2017 v 13:06 G.W. Haywood via bind-users napsal(a):
 Hi there,

 On Fri, 15 Dec 2017, Petr Men??k wrote:

> ... current time is not available or can be inaccurate.

 ntpdate?

>>> Sure, of course. What would be default host after installation, that
>>> can
>>> be used in default installation image without manual configuration? And
>>> how does it resolve that name, when date of the system is 1970-1-1 or
>>> something a only a bit more accurate?
>>>
>>> Current pool.ntp.org adresses are unsigned now, so that would work
>>> anyway. If I want spoof protection, what should I do?
>>
>> Do two passes. First: Use DNS without DNSSEC validation to obtain a
>> list of NTP servers, and thereby determine the current time. Second:
>> Use DNS with DNSSEC to obtain a list of (trusted) NTP servers, and
>> verify the time.
>>
>> The second pass might detect the list of IPs has changed and bypass
>> the second NTP pass as we now know the previous IPs were valid, but
>> you must be prepared for DNS to return different IPs from a pool and
>> to therefore re-verify the time -- We don't care if the IP list has
>> changed, only that the time is valid.
>>
>> The only real challenge is to avoid letting anything else trust the
>> time received in phase 1 until it has been validated by phase 2.
>>
>
> This proposal is involved, but doesn't seem to robustly solve the problem.
True but look at it this way, first get a guess on the time from "an"
NTP server, then try using that time to get DNSSEC replies, if they
work, the time was good enough, if the time was bad, DNSSEC will not
work and you know you have a bad time,and will have to try again or die.
>
>   * Pass 1 obtains "current time".  But you don't trust that the IP
> addresses of the NTP servers were correctly resolved.  So you
> don't trust this time.  However, you need a reasonably trustworthy
> time to bootstrap DNSSEC.  (On the order of minutes).  Else DNSSEC
> validation can fail.
>   * If you're using the pools (and they resolve correctly), you're
> pretty much guaranteed that any two queries will produce a
> different set of servers.  So IP addresses will change.
>   * If you use a reasonable number of NTP servers and NTP (not SNTP)
> protocol, invalid timekeepers will be sorted out.  NTP is quite
> robust, and expects some variance - including some malicious
> actors.  The reasonably recent versions with pool support will
> discard bad timekeepers and keep drawing from the pool until
> consensus is attained.  And again if it's lost (e.g. some go bad
> due to system or network failures.)  To fool NTP, you need to
> provide a number of bad time sources, synchronized closely enough
> for NTP to accept them.  This is non-trivial.  Suppose someone
> puts in that effort and succeeds.  What happens?  DNSSEC is the
> least of your problems.  Other breakage will be more subtle.  Like
> filesystem times being inconsistent and breaking CMS and other
> applications.
>   * To prevent DNSSEC from working, time error has to be quite large. 
> All that's necessary is some approximation that's accurate within
> minutes.
>   * Pass 2 requires "trusted" NTP servers.  If you have that list, why
> not resolve those names without validation in the first place? 
> You could assume that a hostile actor knows which names you
> resolve, and assume that they will substitute bad timekeepers. 
> But if they can do that, they can do the same for the pools' names.
>   * What can bad time do to DNSSEC?  By rolling back, it could allow
> validation of an expired signature - but the attacker would have
> to be able to benefit from that.  Or it could prevent validation
> of a current signature (by making current time be outside the
> validity period).  Or it could prematurely force you to validate a
> published, but not yet active signature.  These amount to (at
> worst) denial of service. 
>
> None of this is news.  See
> https://tools.ietf.org/id/draft-mglt-dnsop-dnssec-validator-requirements-06.html#rfc.section.5
>
>
> The bottom line is that you want accurate time.  And if you have
> accurate time, DNSSEC will follow.  You also need to consider the
> threat profile that you face - including the downside risks and costs
> of a defense.
>
> Bootstrapping requires some reasonably accurate time source.  The
> easiest way to get there is with a locally trusted source.  You can
> add an RTC - again, here's one from Adafruit -
> https://www.adafruit.com/product/3386 about $5 (US).  [Same
> disclaimer.]  The RTCs (I haven't run this one) in general have poor
> accuracy(2) - but if resynchronized with NTP time once in a while,
> easily good enough to bootstrap DNSSEC.  The one I use (1) is good to
> less than 1PPM 

Re: Re: DNSSEC validation without current time

[Timothe Litt]

On 18-Dec-17 01:07, Dave Warren wrote:
> On 2017-12-15 06:23, Petr Menšík wrote:
>>
>> Dne 15.12.2017 v 13:06 G.W. Haywood via bind-users napsal(a):
>>> Hi there,
>>>
>>> On Fri, 15 Dec 2017, Petr Men??k wrote:
>>>
 ... current time is not available or can be inaccurate.
>>>
>>> ntpdate?
>>>
>> Sure, of course. What would be default host after installation, that can
>> be used in default installation image without manual configuration? And
>> how does it resolve that name, when date of the system is 1970-1-1 or
>> something a only a bit more accurate?
>>
>> Current pool.ntp.org adresses are unsigned now, so that would work
>> anyway. If I want spoof protection, what should I do?
>
> Do two passes. First: Use DNS without DNSSEC validation to obtain a
> list of NTP servers, and thereby determine the current time. Second:
> Use DNS with DNSSEC to obtain a list of (trusted) NTP servers, and
> verify the time.
>
> The second pass might detect the list of IPs has changed and bypass
> the second NTP pass as we now know the previous IPs were valid, but
> you must be prepared for DNS to return different IPs from a pool and
> to therefore re-verify the time -- We don't care if the IP list has
> changed, only that the time is valid.
>
> The only real challenge is to avoid letting anything else trust the
> time received in phase 1 until it has been validated by phase 2.
>

This proposal is involved, but doesn't seem to robustly solve the problem.

  * Pass 1 obtains "current time".  But you don't trust that the IP
addresses of the NTP servers were correctly resolved.  So you don't
trust this time.  However, you need a reasonably trustworthy time to
bootstrap DNSSEC.  (On the order of minutes).  Else DNSSEC
validation can fail.
  * If you're using the pools (and they resolve correctly), you're
pretty much guaranteed that any two queries will produce a different
set of servers.  So IP addresses will change.
  * If you use a reasonable number of NTP servers and NTP (not SNTP)
protocol, invalid timekeepers will be sorted out.  NTP is quite
robust, and expects some variance - including some malicious
actors.  The reasonably recent versions with pool support will
discard bad timekeepers and keep drawing from the pool until
consensus is attained.  And again if it's lost (e.g. some go bad due
to system or network failures.)  To fool NTP, you need to provide a
number of bad time sources, synchronized closely enough for NTP to
accept them.  This is non-trivial.  Suppose someone puts in that
effort and succeeds.  What happens?  DNSSEC is the least of your
problems.  Other breakage will be more subtle.  Like filesystem
times being inconsistent and breaking CMS and other applications.
  * To prevent DNSSEC from working, time error has to be quite large. 
All that's necessary is some approximation that's accurate within
minutes.
  * Pass 2 requires "trusted" NTP servers.  If you have that list, why
not resolve those names without validation in the first place?  You
could assume that a hostile actor knows which names you resolve, and
assume that they will substitute bad timekeepers.  But if they can
do that, they can do the same for the pools' names.
  * What can bad time do to DNSSEC?  By rolling back, it could allow
validation of an expired signature - but the attacker would have to
be able to benefit from that.  Or it could prevent validation of a
current signature (by making current time be outside the validity
period).  Or it could prematurely force you to validate a published,
but not yet active signature.  These amount to (at worst) denial of
service. 

None of this is news.  See
https://tools.ietf.org/id/draft-mglt-dnsop-dnssec-validator-requirements-06.html#rfc.section.5


The bottom line is that you want accurate time.  And if you have
accurate time, DNSSEC will follow.  You also need to consider the threat
profile that you face - including the downside risks and costs of a defense.

Bootstrapping requires some reasonably accurate time source.  The
easiest way to get there is with a locally trusted source.  You can add
an RTC - again, here's one from Adafruit -
https://www.adafruit.com/product/3386 about $5 (US).  [Same
disclaimer.]  The RTCs (I haven't run this one) in general have poor
accuracy(2) - but if resynchronized with NTP time once in a while,
easily good enough to bootstrap DNSSEC.  The one I use (1) is good to
less than 1PPM with the help of some drift compensation that I put into
the utility that manages the clock.  [It's a replacement for 'hwclock'
that drives this RTC.]  (This reduces the jump when NTP starts, and
helps keep logs straight.  If you don't care about that, just update the
RTC from NTP time every week or two - that's more than sufficient for
DNSSEC & NTP bootstrap.)

Alternatively, as previously discussed, if you need the best (non PTP)
time, add a GPS receiver, with pool 

Re: DNSSEC validation without current time

[Dave Warren via bind-users]

On 2017-12-15 06:23, Petr Menšík wrote:


Dne 15.12.2017 v 13:06 G.W. Haywood via bind-users napsal(a):

Hi there,

On Fri, 15 Dec 2017, Petr Men??k wrote:


... current time is not available or can be inaccurate.


ntpdate?


Sure, of course. What would be default host after installation, that can
be used in default installation image without manual configuration? And
how does it resolve that name, when date of the system is 1970-1-1 or
something a only a bit more accurate?

Current pool.ntp.org adresses are unsigned now, so that would work
anyway. If I want spoof protection, what should I do?


Do two passes. First: Use DNS without DNSSEC validation to obtain a list 
of NTP servers, and thereby determine the current time. Second: Use DNS 
with DNSSEC to obtain a list of (trusted) NTP servers, and verify the time.


The second pass might detect the list of IPs has changed and bypass the 
second NTP pass as we now know the previous IPs were valid, but you must 
be prepared for DNS to return different IPs from a pool and to therefore 
re-verify the time -- We don't care if the IP list has changed, only 
that the time is valid.


The only real challenge is to avoid letting anything else trust the time 
received in phase 1 until it has been validated by phase 2.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation without current time

[G.W. Haywood via bind-users]

Hi there,

On Fri, 15 Dec 2017,  Barry Margolin wrote:


In article ,
"G.W. Haywood"  wrote:


On Fri, 15 Dec 2017, Petr Men??k wrote:


... current time is not available or can be inaccurate.


ntpdate?


I think the issue is that he needs to resolve the hostname of the NTP
server.


Perhaps he could set up some IPv6 time servers on a dedicated /48.

--

73,
Ged.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation without current time

[Grant Taylor via bind-users]

On 12/15/2017 08:10 AM, Timothe Litt wrote:
I use an 19xLVC too (On Raspbian == Debian).  But I also have an RTC.  
GPS does have outages,  can take a while to get a fix, and NTP wants 
consensus.  So I use my GPS receiver as a local clock source 
(preferred), but also configure several servers from the pools as a 
sanity check - and to deal with any GPS outages/slow starts.  It's 
worked well for me.


Along those lines, I haven't splurged yet, but Adafruit has an 
interesting module for ~$40 (US)  with a breakout module, ($45 on a Pi 
Hat - which is cheaper/easier than building your own PCB), which 
includes a GPS patch antenna.  If you need an external antenna, it comes 
up to about the cost of the Garmin, but draws only 20ma vs. 90, and is a 
more modern receiver.)   On paper it looks good.


See https://www.adafruit.com/?q=ultimate%20gps - I'm not affiliated with 
Adafruit, and while I've looked at the specs, don't have direct 
experience.  YMMV.


Thank you for sharing info Mukund and Timothe.  I suspect I'll be 
playing over the holidays.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation without current time

[Barry Margolin]

In article ,
 "G.W. Haywood"  wrote:

> Hi there,
> 
> On Fri, 15 Dec 2017, Petr Men??k wrote:
> 
> > ... current time is not available or can be inaccurate.
> 
> ntpdate?

I think the issue is that he needs to resolve the hostname of the NTP 
server.

-- 
Barry Margolin
Arlington, MA
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Re: DNSSEC validation without current time

[Timothe Litt]

On 15-Dec-17 07:44, Mukund Sivaraman wrote:

On Fri, Dec 15, 2017 at 12:45:11PM +0100, Petr Menšík wrote:
>> Hi folks.
>>
>> I am looking for a way to validate name also on systems, where current
>> time is not available or can be inaccurate.
> I use a Garmin 18x LVC 1pps GPS receiver device connected to RS-232
> serial port. The device plus cables cost me $70 altogether, and ntpd
> works natively with it using the NMEA refclock driver (there's no need
> of gpsd). It has a 1s PPS signal accurate to 1us. It is accurate to
> within +/- 100us on Fedora where due to no hardpps kernel support
> because of tickless kernel, the PPS signal is timestamped and available
> on /dev/pps0 but the kernel doesn't use it to directly maintain the
> clock and it has to be done from userland which is affected by the
> system load.  If you were to recompile a kernel that's configured
> appropriately, I feel the clock can be synchronized to about 1us
> accuracy.
>
> It is more or less reliable and value for $70 if one wants UTC on their
> computer without accessing the internet. This is more than sufficient
> for DNSSEC validation and many other network services, and certainly
> more accurate than using the ntp.org pools.
>
>   Mukund
>
I use an 19xLVC too (On Raspbian == Debian).  But I also have an RTC. 
GPS does have outages,  can take a while to get a fix, and NTP wants
consensus.  So I use my GPS receiver as a local clock source
(preferred), but also configure several servers from the pools as a
sanity check - and to deal with any GPS outages/slow starts.  It's
worked well for me.

Along those lines, I haven't splurged yet, but Adafruit has an
interesting module for ~$40 (US)  with a breakout module, ($45 on a Pi
Hat - which is cheaper/easier than building your own PCB), which
includes a GPS patch antenna.  If you need an external antenna, it comes
up to about the cost of the Garmin, but draws only 20ma vs. 90, and is a
more modern receiver.)   On paper it looks good.

See https://www.adafruit.com/?q=ultimate%20gps - I'm not affiliated with
Adafruit, and while I've looked at the specs, don't have direct
experience.  YMMV.

Enjoy.

Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 






smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation without current time

[Timothe Litt]

On 15-Dec-17 06:45, Petr Menšík wrote:
> Hi folks.
>
> I am looking for a way to validate name also on systems, where current
> time is not available or can be inaccurate.
>
> This is related to booting with NTP client, when the only configuration
> is hostname that has to be resolved. There is a bit circle dependencies.
> First current time is required for DNSSEC validator to verify signatures
> of all keys. However that is hard to maintain on systems without RTC
> clock running when it is down. Raspberry PI is example of such system.
> Until hostname is known, time cannot be synchronized and corrected to
> real value. They sort of depend on each other. The only secure way I
> found is to hardcode IP address into NTP client or obtain IP from other
> trusted source (DHCP?).
>
> Available option is of course to disable validation until valid time is
> received. It seems to me that is unnecessary lowering the security. I
> would like some option to limit checking validity period of used keys
> instead. Just validate existing keys from trust anchor and trust the
> last key that can validate. I think that is far better than no
> verification at all.
>
> Is it possible to do that in BIND? Maybe bootstrap verification could be
> done only with delv tool with time-checking disabled. I found no way to
> do that. Is there good reason why it is not available? Is better method
> for solving secure configuration of timeless system available?
>

I added an RTC to my Pis :-)  It makes life a lot simpler, even after I
wrote a driver and calibration mechanism.

But if you have access to a DHCP server, have the client request Option
42; this returns one or more NTP servers' IP addresses in preference
order.  You can use NTPD (or ntpdate) to get a time.   ISC DHCP client
supports this option; see dhcp-users if you need help.

DNSSEC requires reasonably accurate time, as signatures have validity
periods.  Your scheme would not work; you need time to validate ANY
signature - from the trust anchor down.  If there's no time, you can't
validate any part of the chain - so you might as well use ordinary DNS. 
NTP is fairly robust; it uses consensus from multiple servers to
establish correct time.  For a rogue DNS to inject bad time into your
PI, it would have to know which NTP servers you are using.

Another option is to use DHCP to get the address of a validating
resolver, and rely on that for bootstrapping NTP.  Again, this depends
on whether your control/trust your DHCP server.  More ISPs are providing
validatiing DNS server, but it's not universal. Hardcoding one of the
public ones (e.g. Google - 8.8.8.8, 8.8.4.4, 2001:4860:4860::,
2001:4860:4860::8844) is fairly safe. 

NTP server addresses are more volatile, and it's a serious breach of
netiquette to hardcode them; there are a number of stories of how this
has gone badly wrong for all concerned.

The choice depends on your requirements, available resources, and risk
tolerance.

You also need valid time for many other applications; TSIGs require a
reasonably close (on the order of minutes) time sync between sender and
receiver.

So rather than try to tweak NAMED, focus on getting a reasonable time
early in boot - and make sure that dependencies on a valid time are
properly expressed in your startup scripts.

Bottom line: your problem is getting a reasonable time, not with the
consumer(s).

Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation without current time

[Petr Menšík]

Dne 15.12.2017 v 13:06 G.W. Haywood via bind-users napsal(a):
> Hi there,
> 
> On Fri, 15 Dec 2017, Petr Men??k wrote:
> 
>> ... current time is not available or can be inaccurate.
> 
> ntpdate?
> 
Sure, of course. What would be default host after installation, that can
be used in default installation image without manual configuration? And
how does it resolve that name, when date of the system is 1970-1-1 or
something a only a bit more accurate?

Current pool.ntp.org adresses are unsigned now, so that would work
anyway. If I want spoof protection, what should I do?

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation without current time

[Tony Finch]

Petr Menšík  wrote:
>
> This is related to booting with NTP client, when the only configuration
> is hostname that has to be resolved. There is a bit circle dependencies.

Yes awkward, and there still aren't any convincing answers. One of the
more interesting projects is https://roughtime.googlesource.com/roughtime
I have not actually tried it out myself or found out if it can be
configured with only IP addresses so that it can get the time without the
DNS.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Southeast Iceland: Variable 3 or 4, but northerly 4 or 5 at first in east.
Moderate or rough. Wintry showers, then fair. Good occasionally poor at
first.___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation without current time

[Mukund Sivaraman]

On Fri, Dec 15, 2017 at 12:45:11PM +0100, Petr Menšík wrote:
> Hi folks.
> 
> I am looking for a way to validate name also on systems, where current
> time is not available or can be inaccurate.

I use a Garmin 18x LVC 1pps GPS receiver device connected to RS-232
serial port. The device plus cables cost me $70 altogether, and ntpd
works natively with it using the NMEA refclock driver (there's no need
of gpsd). It has a 1s PPS signal accurate to 1us. It is accurate to
within +/- 100us on Fedora where due to no hardpps kernel support
because of tickless kernel, the PPS signal is timestamped and available
on /dev/pps0 but the kernel doesn't use it to directly maintain the
clock and it has to be done from userland which is affected by the
system load.  If you were to recompile a kernel that's configured
appropriately, I feel the clock can be synchronized to about 1us
accuracy.

It is more or less reliable and value for $70 if one wants UTC on their
computer without accessing the internet. This is more than sufficient
for DNSSEC validation and many other network services, and certainly
more accurate than using the ntp.org pools.

Mukund
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation without current time

[G.W. Haywood via bind-users]

Hi there,

On Fri, 15 Dec 2017, Petr Men??k wrote:


... current time is not available or can be inaccurate.


ntpdate?

--

73,
Ged.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec validation issue

[dhungyel]

Hi Mukund

> Are you able to reproduce the bug with the latest stock version of BIND 
> 9.9?  9.9.4 is very old and that branch has had numerous bugfixes since. 

> I'm not able to reproduce such a validation failure with 9.9.11: 

At the moment the latest patched version of bind available for CentOS 7 is
9.9.4-50. The policy has been to stick with the patches / versions
distributed by the Distro rather than getting the latest. So, I will have to
try the new version and see if the problem persists.

I have looked around a bit more and this is where it starts getting
interesting. For hosts that are not mapped to CNAME, this works perfectly
fine. See below for host ns.icann.org

# dig @localhost ns.icann.org A +dnssec

; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7_3.1 <<>> @localhost ns.icann.org A
+dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31866
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;ns.icann.org.  IN  A

;; ANSWER SECTION:
ns.icann.org.   3600IN  A   199.4.138.53
ns.icann.org.   3600IN  RRSIG   A 7 3 3600 20170914022301 
20170824010741 56445
icann.org. DFfGY0h65bDzMHNSkf9cmM8vHbIeOyupdw5HeagBiWzQMAbzvtc4w5et
N+1P2zeOPvCvYiBcUsHi+JGqyB0q6gpyZMcXFbMGRPnp931B+F6MUnZL
H2+2PDhkBrZ1EtyVaS8s8IyZ9XOuzJKNwOQBt4mNdFhpvrpWmXMc1zTQ OYX1Kqg=

;; AUTHORITY SECTION:
icann.org.  86393   IN  NS  a.iana-servers.net.
icann.org.  86393   IN  NS  ns.icann.org.
icann.org.  86393   IN  NS  c.iana-servers.net.
icann.org.  86393   IN  NS  b.iana-servers.net.
icann.org.  86393   IN  RRSIG   NS 7 2 86400 20170915091737 
20170825024031 56445
icann.org. P7offNJTV/zX8mZVC7x6uwvhZrdLzLNM/r1tsp4g7yaprD6LY//TLbNc
tIdbFjZdml7CYYZxZSecmb5Uzo8O7sHS+1xdandh6KxPfo47mO+Ge6JI
JmspnEaOxOlK7Vp3RGCqdeUasxIpwjHlNa+4rZ30ImmKxsAGC9oq01ey d/JE8j8=

;; ADDITIONAL SECTION:
a.iana-servers.net. 172793  IN  A   199.43.135.53
a.iana-servers.net. 172793  IN  2001:500:8f::53
b.iana-servers.net. 172793  IN  A   199.43.133.53
b.iana-servers.net. 172793  IN  2001:500:8d::53
c.iana-servers.net. 172793  IN  A   199.43.134.53
c.iana-servers.net. 172793  IN  2001:500:8e::53
ns.icann.org.   86393   IN  2001:500:89::53
ns.icann.org.   3600IN  RRSIG    7 3 3600 20170913162548 
20170824010741
56445 icann.org. cSpl1KEIPeFTzXBhjn9CMA+Y4iVG92++kdzxoTzRhgEMsH2Xud/s8Mg1
DBEc07xMgou5OqyGvlbOxP1F2c/dOFrQBMBuojBmG4ltIj663GYshyFy
3sxqNJGATHDDJ7Sk8eiYFazct09Z2wQ73UdwKGXuzM4bD9LrXUYP0rnJ l0xEen8=

However, when I try the same thing for www.icann.org, I get SERVFAIL like
below:

# dig @localhost www.icann.org A +dnssec

; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7_3.1 <<>> @localhost www.icann.org A
+dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30814
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.icann.org. IN  A

;; Query time: 4237 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Aug 31 10:06:23 +06 2017
;; MSG SIZE  rcvd: 42

So, I am beginning to wonder if there is issue between dissed and CNAME in
9.9.4-50 version of bind. With checking disabled (as suggested by Tony), it
resolves correctly:

# dig @localhost www.icann.org A +cd

; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7_3.1 <<>> @localhost www.icann.org A +cd
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53618
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.icann.org. IN  A

;; ANSWER SECTION:
www.icann.org.  3386IN  CNAME   www.vip.icann.org.
www.vip.icann.org.  30  IN  A   192.0.32.7

;; AUTHORITY SECTION:
vip.icann.org.  3382IN  NS  gtm1.dc.icann.org.
vip.icann.org.  3382IN  NS  gtm1.mdr.icann.org.
vip.icann.org.  3382IN  NS  gtm1.lax.icann.org.

with +cd and +sigchase, the resolver is able to find the RRSIG data fine but
once checking is enabled, it just fails:


/# dig @localhost www.icann.org A +cd +sigchase
;; RRset to chase:
www.icann.org.  3039IN  CNAME   www.vip.icann.org.


;; RRSIG of the RRset to chase:
www.icann.org.  3039IN  RRSIG   CNAME 7 3 3600 20170914195717 
20170824110741
56445 icann.org. GoSDthX9s2BsyaT/AYyfNKixR8UMVF/fx3zz5U9XPIVJUkpp3g9xyuZy
wxO7aTVgiPaESUOttGGn4xs9KMzZ4BcI6bmOAehYubS6AaAb6YdbweR4
S6O3qiNMT5Sai4BrfmvITGjigyNXSb3vc8fsSeUPJVdR8gmObfzbJbdn 

Re: dnssec validation issue

[Mukund Sivaraman]

Hi Ganga

On Thu, Aug 24, 2017 at 09:33:32AM +0600, Ganga R. Dhungyel wrote:
> With dnssec-validation turned on, resolving sites like www.icann.org
>  fails. The alternative is to remove validation
> which of course is not the desired solution.

Are you able to reproduce the bug with the latest stock version of BIND
9.9?  9.9.4 is very old and that branch has had numerous bugfixes since.

I'm not able to reproduce such a validation failure with 9.9.11:

[muks@jurassic bind9]$ bin/dig @127.0.0.1 -p 53000 www.icann.org

; <<>> DiG 9.9.11 <<>> @127.0.0.1 -p 53000 www.icann.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28837
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.icann.org. IN  A

;; ANSWER SECTION:
www.icann.org.  3497IN  CNAME   www.vip.icann.org.
www.vip.icann.org.  30  IN  A   192.0.32.7

;; Query time: 464 msec
;; SERVER: 127.0.0.1#53000(127.0.0.1)
;; WHEN: Wed Aug 30 18:59:51 IST 2017
;; MSG SIZE  rcvd: 80

[muks@jurassic bind9]$

Both dig and named are from BIND 9.9.11. AD bit is set indicating
validation was performed.

Mukund
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec validation issue

[Stephane Bortzmeyer]

On Thu, Aug 24, 2017 at 09:33:32AM +0600,
 Ganga R. Dhungyel  wrote 
 a message of 677 lines which said:

> # dig @localhost www.icann.org A +dnssec

When you suspect a DNSSEC issue, always retry dig with +cd (Checking
Disabled). And post the result.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec validation issue

[Tony Finch]

Ganga R. Dhungyel  wrote:
>
> **debug log
>
> 23-Aug-2017 16:17:57.567 dnssec: debug 3:
>   validating @0x7f3ffc96e4d0: www.vip.icann.org A:
>   attempting insecurity proof
>
> With dnssec-validation turned on, resolving sites like www.icann.org fails.

I think that line in the debug log indicates that something went wrong
earlier - looks like the resolver somehow got an unsigned answer. I can't
say why without a bit more context.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Faeroes: Variable, mainly north, 3 or 4. Moderate or rough. Mainly fair. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-validation [ ddig_sigchase option ]

[Dennis Clarke]

On 10/12/16 15:07, Evan Hunt wrote:

On Wed, Oct 12, 2016 at 01:56:09PM -0400, Dennis Clarke wrote:

On 10/12/16 13:36, Evan Hunt wrote:

I recommend using "delv" instead.  "dig +sigchase" isn't good code.


? well that is news to me  :-\


It's code that was contributed over ten years ago; we put it into dig
(hidden behind #ifdef's) because at the time there was no better
alternative, but we never formally supported it.  It's buggy and
broken in a number of edge cases and hasn't really kept up with the
evolution of DNSSEC.

Please try "delv" and if you find that it doesn't meet your needs,
let me know so I can try to improve it.

NLNetLabs's "drill" is also useful.


I expect we'll be removing it in a future release.


cool .. so ... any change in our build process here ? A configure change
? Anything ?


No, delv is built and installed in BIND 9.10 and higher.



Thing of beauty.  Now I understand why there wasn't a configure option 
for sigchase and we needed a define. Makes sense.


Moving upwards to 9.11 anyways.

Thanks for the info.

Dennis

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-validation [ ddig_sigchase option ]

[Evan Hunt]

On Wed, Oct 12, 2016 at 01:56:09PM -0400, Dennis Clarke wrote:
> On 10/12/16 13:36, Evan Hunt wrote:
> > I recommend using "delv" instead.  "dig +sigchase" isn't good code.
> 
> ? well that is news to me  :-\

It's code that was contributed over ten years ago; we put it into dig
(hidden behind #ifdef's) because at the time there was no better
alternative, but we never formally supported it.  It's buggy and
broken in a number of edge cases and hasn't really kept up with the
evolution of DNSSEC.

Please try "delv" and if you find that it doesn't meet your needs,
let me know so I can try to improve it.

NLNetLabs's "drill" is also useful.

> > I expect we'll be removing it in a future release.
> 
> cool .. so ... any change in our build process here ? A configure change 
> ? Anything ?

No, delv is built and installed in BIND 9.10 and higher.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-validation [ ddig_sigchase option ]

[Dennis Clarke]

On 10/12/16 13:36, Evan Hunt wrote:

On Wed, Oct 12, 2016 at 03:40:54PM +, Bhangui, Sandeep - BLS CTR wrote:

Was trying to run dig commands to do some dnssec validation and got the following 
message "

"Invalid option: +sigchase"


I recommend using "delv" instead.  "dig +sigchase" isn't good code.


? well that is news to me  :-\


I expect we'll be removing it in a future release.


cool .. so ... any change in our build process here ? A configure change 
? Anything ?



Dennis



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-validation [ ddig_sigchase option ]

[Evan Hunt]

On Wed, Oct 12, 2016 at 03:40:54PM +, Bhangui, Sandeep - BLS CTR wrote:
> Was trying to run dig commands to do some dnssec validation and got the 
> following message "
> 
> "Invalid option: +sigchase"

I recommend using "delv" instead.  "dig +sigchase" isn't good code.
I expect we'll be removing it in a future release.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-validation [ ddig_sigchase option ]

[Dennis Clarke]

On 10/12/16 11:40, Bhangui, Sandeep - BLS CTR wrote:

Hi

Running ISC Bind 9.10.4-P2 will be soon moving to 9.10.4-P3.

Was trying to run dig commands to do some dnssec validation and got the following 
message "

"Invalid option: +sigchase"

When checked found that the dig utility has to be compiled with 
"-DDIG_SIGCHASE" option for that apparently looks like I have not done when we 
compiled 9.10.4-P2

I plan to soon compile 9.10.4.-P3 is it simply using " --DDIG_SIGCHASE" when I compile 
which will than allow me to run the dig binary with the "+sigchase" option?

My current compile options are as follows so would I be just adding 
"--DDIG_SIGCHASE" to get the dig binary which will allow me run dig with 
+sigchase option when I run the compile for 9.10.4-P3?



Create an environment var thus :

STD_CDEFINES=-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -DDIG_SIGCHASE=1


The run configure and carry on as usual.  Test with :

$ dig @my1.mydnsserver.com facebook.com +sigchase +trace



Dennis





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation failures for www.hrsa.gov

[Mark Andrews]

In message , Jay 
Ford writes:
> On Sat, 25 Jun 2016, Mark Andrews wrote:
> > The servers for webfarm.dr.hrsa.gov are not EDNS and DNSSEC compliant.
> > They are returning FORMERR to queries with EDNS options.  Unknown
> > EDNS options are supposed to be ignored (RFC 6891).
> >
> > You can workaround this with a server clause to disable sending the
> > cookie option with a server clause.
> >
> > server  { request-sit no; };   // 9.10.x
> > server  { send-cookie no; };   // 9.11.x
> 
> That did it, at least for now.
> 
> > Now one could argue that FORMERR is legal under RFC 2671 (the initial
> > EDNS specification) as no options were defined and to use a option
> > you need to bump the EDNS version but the servers don't do EDNS
> > version negotiation either as they return FORMERR to a EDNS version 1
> > query rather than BADVERS.  They also incorrectly copy back unknown
> > EDNS flags.
> 
> > Whether this is the cause of your issue I don't know but it won't be
> > helping.
> 
> The HRSA folks claim that their "site is fine".  In hopes of disabusing them 
> of that notion I'll have our folks who have to try to use the HRSA site pass 
> along the trouble report.

Just because it appears to work for some clients does not mean that
it works for all clients.  This is yet another IT department putting
their fingers in their ears and saying "nah nah nah".  If they were
compentent they would look at the RFC's listed in the original
report and check that their servers work correctly and fix the
issues found.

EDNS was designed to allow clients and servers to upgrade independently
but that requires that both clients and servers follow the protocol.
That they handle new/unknown stuff correctly which these servers
do not.

They can check their servers at https://ednscomp.isc.org/

Mark

> Thanks for the diagnosis & work-around.  Excellent as always & crazy fast, 
> too!
> 
> 
> Jay Ford, Network Engineering Group, Information Technology Services
> University of Iowa, Iowa City, IA 52242
> email: jay-f...@uiowa.edu, phone: 319-335-
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Re: DNSSEC validation failures for www.hrsa.gov

[Timothe Litt]

On 24-Jun-16 22:13, Jay Ford wrote:
> On Sat, 25 Jun 2016, Mark Andrews wrote:
>> The servers for webfarm.dr.hrsa.gov are not EDNS and DNSSEC compliant.
>> They are returning FORMERR to queries with EDNS options.  Unknown
>> EDNS options are supposed to be ignored (RFC 6891).
>>
>> You can workaround this with a server clause to disable sending the
>> cookie option with a server clause.
>>
>> server  { request-sit no; };// 9.10.x
>> server  { send-cookie no; };// 9.11.x
>
> That did it, at least for now.
>
>> Now one could argue that FORMERR is legal under RFC 2671 (the initial
>> EDNS specification) as no options were defined and to use a option
>> you need to bump the EDNS version but the servers don't do EDNS
>> version negotiation either as they return FORMERR to a EDNS version 1
>> query rather than BADVERS.  They also incorrectly copy back unknown
>> EDNS flags.
>
>> Whether this is the cause of your issue I don't know but it won't be
>> helping.
>
> The HRSA folks claim that their "site is fine".  In hopes of
> disabusing them of that notion I'll have our folks who have to try to
> use the HRSA site pass along the trouble report.
>
> Thanks for the diagnosis & work-around.  Excellent as always & crazy
> fast, too!
>
> 
> Jay Ford, Network Engineering Group, Information Technology Services
> University of Iowa, Iowa City, IA 52242
> email: jay-f...@uiowa.edu, phone: 319-335-
>

FWIW, dnsfp identifies the DNS servers as:

fingerprint (162.99.248.222, 162.99.248.222): Unlogic Eagle DNS 1.0 -- 1.0.1 
[New Rules]  

If this is correct, the project website for Eagle DNS would appear to
be: http://www.unlogic.se/projects/eagledns

It seems a rather odd choice for a .gov (US Health and Human Services)
owned domain...though one never knows what IT outsourcing will produce :-)

Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation failures for www.hrsa.gov

[Jay Ford]

On Sat, 25 Jun 2016, Mark Andrews wrote:

The servers for webfarm.dr.hrsa.gov are not EDNS and DNSSEC compliant.
They are returning FORMERR to queries with EDNS options.  Unknown
EDNS options are supposed to be ignored (RFC 6891).

You can workaround this with a server clause to disable sending the
cookie option with a server clause.

server  { request-sit no; }; // 9.10.x
server  { send-cookie no; }; // 9.11.x


That did it, at least for now.


Now one could argue that FORMERR is legal under RFC 2671 (the initial
EDNS specification) as no options were defined and to use a option
you need to bump the EDNS version but the servers don't do EDNS
version negotiation either as they return FORMERR to a EDNS version 1
query rather than BADVERS.  They also incorrectly copy back unknown
EDNS flags.



Whether this is the cause of your issue I don't know but it won't be
helping.


The HRSA folks claim that their "site is fine".  In hopes of disabusing them 
of that notion I'll have our folks who have to try to use the HRSA site pass 
along the trouble report.


Thanks for the diagnosis & work-around.  Excellent as always & crazy fast, 
too!



Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation failures for www.hrsa.gov

[Mark Andrews]

The servers for webfarm.dr.hrsa.gov are not EDNS and DNSSEC compliant.
They are returning FORMERR to queries with EDNS options.  Unknown
EDNS options are supposed to be ignored (RFC 6891).

You can workaround this with a server clause to disable sending the
cookie option with a server clause.

server  { request-sit no; };   // 9.10.x
server  { send-cookie no; };   // 9.11.x

Now one could argue that FORMERR is legal under RFC 2671 (the initial
EDNS specification) as no options were defined and to use a option
you need to bump the EDNS version but the servers don't do EDNS
version negotiation either as they return FORMERR to a EDNS version 1
query rather than BADVERS.  They also incorrectly copy back unknown
EDNS flags.

; <<>> DiG 9.11.0a3 <<>> webfarm.dr.hrsa.gov @ns2.hrsa.gov +edns=1 +noednsneg 
+nocookie +noad +norec +qr
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59618
;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 1, flags:; udp: 4096
;; QUESTION SECTION:
;webfarm.dr.hrsa.gov.   IN  A

;; QUERY SIZE: 48

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 59618
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 1, flags:; udp: 4096
;; QUESTION SECTION:
;webfarm.dr.hrsa.gov.   IN  A

;; Query time: 313 msec
;; SERVER: 162.99.248.222#53(162.99.248.222)
;; WHEN: Sat Jun 25 11:18:55 EST 2016
;; MSG SIZE  rcvd: 48

Whether this is the cause of your issue I don't know but it won't be
helping.

Mark

In message , Jay For
d writes:
> I'm getting DNSSEC validation failures by BIND 9.10.4-P1 for www.hrsa.gov.
> 
> The pertinent log messages are things like:
> 
> lame-servers: info: no valid RRSIG resolving 'webfarm.dr.hrsa.gov/DS/IN':
>  165.112.137.222#53
> lame-servers: info: no valid RRSIG resolving 'webfarm.dr.hrsa.gov/DS/IN':
>  162.99.248.222#53
> lame-servers: info: no valid DS resolving 'webfarm.dr.hrsa.gov/A/IN': 162
> .99.248.222#53
> lame-servers: info: broken trust chain resolving 'webfarm.dr.hrsa.gov/A/I
> N': 165.112.137.222#53
> lame-servers: info: insecurity proof failed resolving 'dr.hrsa.gov/SOA/IN
> ': 162.99.248.222#53
> lame-servers: info: insecurity proof failed resolving 'dr.hrsa.gov/SOA/IN
> ': 165.112.137.222#53
> 
> The dig output is:
> 
> $ dig www.hrsa.gov @dns-spare.uiowa.edu
> 
> ; <<>> DiG 9.10.3-P4-Debian <<>> www.hrsa.gov @dns-spare.uiowa.edu
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42947
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;www.hrsa.gov.  IN  A
> 
> ;; Query time: 103 msec
> ;; SERVER: fd9a:2c75:7d0c:5::2#53(fd9a:2c75:7d0c:5::2)
> ;; WHEN: Fri Jun 24 18:49:06 CDT 2016
> ;; MSG SIZE  rcvd: 41
> 
> It doesn't fail with a similar config on 9.10.3-P4, but there are admittedly 
> config differences.
> 
> Other DNSSEC-signed things validate fine at both versions, so things are
> mostly OK.
> 
> My guess is that BIND 9.10.4-P1 is checking something more stringently than
> previous versions did, & that something is broken with the DNS for
> www.hrsa.gov, but I can't spot what it is.  There are some very short TTLs (5
> seconds) in the data tree in question, including for SOAs, which seems like a
> really bad idea but I'm not sure it definitely breaks things.  There are also
> some answers with both "AA" & "AD" set, which seems odd, but again, not
> definitely broken.
> 
> dnsviz.net reports a couple of warnings, including a non-AA answer from
> authoritative servers, but it doesn't say it's bogus.
> 
> If anybody can spot something broken for www.hrsa.gov, I'd be very glad to
> hear about it.
> 
> 
> Jay Ford, Network Engineering Group, Information Technology Services
> University of Iowa, Iowa City, IA 52242
> email: jay-f...@uiowa.edu, phone: 319-335-
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: DNSSEC validation on 9.7.4 not working

[frnkblk]

Ding-ding-ding -- issuing rndc flushname . did the trick, Mark.

I'd encourage this troubleshooting tip to be documented in one of those
how-to guides.  I don't think waiting for a TTL is a good idea if most
queries are failing with bad cache hit.

Frank

-Original Message-
From: Mark Andrews [mailto:ma...@isc.org] 
Sent: Tuesday, June 23, 2015 11:03 PM
To: Frank Bulk
Cc: bind-us...@isc.org
Subject: Re: DNSSEC validation on 9.7.4 not working


I suspect that the DNSKEY record for the root will be marked as a
'answer' rather than 'secure' (rndc dumpdb) and flushing the cache
will fix the issue as will waiting ~30703 seconds.  'rndc flushname .'
should also work though I forget where we added flushname.

Mark

In message 005701d0ae2f$ef2798f0$cd76cad0$@iname.com, Frank Bulk writes:
 Here you go:
 
 root@nagios:/etc/bind# dig @127.0.0.1 +dnssec +cd ds com; dig @127.0.0.1
 +dnssec +cd dnskey .
 
 ;  DiG 9.7.3  @127.0.0.1 +dnssec +cd ds com
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 38536
 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags: do; udp: 4096
 ;; QUESTION SECTION:
 ;com.   IN  DS
 
 ;; ANSWER SECTION:
 com.86400   IN  DS  30909 8 2
 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
 com.86400   IN  RRSIG   DS 8 1 86400
2015070317
 2015062316 48613 .
 ioJ6KyZ9ig0PsFBdo5jfM/9hLEX9qn06QaitkJubhcH3m/DPBi2o9xTu
 Cs9Aabwm/tSlGc+JVc3oBVSwv6LakHUY9v7aJn77pD244tnnlgNeR+z4
 kkZSn1Kp5tHmhKx8sNYe8Fe9rTA/9hC+3IokE949ppf+3CEyjJ4uhJhm lN0=
 
 ;; Query time: 54 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Tue Jun 23 22:41:31 2015
 ;; MSG SIZE  rcvd: 239
 
 
 ;  DiG 9.7.3  @127.0.0.1 +dnssec +cd dnskey .
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 11727
 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags: do; udp: 4096
 ;; QUESTION SECTION:
 ;.  IN  DNSKEY
 
 ;; ANSWER SECTION:
 .   30703   IN  DNSKEY  256 3 8
 AwEAAZyIkCwEYeG29NV+4cOdKE4DPng/4BqJeoOhKqzJbl+LR33TPWsr
 wBRfmAi9wvR/Qc6IV4MFMXjmkclXns+atIQZ9uQV3YAvKv/cVuO7Mneu
 MssIQixaMw+jp73R7zIUNMbLBgJRQXI57Rl+pvXBAkgHndVwv+aJkf7y GEuE9Dtj
 .   30703   IN  DNSKEY  256 3 8
 AwEAAa67bQck1JjopOOFc+iMISFcp/osWrEst2wbKbuQSUWu77QC9UHL
 ipiHgWN7JlqVAEjKITZz49hhkLmOpmLK55pTq+RD2kwoyNWk9cvpc+tS
 nIxT7i93O+3oVeLYjMWrkDAz7K45rObbHDuSBwYZKrcSIUCZnCpNMUtn PFl/04cb
 .   30703   IN  DNSKEY  257 3 8
 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
 FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
 bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
 X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
 W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
 Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=
 .   30703   IN  RRSIG   DNSKEY 8 0 172800
 20150705235959 2015062000 19036 .
 W6ZIOh5tJ1ph3C0c9Fqot+55jCewbk/cWRquGOeRnWkag7rx/XgsEfvd
 HLr1HsSIlag+lt1OvTlsLgvVk/yUcOAZA/NvMRPbFfbyrEi82YpZ70Z2
 B995qkT7dCf/3uBynAzubAPshUfEi7LuBy9bzyYPMvtRZptEnBz3xsAf
 4gmrRTX0BW66ve2xqvitZrPVH2WaYR70iJbJWbKKDCPl9rwEcit95gyi
 CNQLOIPFq2XgHDmo01Pr4evPbSowny6kNXzuDHgKQn1+BWX5zhbr74OE
 3FZXo2DUXm8BA5OhMY0bMg32kjzQLu+lxBWpaXabjFoALNFG4WRRdx1s 4+Wuhg==
 
 ;; Query time: 0 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Tue Jun 23 22:41:31 2015
 ;; MSG SIZE  rcvd: 883
 
 root@nagios:/etc/bind# date -u
 Wed Jun 24 03:41:52 UTC 2015
 root@nagios:/etc/bind#
 
 Frank
 
 -Original Message-
 From: Mark Andrews [mailto:ma...@isc.org] 
 Sent: Tuesday, June 23, 2015 10:31 PM
 To: Frank Bulk frnk...@iname.com
 Cc: bind-us...@isc.org
 Subject: Re: DNSSEC validation on 9.7.4 not working
 
 
 Should have asked for +dnssec on those queries.  Also date -u.
 
 
 In message 005601d0ae2c$b698b6c0$23ca2440$@iname.com, Frank Bulk
writes:
  Mark,
  
  Sorry for top-posting -- my email client makes it difficult to do
 otherwise.
  
  Yes, I'm absolutely sure there's no software or physical firewall (we're
 an
  ISP), and there's also no load-balancer in front of this box.  I've also
  used the EDNS tests and I can get a 4000+ byte response.  There's also
no
  forwarder configured.
  
  Here's the requested output:
  
  
  root@nagios:/etc/bind# dig @127.0.0.1 +cd ds com; dig @127.0.0.1 +cd
 dnskey
  .
  
  ;  DiG 9.7.3  @127.0.0.1 +cd ds com
  ; (1 server found)
  ;; global options: +cmd
  ;; Got answer:
  ;; -HEADER- opcode: QUERY, status: NOERROR, id: 55498
  ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
  
  ;; QUESTION SECTION:
  ;com.   IN  DS
  
  ;; ANSWER SECTION:
  com

Re: DNSSEC validation on 9.7.4 not working

[Alan Clegg]

I've always recommended either a cache flush or a complete restart of
named after turning on DNSSEC.

I thought I opened a ticket about this, but probably not.

AlanC

On 6/24/15 3:46 AM, frnk...@iname.com wrote:
 Ding-ding-ding -- issuing rndc flushname . did the trick, Mark.
 
 I'd encourage this troubleshooting tip to be documented in one of those
 how-to guides.  I don't think waiting for a TTL is a good idea if most
 queries are failing with bad cache hit.
 
 Frank
 
 -Original Message-
 From: Mark Andrews [mailto:ma...@isc.org] 
 Sent: Tuesday, June 23, 2015 11:03 PM
 To: Frank Bulk
 Cc: bind-us...@isc.org
 Subject: Re: DNSSEC validation on 9.7.4 not working
 
 
 I suspect that the DNSKEY record for the root will be marked as a
 'answer' rather than 'secure' (rndc dumpdb) and flushing the cache
 will fix the issue as will waiting ~30703 seconds.  'rndc flushname .'
 should also work though I forget where we added flushname.
 
 Mark
 
 In message 005701d0ae2f$ef2798f0$cd76cad0$@iname.com, Frank Bulk writes:
 Here you go:

 root@nagios:/etc/bind# dig @127.0.0.1 +dnssec +cd ds com; dig @127.0.0.1
 +dnssec +cd dnskey .

 ;  DiG 9.7.3  @127.0.0.1 +dnssec +cd ds com
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 38536
 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags: do; udp: 4096
 ;; QUESTION SECTION:
 ;com.   IN  DS

 ;; ANSWER SECTION:
 com.86400   IN  DS  30909 8 2
 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
 com.86400   IN  RRSIG   DS 8 1 86400
 2015070317
 2015062316 48613 .
 ioJ6KyZ9ig0PsFBdo5jfM/9hLEX9qn06QaitkJubhcH3m/DPBi2o9xTu
 Cs9Aabwm/tSlGc+JVc3oBVSwv6LakHUY9v7aJn77pD244tnnlgNeR+z4
 kkZSn1Kp5tHmhKx8sNYe8Fe9rTA/9hC+3IokE949ppf+3CEyjJ4uhJhm lN0=

 ;; Query time: 54 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Tue Jun 23 22:41:31 2015
 ;; MSG SIZE  rcvd: 239


 ;  DiG 9.7.3  @127.0.0.1 +dnssec +cd dnskey .
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 11727
 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags: do; udp: 4096
 ;; QUESTION SECTION:
 ;.  IN  DNSKEY

 ;; ANSWER SECTION:
 .   30703   IN  DNSKEY  256 3 8
 AwEAAZyIkCwEYeG29NV+4cOdKE4DPng/4BqJeoOhKqzJbl+LR33TPWsr
 wBRfmAi9wvR/Qc6IV4MFMXjmkclXns+atIQZ9uQV3YAvKv/cVuO7Mneu
 MssIQixaMw+jp73R7zIUNMbLBgJRQXI57Rl+pvXBAkgHndVwv+aJkf7y GEuE9Dtj
 .   30703   IN  DNSKEY  256 3 8
 AwEAAa67bQck1JjopOOFc+iMISFcp/osWrEst2wbKbuQSUWu77QC9UHL
 ipiHgWN7JlqVAEjKITZz49hhkLmOpmLK55pTq+RD2kwoyNWk9cvpc+tS
 nIxT7i93O+3oVeLYjMWrkDAz7K45rObbHDuSBwYZKrcSIUCZnCpNMUtn PFl/04cb
 .   30703   IN  DNSKEY  257 3 8
 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
 FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
 bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
 X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
 W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
 Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=
 .   30703   IN  RRSIG   DNSKEY 8 0 172800
 20150705235959 2015062000 19036 .
 W6ZIOh5tJ1ph3C0c9Fqot+55jCewbk/cWRquGOeRnWkag7rx/XgsEfvd
 HLr1HsSIlag+lt1OvTlsLgvVk/yUcOAZA/NvMRPbFfbyrEi82YpZ70Z2
 B995qkT7dCf/3uBynAzubAPshUfEi7LuBy9bzyYPMvtRZptEnBz3xsAf
 4gmrRTX0BW66ve2xqvitZrPVH2WaYR70iJbJWbKKDCPl9rwEcit95gyi
 CNQLOIPFq2XgHDmo01Pr4evPbSowny6kNXzuDHgKQn1+BWX5zhbr74OE
 3FZXo2DUXm8BA5OhMY0bMg32kjzQLu+lxBWpaXabjFoALNFG4WRRdx1s 4+Wuhg==

 ;; Query time: 0 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Tue Jun 23 22:41:31 2015
 ;; MSG SIZE  rcvd: 883

 root@nagios:/etc/bind# date -u
 Wed Jun 24 03:41:52 UTC 2015
 root@nagios:/etc/bind#

 Frank

 -Original Message-
 From: Mark Andrews [mailto:ma...@isc.org] 
 Sent: Tuesday, June 23, 2015 10:31 PM
 To: Frank Bulk frnk...@iname.com
 Cc: bind-us...@isc.org
 Subject: Re: DNSSEC validation on 9.7.4 not working


 Should have asked for +dnssec on those queries.  Also date -u.


 In message 005601d0ae2c$b698b6c0$23ca2440$@iname.com, Frank Bulk
 writes:
 Mark,

 Sorry for top-posting -- my email client makes it difficult to do
 otherwise.

 Yes, I'm absolutely sure there's no software or physical firewall (we're
 an
 ISP), and there's also no load-balancer in front of this box.  I've also
 used the EDNS tests and I can get a 4000+ byte response.  There's also
 no
 forwarder configured.

 Here's the requested output:


 root@nagios:/etc/bind# dig @127.0.0.1 +cd ds com; dig @127.0.0.1 +cd
 dnskey
 .

 ;  DiG 9.7.3  @127.0.0.1 +cd ds com
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id

Re: DNSSEC validation on 9.7.4 not working

[Mark Andrews]

In message 003d01d0ae24$682fc080$388f4180$@iname.com, Frank Bulk writes:
 I'm running BIND 9.7.3 on Debian and having trouble configuring DNSSEC
 validation.  
 
 I'm using the excellent guides at
 http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html#easy-start-guide-
 for-recursive-servers and
 https://www.surf.nl/binaries/content/assets/surf/en/knowledgebase/2012/rappo
 rt_Deploying_DNSSEC_v20.pdf and http://dnssec.vs.uni-due.de/ which provide
 9.7.x configuration instructions and so I'm feeling a bit slow that I can't
 make this work.
 
 I'm have a copy of bind.keys from
 https://www.isc.org/downloads/bind/bind-keys/ in /etc/bind/
 
 This statement in /etc/bind/bind.conf:
 
 managed-keys {
   . initial-key 257 3 8
 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
 FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
 bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
 X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
 W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
 Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=;
 };
 
 and the following in /etc/bind/bind.conf.options:
 
 options {
snip
dnssec-enable yes;
dnssec-validation yes;
snip
 }
 
 But when I issue rdnc reconifg I immediately get repeated log lines about
 the following and then similar statements for each domains:
 
 23-Jun-2015 20:43:47.402 dnssec: info:   validating @0x7fcec948ce40: com DS:
 no valid signature found
 23-Jun-2015 20:43:47.402 dnssec: info:   validating @0x7fcec8c41bf0: com DS:
 no valid signature found
 23-Jun-2015 20:43:47.438 dnssec: info: validating @0x7fcec8c39b80: . NS: no
 valid signature found
 snip
 23-Jun-2015 20:43:48.750 dnssec: info: validating @0x7fced04fd9e0: . NS: no
 valid signature found
 23-Jun-2015 20:43:48.754 dnssec: info: validating @0x7fcee55996a0:
 a1075.dscg.akamai.net : bad cache hit (net/DS)
 23-Jun-2015 20:43:48.757 dnssec: info: validating @0x7fceca621970:
 wwwp.wip.rackspace.com : bad cache hit (com/DS)
 23-Jun-2015 20:43:48.759 dnssec: info: validating @0x7fceca621970:
 a1526.dscg.akamai.net : bad cache hit (net/DS)
 23-Jun-2015 20:43:48.759 dnssec: info: validating @0x7fced04fd9e0:
 a1784.dscg.akamai.net : bad cache hit (net/DS)
 23-Jun-2015 20:43:48.761 dnssec: info: validating @0x7fced04fd9e0:
 e1181.dscb.akamaiedge.net : bad cache hit (net/DS)
 
 Of course, once the TLDs aren't considered valid everything goes south.  
 
 What am I doing wrong?
 
 Regards,
 
 Frank Bulk

Are you sure that there isn't a firewall that is block RRSIGs getting
through or that you aren't using a forwarder that isn't also
validating.  These sorts of messages come when named is forced back
to plain DNS to get a response.

What do dig +cd ds com and dig +cd dnskey . return.  

Mark

 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
 from
  this list
 
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation on 9.7.4 not working

[Mark Andrews]

Should have asked for +dnssec on those queries.  Also date -u.


In message 005601d0ae2c$b698b6c0$23ca2440$@iname.com, Frank Bulk writes:
 Mark,
 
 Sorry for top-posting -- my email client makes it difficult to do otherwise.
 
 Yes, I'm absolutely sure there's no software or physical firewall (we're an
 ISP), and there's also no load-balancer in front of this box.  I've also
 used the EDNS tests and I can get a 4000+ byte response.  There's also no
 forwarder configured.
 
 Here's the requested output:
 
 
 root@nagios:/etc/bind# dig @127.0.0.1 +cd ds com; dig @127.0.0.1 +cd dnskey
 .
 
 ;  DiG 9.7.3  @127.0.0.1 +cd ds com
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 55498
 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;com.   IN  DS
 
 ;; ANSWER SECTION:
 com.86400   IN  DS  30909 8 2
 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
 
 ;; Query time: 17 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Tue Jun 23 22:17:58 2015
 ;; MSG SIZE  rcvd: 69
 
 ;; Truncated, retrying in TCP mode.
 
 ;  DiG 9.7.3  @127.0.0.1 +cd dnskey .
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 25167
 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;.  IN  DNSKEY
 
 ;; ANSWER SECTION:
 .   32115   IN  DNSKEY  256 3 8
 AwEAAa67bQck1JjopOOFc+iMISFcp/osWrEst2wbKbuQSUWu77QC9UHL
 ipiHgWN7JlqVAEjKITZz49hhkLmOpmLK55pTq+RD2kwoyNWk9cvpc+tS
 nIxT7i93O+3oVeLYjMWrkDAz7K45rObbHDuSBwYZKrcSIUCZnCpNMUtn PFl/04cb
 .   32115   IN  DNSKEY  257 3 8
 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
 FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
 bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
 X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
 W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
 Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=
 .   32115   IN  DNSKEY  256 3 8
 AwEAAZyIkCwEYeG29NV+4cOdKE4DPng/4BqJeoOhKqzJbl+LR33TPWsr
 wBRfmAi9wvR/Qc6IV4MFMXjmkclXns+atIQZ9uQV3YAvKv/cVuO7Mneu
 MssIQixaMw+jp73R7zIUNMbLBgJRQXI57Rl+pvXBAkgHndVwv+aJkf7y GEuE9Dtj
 
 ;; Query time: 0 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Tue Jun 23 22:17:59 2015
 ;; MSG SIZE  rcvd: 586
 
 
 Frank
 
 
 -Original Message-
 From: Mark Andrews [mailto:ma...@isc.org] 
 Sent: Tuesday, June 23, 2015 10:11 PM
 To: Frank Bulk frnk...@iname.com
 Cc: bind-us...@isc.org
 Subject: Re: DNSSEC validation on 9.7.4 not working
 
 
 In message 003d01d0ae24$682fc080$388f4180$@iname.com, Frank Bulk writes:
  I'm running BIND 9.7.3 on Debian and having trouble configuring DNSSEC
  validation.  
  
  I'm using the excellent guides at
 
 http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html#easy-start-guide-
  for-recursive-servers and
 
 https://www.surf.nl/binaries/content/assets/surf/en/knowledgebase/2012/rappo
  rt_Deploying_DNSSEC_v20.pdf and http://dnssec.vs.uni-due.de/ which provide
  9.7.x configuration instructions and so I'm feeling a bit slow that I
 can't
  make this work.
  
  I'm have a copy of bind.keys from
  https://www.isc.org/downloads/bind/bind-keys/ in /etc/bind/
  
  This statement in /etc/bind/bind.conf:
  
  managed-keys {
. initial-key 257 3 8
  AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
  FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
  bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
  X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
  W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
  Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=;
  };
  
  and the following in /etc/bind/bind.conf.options:
  
  options {
 snip
 dnssec-enable yes;
 dnssec-validation yes;
 snip
  }
  
  But when I issue rdnc reconifg I immediately get repeated log lines
 about
  the following and then similar statements for each domains:
  
  23-Jun-2015 20:43:47.402 dnssec: info:   validating @0x7fcec948ce40: com
 DS:
  no valid signature found
  23-Jun-2015 20:43:47.402 dnssec: info:   validating @0x7fcec8c41bf0: com
 DS:
  no valid signature found
  23-Jun-2015 20:43:47.438 dnssec: info: validating @0x7fcec8c39b80: . NS:
 no
  valid signature found
  snip
  23-Jun-2015 20:43:48.750 dnssec: info: validating @0x7fced04fd9e0: . NS:
 no
  valid signature found
  23-Jun-2015 20:43:48.754 dnssec: info: validating @0x7fcee55996a0:
  a1075.dscg.akamai.net : bad cache hit (net/DS)
  23-Jun-2015 20:43:48.757 dnssec: info: validating @0x7fceca621970:
  wwwp.wip.rackspace.com : bad cache hit (com/DS)
  23-Jun-2015 20:43:48.759 dnssec: info: validating @0x7fceca621970:
  a1526.dscg.akamai.net : bad cache

Re: dnssec validation issue

[Jaap Akkerhuis]

 Eray Aslan writes:

  On Thu, Jun 18, 2015 at 07:26:28PM -0700, Carl Byington wrote:
   On Fri, 2015-06-19 at 11:10 +1000, Mark Andrews wrote:
To use the keys in /etc/named.iscdlv.key set dnssec-validation
auto;
   New centos rpms at http://www.five-ten-sg.com/mapper/bind with a default
   named.conf that should actually work.
  
  With the root zone and most TLDs signed, I do not think it makes sense
  to use DLV anymore.  While a typical DNSSEC resolver configuration has
  DLV enabled, I personally make the effort to disable it.

Furthermore, the whole dlv register is going to disappear in 2017
as announced at https://www.isc.org/blogs/dlv/.

jaap
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec validation issue

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 2015-06-19 at 11:10 +1000, Mark Andrews wrote:

 You don't have any trust anchors active.

 To use the keys in /etc/named.iscdlv.key set dnssec-validation
 auto;

Thanks!!

New centos rpms at http://www.five-ten-sg.com/mapper/bind with a default
named.conf that should actually work.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlWDfboACgkQL6j7milTFsEsYgCcDCJgzbdD4quzkp8tI+hFIsfq
oQAAnRTCvYt4K9t98AjGnruiJqTxAj5y
=DOlX
-END PGP SIGNATURE-


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec validation issue

[Mark Andrews]

In message 1434674101.18744.119.ca...@ns.five-ten-sg.com, Carl Byington write
s:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 I have multiple centos6 boxes running 9.10.2-P1, and almost everything
 looks good. However, one box seems to not be doing dnssec validation. It
 is possible that this behavior predates the latest updates and I just
 never noticed it.
 
 A and B have essentially identical configuration, except that A is the
 master for some zones, and B is the slave pulling from A. Other than
 that, the /etc/named.conf is identical. A also has ipv6 connectivity,
 and B does not. The authoritative side works nicely on both. The
 recursive resolver is where the difference shows up.
 
 On A:
 
 dig www.dnssec-failed.org  @localhost
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 19813
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 11
 ;; ANSWER SECTION:
 www.dnssec-failed.org.  7178IN  A   68.87.109.242
 www.dnssec-failed.org.  7178IN  A   69.252.193.191
 
 
 
 On B:
 dig www.dnssec-failed.org  @localhost
 ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 4969
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
 

You don't have any trust anchors active.

To use the keys in /etc/named.iscdlv.key set dnssec-validation auto;

 /etc/named.conf:
 
 options {
 directory /var/named;
 allow-recursion { friends; };
 dnssec-enable yes;
 dnssec-validation yes;
 bindkeys-file /etc/named.iscdlv.key;
 managed-keys-directory /var/named/dynamic;
 listen-on-v6 {any;};
 ixfr-from-differences yes;
 max-journal-size 2m;
 notify yes;
 response-policy { zone rpz.five-ten-sg.com;}
 qname-wait-recurse no;
 filter--on-v4 yes;
 filter- { brokenv6; };
 rate-limit {
 responses-per-second 5;
 errors-per-second5;
 nxdomains-per-second 40;
 qps-scale300;
 exempt-clients { friends; };
 };
 };
 
 
 A is neither master nor slave for dnssec-failed.org, and that domain is
 not mentioned in the rpz zone.
 
 
 
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.14 (GNU/Linux)
 
 iEYEARECAAYFAlWDYtAACgkQL6j7milTFsHClQCeLKkTuQYlM4liB0UECG5Z4pui
 ujMAnj4wnUWqJj258pIlUFo0IONtkkEP
 =/QDW
 -END PGP SIGNATURE-
 
 
 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
  from this list
 
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec validation issue

[Eray Aslan]

On Thu, Jun 18, 2015 at 07:26:28PM -0700, Carl Byington wrote:
 On Fri, 2015-06-19 at 11:10 +1000, Mark Andrews wrote:
  To use the keys in /etc/named.iscdlv.key set dnssec-validation
  auto;
 New centos rpms at http://www.five-ten-sg.com/mapper/bind with a default
 named.conf that should actually work.

With the root zone and most TLDs signed, I do not think it makes sense
to use DLV anymore.  While a typical DNSSEC resolver configuration has
DLV enabled, I personally make the effort to disable it.

-- 
Eray
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec validation, managed keys, and chaos view

[b...@bitrate.net]

On 2011.02.28 00.20, Evan Hunt wrote:

if i comment out dnssec-lookaside, or the chaos view, things seem to work
ok.  i'm wondering what i can do to further diagnose what is happening.
below is my configuration, with the (presumably) uninteresting bits
removed.  i'm using 9.7.1, courtesy of ubuntu 10.10.


Try putting dnssec-lookaside auto; into all the non-chaos view
stanzas separately, and leaving it out of the chaos one.


even with dnssec-lookaside auto; only in the non-chaos view stanzas, it 
seems to still want to do something relating to the chaos view:


28-Feb-2011 14:12:44.702 general: info: managed-keys-zone ./IN/internal: 
loaded serial 2
28-Feb-2011 14:12:44.703 general: info: zone 
5.0.1.0.1.1.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN/external: loaded serial 
2010061300
28-Feb-2011 14:12:44.703 general: info: zone 
1.4.2.c.0.7.4.0.1.0.0.2.ip6.arpa/IN/external: loaded serial 2010061300
28-Feb-2011 14:12:44.705 general: info: zone bitrate.net/IN/external: 
loaded serial 2010061300
28-Feb-2011 14:12:44.706 general: info: zone dipswitch.net/IN/external: 
loaded serial 2010121001
28-Feb-2011 14:12:44.706 general: info: zone 
groundnoise.net/IN/external: loaded serial 2010061301
28-Feb-2011 14:12:44.706 general: info: zone sjva1991.org/IN/external: 
loaded serial 2010061300
28-Feb-2011 14:12:44.707 general: info: zone thielsen.org/IN/external: 
loaded serial 2010061300
28-Feb-2011 14:12:44.784 general: info: managed-keys-zone ./IN/external: 
loaded serial 8
28-Feb-2011 14:12:44.784 general: info: zone bind/CH/chaos: loaded 
serial 2009113000
28-Feb-2011 14:12:44.784 general: error: managed-keys-zone ./CH/chaos: 
loading from master file 
/etc/bind/keys/managed/5d5bddb577102d0a960bcf6fea9050c10fe5e9feddcb5c2170ccab872db9ee87.mkeys 
failed: file not found
28-Feb-2011 14:12:44.785 general: critical: 
rdata/generic/keydata_65533.c:222: REQUIRE(keydata-common.rdclass == 
rdclass) failed, back trace

28-Feb-2011 14:12:44.785 general: critical: #0 0x424290 in ??
28-Feb-2011 14:12:44.785 general: critical: #1 0x119773 in ??
28-Feb-2011 14:12:44.785 general: critical: #2 0xee4276 in ??
28-Feb-2011 14:12:44.785 general: critical: #3 0xee55b9 in ??
28-Feb-2011 14:12:44.785 general: critical: #4 0xf691d8 in ??
28-Feb-2011 14:12:44.785 general: critical: #5 0xf69d39 in ??
28-Feb-2011 14:12:44.785 general: critical: #6 0xf6ba24 in ??
28-Feb-2011 14:12:44.785 general: critical: #7 0x44219a in ??
28-Feb-2011 14:12:44.785 general: critical: #8 0x442400 in ??
28-Feb-2011 14:12:44.785 general: critical: #9 0x13c2cb in ??
28-Feb-2011 14:12:44.785 general: critical: #10 0xdb6cc9 in ??
28-Feb-2011 14:12:44.785 general: critical: #11 0x7d869e in ??
28-Feb-2011 14:12:44.785 general: critical: exiting (due to assertion 
failure)




modified config:

/etc/bind named-checkconf -p
options {
bindkeys-file /etc/bind/keys/dnssec/bind.keys;
blackhole {
bogon;
};
directory /var/cache/bind;
dump-file /var/log/named/named.dump;
interface-interval 0;
listen-on-v6 {
::1/128;
};
managed-keys-directory /etc/bind/keys/managed;
memstatistics-file /var/log/named/named.memstats;
recursing-file /var/log/named/namedrecursing;
statistics-file /var/log/named/named.stats;
allow-query-cache-on {
localhost;
private_lan;
};
allow-recursion {
localhost;
private_lan;
};
allow-recursion-on {
localhost;
private_lan;
};
minimal-responses yes;
allow-transfer {
localhost;
slaves;
};
zone-statistics yes;
};

view internal in {
match-clients {
localhost;
private_lan;
};

zone example.com {
type master;
file /var/lib/bind/internal/example.com;
allow-update {
key ddns-key-1;
};
};
dnssec-lookaside auto ;
};

view external in {
match-clients {
any;
};
zone example.com {
type master;
file /etc/bind/zones/external/example.com;
};
dnssec-lookaside auto ;
};
view chaos chaos {
match-clients {
any;
};
zone . {
type hint;
file /dev/null;
};
zone bind {
type master;
file /etc/bind/zones/system/db.bind;
};
allow-query {
localhost;
};
allow-transfer {
none;
};
};
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec validation, managed keys, and chaos view

[Evan Hunt]

 even with dnssec-lookaside auto; only in the non-chaos view stanzas, it 
 seems to still want to do something relating to the chaos view:

Ah well, thanks for checking.  Turns out managed keys cross-link between
the views incorrectly.  There's a fix in review, I'll send you a patch
later today.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec validation, managed keys, and chaos view

[Evan Hunt]

 if i comment out dnssec-lookaside, or the chaos view, things seem to work
 ok.  i'm wondering what i can do to further diagnose what is happening.
 below is my configuration, with the (presumably) uninteresting bits
 removed.  i'm using 9.7.1, courtesy of ubuntu 10.10.

Try putting dnssec-lookaside auto; into all the non-chaos view
stanzas separately, and leaving it out of the chaos one.

In order for DLV to work, you server needs to be able to reach dlv.isc.org,
which isn't possible in a class-CH view.  The core dump is a particularly
pathological failure mode, but even if we fix that, the configuration
you're using still wouldn't work right.

I think named should reject or warn-and-ignore when it encounters 
managed-keys or dnssec-lookaside statements in non-IN views.  It hadn't
occurred to me to have it check for that; thanks!

--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation on combined auth+recursive server

[Eivind Olsen]

(Resending it here, didn't mean to reply just to you Alan)

 On 1/6/2011 3:38 AM, Eivind Olsen wrote:
 (Yes, I know it's best practice to combine the authoritative + recursive
 functionality)
 [...] it's NOT best [...]

Yep, I knew that. Embarassing of me to miss that slightly important
NOT-word :D

Thankfully I haven't mixed DNSSEC into this yet, and this has given me yet
another reason to keep authoritative + recursive functions separate.

Regards
Eivind Olsen

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation works with DLV, but not with just trusted-key

[Alan Clegg]

Hanno Böck wrote:


dig baddata-A.test.dnssec-tools.org @localhost


There is no DS record for dnssec-tools.org in .org (chain of trust is 
broken), so you can't validate the response -- thus the data being 
passed back to you.


AlanC
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation works with DLV, but not with just trusted-key

[Hanno Böck]

Am Mittwoch 25 November 2009 schrieb Alan Clegg:
 There is no DS record for dnssec-tools.org in .org (chain of trust is
 broken), so you can't validate the response -- thus the data being
 passed back to you.

Ok, that explains it.

Are there any example domains with known-broken dnssec records with a full 
trust chain?

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de

http://schokokeks.org - professional webhosting


signature.asc
Description: This is a digitally signed message part.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation works with DLV, but not with just trusted-key

[Alan Clegg]

Hanno Böck wrote:

Am Mittwoch 25 November 2009 schrieb Alan Clegg:

There is no DS record for dnssec-tools.org in .org (chain of trust is
broken), so you can't validate the response -- thus the data being
passed back to you.


Ok, that explains it.

Are there any example domains with known-broken dnssec records with a full 
trust chain?


I've been meaning to set some up, but at this moment, I'm not aware of any.

Setting up your trust-anchor with the DNSKEY from dnssec-tools.org would 
be only one level worse than using the DNSKEY from .org


Setting up validator using the key from dnssec-tools.org should be able 
to prove your point...


AlanC
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation works with DLV, but not with just trusted-key

[Mark Andrews]

Or one could use DLV to provide the trust linkage.

dnssec-tools.org.dlv.isc.org. 3499 IN   DLV 54556 5 1 
11A4026F4E09B1C106AAF3AC81A37AA537B8A3E6
dnssec-tools.org.dlv.isc.org. 3499 IN   DLV 54556 5 2 
6B026928292D452A5CC37B3EF327F27F50A29936CB31E664EB066D71 A476E282

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC validation works with DLV, but not with just trusted-key

[Mark Andrews]

In message 200911252202.napm2asg000...@drugs.dv.isc.org, Mark Andrews writes:
 
 Or one could use DLV to provide the trust linkage.
 
 dnssec-tools.org.dlv.isc.org. 3499 IN   DLV 54556 5 1 
 11A4026F4E09B1C106AAF3AC81A37AA537B8A3E6
 dnssec-tools.org.dlv.isc.org. 3499 IN   DLV 54556 5 2 
 6B026928292D452A5CC37B3EF327F27F50A29936CB31E664EB066D71 A476E
 282

Should have read the subject more closely. :-)

In any case as Alan said, there needs to be a trusted path from a
trust anchor to the data.  DLV provides that trusted path.  ORG
will soon once they leave the friends and family stage.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users