Discussion:
DNSSEC and secondary DNS servers
@lbutlr
2018-09-08 13:58:11 UTC
Permalink
So, I setup up DNSSEC on my authoritative bind 9.12 server, which was very straightforward and works fine:

dig covisp.net +dnssec +short @8.8.8.8
65.121.55.42
A 7 2 86400 20181008122535 20180908122535 17363 covisp.net. pkpVdFONJ2dYN+7wQ4pVcQTlWIThY3+mbNdXsE8p5uWiLNvIefVT32JE i9itA3Si91/pImofmPnLPbxRbLzWt+dSfbxBoHaoCYK1ZCngw/vy9QlG 36Um0De5ItCC/GuflXUnBKmEJKx0pQOlvqSnkRSV75yLnAw3NA0BdKnf CBJP9QLQH/A1vojRafIER5MNM34lKfJC9QrMDBiUBYzrv3i/2QK3gE7t 8Y1Zpoemux8Uz/zps1I/pmjVAIixk2ilVOLDXkeS6Ta4ODrWayyuFM8b xwkodXsMtFAx5PhkVyHT5zJyScYYzC82aZs7fTmA6F01saabVsxIYAi6 78upgA==

But now, what do I need to do for other DNS servers? Is it enough to simply add

dnssec-enable yes;
dnssec-validation yes;
managed-keys-directory "/usr/local/etc/namedb/working/keys";

? Should it simply validate the key with the primary and go from there?

I tried this, but trying to do a dig +dnssec on the secondary DNS doesn’t return the record, so I think there must be something else.


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

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailm
Niall O'Reilly
2018-09-08 15:59:41 UTC
Permalink
Post by @lbutlr
so I think there must be something else.
You might need to so some other housekeeping:

https://zonemaster.net/domain_check
http://dnsviz.net/d/covisp.net/dnssec/

/Niall
@lbutlr
2018-09-08 17:36:16 UTC
Permalink
Post by Niall O'Reilly
Post by @lbutlr
so I think there must be something else.
https://zonemaster.net/domain_check
http://dnsviz.net/d/covisp.net/dnssec/
Oh, well, that is interesting. I though Bind always listened on port 53 for both TCP/UDP.

# sockstat -4 -l | grep :53
bind named 48714 21 tcp4 65.121.55.42:53 *:*
bind named 48714 23 tcp4 127.0.0.1:53 *:*
bind named 48714 512 udp4 65.121.55.42:53 *:*
bind named 48714 513 udp4 65.121.55.42:53 *:*
bind named 48714 514 udp4 65.121.55.42:53 *:*
bind named 48714 518 udp4 127.0.0.1:53 *:*
bind named 48714 519 udp4 127.0.0.1:53 *:*
bind named 48714 520 udp4 127.0.0.1:53 *:*

And there’s nothing interesting in pfctl

# pfctl -s rules
block drop in quick on em0 from <sshguard> to any label "sshguardblock"
block drop in quick on em0 from <badguys> to any
pass in quick on em0 proto tcp from <goodguys> to (em0) port = ssh flags S/SA keep state
pass in on em0 proto tcp from any to (em0) port = ssh flags S/SA keep state (source-track rule, max-src-conn 5, max-src-conn-rate 4/300, overload <badguys> flush global, src.track 300)
--
Man is born free, but is everywhere in chains.

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

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bi
Grant Taylor via bind-users
2018-09-08 16:18:45 UTC
Permalink
Post by @lbutlr
what do I need to do for other DNS servers?
I don't think you need to do anything special.

The zone signatures come form and are managed by the master name server.
The secondary name server(s) is (are) just additional servers with
copies of the zone.

You /might/ want to look at something to ensure that the zone is not
corrupted during the typical slave process. (New mirror zones come to
mind, but I don't know enough about them.)

I know that I've been running DNSSEC on my zones for years and have
never done anything special on the slave DNS servers. Some of which are
even hosted by other companies that I wouldn't give any DNSSEC keying
material to. (Besides, they don't offer anything like that.)
--
Grant. . . .
unix || die
Mark Elkins
2018-09-08 16:21:34 UTC
Permalink
Some clarification....

Have you DNSSEC Signed your Domain - that is "covisp.net" because I
don't see any DS records for it in the "net" zone.

dig @a.gtld-servers.net. covisp.net ds
flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
returns the SOA for NET - so I know I got to the right place but there
was no answer...

If you mean you want to switch on DNSSEC for recursion - that is - when
you look up names and want DNSSEC protection - you should not do that on
your authoritative servers. If an authoritative server has a DNSSEC
signed zone and you ask it directly (e.g. with DIG) - it will set the
"AA" flag for that domain but never set the AD bit.

In my case, posix.co.za is signed and if I ask my local DNS Server which
is DNSSEC aware - I get...

$ dig posix.co.za a
...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
posix.co.za.        3600    IN    A    192.96.24.1
...
;; SERVER: 127.0.0.1#53(127.0.0.1)

If I ask my authoritative (for "posix.co.za") Nameserver for the same:

$ dig posix.co.za a @secdns1.posix.co.za
...
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6
...
posix.co.za.        3600    IN    A    192.96.24.1
...
;; SERVER: 192.96.24.81#53(192.96.24.81)

Notice there is no AD bit, just AA.

In a new install of bind (on my Linux Laptop: BIND 9.11.2-P1 )  I think
you'll find DNSSEC is already switched on otherwise you want:

options {
        dnssec-enable yes;
        dnssec-validation auto;
};

On an Authoritative system - anyone can query it but only for your
domain and there should be no recursion
allow-recursion { none; };

On a Recursive server, recursion should be on but only for a few trusted
people...
allow-recursion { trusted; };     // Trusted is only my local networks

Thus Recursive and Authoritative Nameservers should *ideally* be on
separate servers (virtual or physical)
Post by @lbutlr
65.121.55.42
A 7 2 86400 20181008122535 20180908122535 17363 covisp.net. pkpVdFONJ2dYN+7wQ4pVcQTlWIThY3+mbNdXsE8p5uWiLNvIefVT32JE i9itA3Si91/pImofmPnLPbxRbLzWt+dSfbxBoHaoCYK1ZCngw/vy9QlG 36Um0De5ItCC/GuflXUnBKmEJKx0pQOlvqSnkRSV75yLnAw3NA0BdKnf CBJP9QLQH/A1vojRafIER5MNM34lKfJC9QrMDBiUBYzrv3i/2QK3gE7t 8Y1Zpoemux8Uz/zps1I/pmjVAIixk2ilVOLDXkeS6Ta4ODrWayyuFM8b xwkodXsMtFAx5PhkVyHT5zJyScYYzC82aZs7fTmA6F01saabVsxIYAi6 78upgA==
But now, what do I need to do for other DNS servers? Is it enough to simply add
dnssec-enable yes;
dnssec-validation yes;
managed-keys-directory "/usr/local/etc/namedb/working/keys";
? Should it simply validate the key with the primary and go from there?
I tried this, but trying to do a dig +dnssec on the secondary DNS doesn’t return the record, so I think there must be something else.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark James ELKINS - Posix Systems - (South) Africa
***@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-***@lists.isc.org
https://lists.isc.org/ma
@lbutlr
2018-09-08 19:49:15 UTC
Permalink
I need to check that I am supposed to generate the digest.
to check *HOW* I am supposed to generate the digest.
--
Ille Qui Nos Omnes Servabit

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

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
LuKreme
2018-09-09 18:59:51 UTC
Permalink
Post by Mark Elkins
Have you DNSSEC Signed your Domain - that is "covisp.net" because I
don't see any DS records for it in the "net" zone.
I think I have everything set now and am hopping the two errors I have about validation are a matter of waiting for hover to propagate.

“None of the 2 DNSKEY records could be validated by any of the 2 DS records”

Thanks for all your help. We'll see if I still show this as broken tomorrow.
--
My main job is trying to come up with new and innovative and effective ways to reject even more mail. I'm up to about 97% now.
Mark Elkins
2018-09-09 20:58:59 UTC
Permalink
(Seems I can't reply directly to the author)

$ dig covisp.net ds
; <<>> DiG 9.11.2-P1 <<>> covisp.net ds
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21696
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
covisp.net.        86352    IN    DS    1 7 1
E59B549EC68D577C44A4E13542257CA44FE21970
covisp.net.        86352    IN    DS    2 7 2
051033AF1BC909BE73FCFE4B59B1BDD2B8D7F8BF7BD840174AC1DEF7 14895D02

Umm... this initially looks great but something is seriously strange.
The first numerical value after DS should be the Key ID (or Key Tag). I
really doubt that you would (randomly) create two different DNSKEY
records with sequential Key-ID's (Tags) starting from "1"... its usually
a relatively random value between 1 and 2^16

Also as an aside - many people are no longer putting the SHA-1 Digest
type DS record in their parent, just the longer (more secure?) SHA-256
(Digest Type 2) record.

As the root uses Algorithm 8 - many people also use algorithm 8 - you
are using algorithm 7. Algorithm roll-overs are a pain so if you can -
move straight to 8.

I also can not detect a DNSKEY in your zone?
dig covisp.net dnskey +cd
...gives your SOA.
Without the "+cd" (ignore any DNSSEC validation) - I get a SERVFAIL.

Adding DS records into your parent should be the last part of the
process in securing your Zone with DNSSEC.

I really think you need to start over. What are you using to sign your
zone with? Maybe I can help.
Take a look at https://dnssec.co.za
Post by LuKreme
Post by Mark Elkins
Have you DNSSEC Signed your Domain - that is "covisp.net
<http://covisp.net>" because I
don't see any DS records for it in the "net" zone.
I think I have everything set now and am hopping the two errors I have
about validation are a matter of waiting for hover to propagate.
“None of the 2 DNSKEY records could be validated by any of the 2 DS records”
Thanks for all your help. We'll see if I still show this as broken tomorrow.
-- 
My main job is trying to come up with new and innovative and effective
ways to reject even more mail. I'm up to about 97% now.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark James ELKINS - Posix Systems - (South) Africa
***@posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
@lbutlr
2018-09-12 07:34:35 UTC
Permalink
Umm... this initially looks great but something is seriously strange. The first numerical value after DS should be the Key ID (or Key Tag). I really doubt that you would (randomly) create two different DNSKEY records with sequential Key-ID's (Tags) starting from "1"... its usually a relatively random value between 1 and 2^16
Yes, that was a mistake in the configuration.
Also as an aside - many people are no longer putting the SHA-1 Digest type DS record in their parent, just the longer (more secure?) SHA-256 (Digest Type 2) record.
Thanks, I keep that in mind.
As the root uses Algorithm 8 - many people also use algorithm 8 - you are using algorithm 7. Algorithm roll-overs are a pain so if you can - move straight to 8.
And that.
I also can not detect a DNSKEY in your zone?
dig covisp.net dnskey +cd
...gives your SOA.
Without the "+cd" (ignore any DNSSEC validation) - I get a SERVFAIL.
Yes, I was in the midst of futzing with things at the time.
Adding DS records into your parent should be the last part of the process in securing your Zone with DNSSEC.
I've pulled the DNSSEC entirely for right now as there is still some research I need to do (things like renewal, automating the process for other domains, etc).
--
"I've had a perfectly wonderful evening. But this wasn't it." - Groucho
Marx

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

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