permissions for DNSSEC zone signing

[David Newman]

FreeBSD 9.1-RELEASE-p4, BIND 9.9.3-P1 ESV installed from ports

What are the correct directory and file permissions for DNSSEC static
zone signing with bind?

By default, everything in /var/named/etc/namedb is owned by bind except
for the master directory. For example:

drwxr-xr-x bind wheel dynamic
drwxr-xr-x bind bind managed-keys
drwxr-xr-x root wheel master
-rw-r--r-- bind wheel named.conf
-rw-r--r-- bind wheel named.root
-r--r--r-- bind wheel rndc.conf
drwxr-xr-x bind wheel slave
drwxr-xr-x bind wheel working

Without DNSSEC, this is fine. With DNSSEC enabled, there are permissions
errors in /var/log/messages after restarting named, because bind can't
create the jnl/jbk/signed files. For example:

Jul 23 14:57:16 hostname named[42000]: master/example.org.db.jbk:
create: permission denied

Here are the DNSSEC-specific bits from named.conf:
options {
..
managed-keys-directory "/etc/namedb/managed-keys";
dnssec-enable yes;
dnssec-lookaside auto;
dnssec-validation auto;
..
}

zone "example.org" {
type master;
file "master/example.org.db";
allow-query { any; };
allow-transfer { xfer; };
key-directory "/etc/namedb/managed-keys";
inline-signing yes;
auto-dnssec maintain;
};

There is a valid KSK and ZSK for this zone in managed-keys.

Changing ownership of the master directory results in a complaint when
restarting named that master wants to be owned by root.

Thanks in advance for clues on sorting out this permissions problem.

dn

___
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: permissions for DNSSEC zone signing

[David Newman]

On 7/23/13 3:44 PM, Mark Andrews wrote:
> In message <51ef00af.4090...@networktest.com>, David Newman writes:
>> FreeBSD 9.1-RELEASE-p4, BIND 9.9.3-P1 ESV installed from ports
>>
>> What are the correct directory and file permissions for DNSSEC static
>> zone signing with bind?
>>
>> By default, everything in /var/named/etc/namedb is owned by bind except
>> for the master directory. For example:
>>
>> drwxr-xr-x bind wheel dynamic
>> drwxr-xr-x bind bind managed-keys
>> drwxr-xr-x root wheel master
>> -rw-r--r-- bind wheel named.conf
>> -rw-r--r-- bind wheel named.root
>> -r--r--r-- bind wheel rndc.conf
>> drwxr-xr-x bind wheel slave
>> drwxr-xr-x bind wheel working
>>
>> Without DNSSEC, this is fine. With DNSSEC enabled, there are permissions
>> errors in /var/log/messages after restarting named, because bind can't
>> create the jnl/jbk/signed files. For example:
>>
>> Jul 23 14:57:16 hostname named[42000]: master/example.org.db.jbk:
>> create: permission denied
>>
>> Here are the DNSSEC-specific bits from named.conf:
>> options {
>>  ..
>> managed-keys-directory "/etc/namedb/managed-keys";
>> dnssec-enable yes;
>> dnssec-lookaside auto;
>> dnssec-validation auto;
>>  ..
>> }
>>
>> zone "example.org" {
>> type master;
>> file "master/example.org.db";
>> allow-query { any; };
>> allow-transfer { xfer; };
>> key-directory "/etc/namedb/managed-keys";
>> inline-signing yes;
>> auto-dnssec maintain;
>> };
>>
>> There is a valid KSK and ZSK for this zone in managed-keys.
>>
>> Changing ownership of the master directory results in a complaint when
>> restarting named that master wants to be owned by root.
> 
> Rename the file to "dynamic/example.org.db" and update named.conf.
> The directory "dynamic" has permissions set up for dynamic master files
> which this zone is.

Thanks, Mark!

This is a *static* zone file but signing works as expected if:

1. the zone file is set up in a directory which bind can write to (e.g.,
/var/named/etc/namedb/dynamic, even for static zones); and

2. the zone file's serial number increments. (named did not create a
filename.jnl file until I incremented the zone file's serial number.)

Thanks very much for sorting out this permissions problem.

dn


> 
>> Thanks in advance for clues on sorting out this permissions problem.
>>
>> dn
>>
>> ___
>> 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: "auto-dnssec maintain;" and key "missing or inactive and has no replacement"

[David Newman]

On 7/24/13 2:29 AM, Stephane Bortzmeyer wrote:
> I'm trying "auto-dnssec maintain;" with a BIND 9.9.3-P1. My
> configuration is:
> 
> options {
> directory "/tmp/bind";
>   key-directory "/tmp/bind"; 

Not sure if this is the problem, but have you tried with
"managed-keys-directory" in options instead of "key-directory"?

You would still use "key-directory" in each zone statement.

Per the Bind 9 docs, there's a small difference between the two:

http://dotat.at/tmp/arm98/Bv9ARM.ch06.html

key-directory

When performing dynamic update of secure zones, the directory where
the public and private DNSSEC key files should be found, if different
than the current working directory. (Note that this option has no effect
on the paths for files containing non-DNSSEC keys such as bind.keys,
rndc.key or session.key.)

managed-keys-directory

The directory used to hold the files used to track managed keys. By
default it is the working directory. It there are no views then the file
managed-keys.bind otherwise a SHA256 hash of the view name is used with
.mkeys extension added.

dn


> };
> 
> 
> zone "example" {
> type master;
> file "example";
>   inline-signing yes;
> auto-dnssec maintain;
> };
> 
> Apparently, everything works. The key I created and put in /tmp/bind
> is used, the zone is signed, everyone is happy.
> 
> But I get messages:
> 
> 24-Jul-2013 07:39:25.480 zone example/IN (signed): Key 
> example/RSASHA256/46747 missing or inactive and has no replacement: retaining 
> signatures.
> 
> Which I do not understand. They key is there:
> 
> % ls -lt /tmp/bind/Kexample.+008+46747*
> -rw-r--r-- 1 bortzmeyer bortzmeyer  597 Jul 23 12:02 
> /tmp/bind/Kexample.+008+46747.key
> -rw--- 1 bortzmeyer bortzmeyer 1776 Jul 23 12:02 
> /tmp/bind/Kexample.+008+46747.private
> 
> And is certainly active:
> 
> % cat /tmp/bind/Kexample.+008+46747.key 
> ; This is a key-signing key, keyid 46747, for example.
> ; Created: 2013072315 (Tue Jul 23 12:00:05 2013)
> ; Publish: 2013072315 (Tue Jul 23 12:00:05 2013)
> ; Activate: 20130723070226 (Tue Jul 23 09:02:26 2013)
> ...
> 
> And, despite the message "retaining signatures", signatures *are*
> regenerated periodically, even after the warning:
> 
> example.  600 IN RRSIG DNSKEY 8 1 600 20130725045802 (
>   20130724043925 46747 example.
>   rkNJdCp8PV3PzEsVc6efh/mBY3eHZcL3712ELD2g7gte
> ...
> ___
> 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: How to get AD flag

[David Newman]

On 8/1/13 10:48 PM, rams wrote:
> Thanks david,
> This the response i get
> dig +short rs.dns-oarc.net  txt @
> rst.x3827.rs.dns-oarc.net .
> rst.x3837.x3827.rs.dns-oarc.net .
> rst.x3843.x3837.x3827.rs.dns-oarc.net
> .
> "50.16.87.189 sent EDNS buffer size 4096"
> "50.16.87.189 DNS reply size limit is at least 3843 bytes"

That looks OK, but the forwarder might still be broken (i.e., it might
strip replies).

Stephane Bortzmeyer's three possibilities are all plausible. I'd
recommend beginning with queries of known-valid domains (e.g., ietf.org,
isc.org) against known-valid resolvers (e.g., 8.8.8.8) and then working
from there.

dn


___
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

moving DNSSEC to a hidden master

[David Newman]

Is there a recommended order of operations when moving DNSSEC-enabled
nameservers to a hidden-master setup?

I'm hoping it's just as simple as moving all these files into place on
the hidden master:

*.key
*.private
managed-keys.bind
*.jbk
*.jnl
*.signed
*.signed.jnl

If not, what do I need to do? In theory I suppose I could crank all TTLs
down to 0 and generate new keys on the hidden master and generate new DS
keys for the registrar, but is that necessary?

This is all on bind 9.9.4.

Thanks.

dn

___
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: moving DNSSEC to a hidden master

[David Newman]

On 10/1/13 2:16 PM, David Newman wrote:
> Is there a recommended order of operations when moving DNSSEC-enabled
> nameservers to a hidden-master setup?

Actually, this is really a more general question: Is there a recommended
order of operations when migrating zones between any two DNSSEC-enabled
nameservers, assuming the same version of bind on each?

thanks

dn


> 
> I'm hoping it's just as simple as moving all these files into place on
> the hidden master:
> 
> *.key
> *.private
> managed-keys.bind
> *.jbk
> *.jnl
> *.signed
> *.signed.jnl
> 
> If not, what do I need to do? In theory I suppose I could crank all TTLs
> down to 0 and generate new keys on the hidden master and generate new DS
> keys for the registrar, but is that necessary?
> 
> This is all on bind 9.9.4.
> 
> Thanks.
> 
> dn
> 
> ___
> 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: moving DNSSEC to a hidden master

[David Newman]

Thanks all for your responses.

On 10/1/13 6:42 PM, Mark Andrews wrote:
> As Alan said copy the .key and .private files over.
> 
> Disable updating on the old master.
> 
> Transfer the zone contents by setting up as a slave
> using "masterfile-format text"; or using by using dig.
> This will give you the most up to date version of the
> zone.
> 
>   dig axfr zone +onesoa @oldmaster
> 
> Check that the new server is working 

Converting the new secondary to a new master worked. But incrementing
the zone's serial number did not, producing an error after 'rndc reload'
like this:

Oct  3 16:00:29 host named[35249]: malformed transaction:
dynamic/mydomain.com/mydomain.com.db.jnl last serial 2013092701 !=
transaction first serial 2013092700

> and you can update
> the zone by using nsupdate.

Although the zone file lives under dynamic/mydomain.com so DNSSEC
updates can happen, I don't have dynamic updates configured, so nsupdate
won't work. This arrangement -- with static zone files under the dynamic
directory -- worked OK on the old master. Permissions are the same on both.

This thread suggested the journal issue was separate views pointing to
the same zone file:

https://lists.isc.org/pipermail/bind-users/2008-June/070807.html

Indeed I had pointers to the same zone file in separate views, but
removing them and restarting named did not clear the issue. Now I have
the zone in just one view, and still can't manually increment the serial
number without that journal complaint.

Thanks in advance for clues on resolving the journal version issue.

dn

> 
> Convert the old master server into a slave.
> 
> Update the other slaves to talk to a new master.
> 
___
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: moving DNSSEC to a hidden master

[David Newman]

On 10/3/13 5:27 PM, Sten Carlsen wrote:
> This works for me and is the standard method:
> 
> rndc freeze
> update serial
> rndc thaw

Bingo. Thanks!

dn

> 
> Rndc freeze merges the .jnl files into the zone files and stops dynamic
> updates. Thaw allows dynamic updates to resume.
> 
> On 04/10/13 02.12, David Newman wrote:
>> Thanks all for your responses.
>>
>> On 10/1/13 6:42 PM, Mark Andrews wrote:
>>> As Alan said copy the .key and .private files over.
>>>
>>> Disable updating on the old master.
>>>
>>> Transfer the zone contents by setting up as a slave
>>> using "masterfile-format text"; or using by using dig.
>>> This will give you the most up to date version of the
>>> zone.
>>>
>>> dig axfr zone +onesoa @oldmaster
>>>
>>> Check that the new server is working 
>> Converting the new secondary to a new master worked. But incrementing
>> the zone's serial number did not, producing an error after 'rndc reload'
>> like this:
>>
>> Oct  3 16:00:29 host named[35249]: malformed transaction:
>> dynamic/mydomain.com/mydomain.com.db.jnl last serial 2013092701 !=
>> transaction first serial 2013092700
>>
>>> and you can update
>>> the zone by using nsupdate.
>> Although the zone file lives under dynamic/mydomain.com so DNSSEC
>> updates can happen, I don't have dynamic updates configured, so nsupdate
>> won't work. This arrangement -- with static zone files under the dynamic
>> directory -- worked OK on the old master. Permissions are the same on both.
>>
>> This thread suggested the journal issue was separate views pointing to
>> the same zone file:
>>
>> https://lists.isc.org/pipermail/bind-users/2008-June/070807.html
>>
>> Indeed I had pointers to the same zone file in separate views, but
>> removing them and restarting named did not clear the issue. Now I have
>> the zone in just one view, and still can't manually increment the serial
>> number without that journal complaint.
>>
>> Thanks in advance for clues on resolving the journal version issue.
>>
>> dn
>>
>>> Convert the old master server into a slave.
>>>
>>> Update the other slaves to talk to a new master.
>>>
>> ___
>> 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
> 
> -- 
> Best regards
> 
> Sten Carlsen
> 
> No improvements come from shouting:
> 
>"MALE BOVINE MANURE!!!" 
> 

___
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

inactivating and deleting DNSSEC keys

[David Newman]

bind 9.9.4

How to troubleshoot issues when keys are supposed to be invalidated or
deleted on specific dates, but aren't?

In this case, a KSK was supposed to be inactivated on 29 September 2013
and deleted on 9 October 2013.

>From the .key file:

; This is a key-signing key, keyid 56989, for networktest.com.
; Created: 20130723214837 (Tue Jul 23 14:48:37 2013)
; Publish: 20130723214837 (Tue Jul 23 14:48:37 2013)
; Activate: 20130723214837 (Tue Jul 23 14:48:37 2013)
; Inactive: 20130929201510 (Sun Sep 29 13:15:10 2013)
; Delete: 20131009201510 (Wed Oct  9 13:15:10 2013)

Problem is, dig says the key is still active, and will be until 29
October 2013:

$ dig networktest.com @localhost +multi rrsig | grep 56989

20131029191450 20130929181450 56989 networktest.com.

named.conf has this:

options {
..
// DNSSEC stuff
managed-keys-directory "managed-keys";
dnssec-enable yes;
dnssec-validation auto;
}

..

zone "networktest.com" {
type master;
..
key-directory "managed-keys/networktest.com";
inline-signing yes;
auto-dnssec maintain;
};

$ ls -l managed-keys/networktest.com/ | grep 56989
-rw-r-  1 bind  bind   719 Jul 31 13:15 Knetworktest.com.+008+56989.key
-rw---  1 bind  bind  1824 Jul 31 13:15
Knetworktest.com.+008+56989.private

I don't understand the disconnect between the configured inactive/delete
times and the ones returned by dig, and presume this is because I've
misconfigured something.

Thanks in advance for troubleshooting clues.

dn

___
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: inactivating and deleting DNSSEC keys

[David Newman]

On 10/8/13 3:51 PM, Alan Clegg wrote:
> 
> On Oct 8, 2013, at 6:42 PM, David Newman  
> wrote:
> 
>> bind 9.9.4
>> 
>> How to troubleshoot issues when keys are supposed to be 
>> invalidated or deleted on specific dates, but aren't?
>> 
>> In this case, a KSK was supposed to be inactivated on 29 
>> September 2013 and deleted on 9 October 2013.
>> 
>> From the .key file:
>> 
>> ; This is a key-signing key, keyid 56989, for networktest.com. ; 
>> Created: 20130723214837 (Tue Jul 23 14:48:37 2013) ; Publish: 
>> 20130723214837 (Tue Jul 23 14:48:37 2013) ; Activate: 
>> 20130723214837 (Tue Jul 23 14:48:37 2013) ; Inactive: 
>> 20130929201510 (Sun Sep 29 13:15:10 2013) ; Delete: 
>> 20131009201510 (Wed Oct  9 13:15:10 2013)
>> 
>> Problem is, dig says the key is still active, and will be until 
>> 29 October 2013:
>> 
>> $ dig networktest.com @localhost +multi rrsig | grep 56989 
>> 20131029191450 20130929181450 56989 networktest.com.
> 
> You don't provide all of the record.  It's an RRSIG that is still 
> within it's lifetime.
> 
> Do a dig for "DNSKEY" retype at the zone name and see what you
> get back.

I think this is what you're asking for, but if not please let me know.
Thanks.

dn

$ dig networktest.com @localhost +multi dnskey

; <<>> DiG 9.9.4 <<>> networktest.com @localhost +multi dnskey
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11568
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
networktest.com.3600 IN DNSKEY 256 3 8 (
AwEAAc/YdGPWOi57E4yj6bYw55o9XXYP2V8xNhRFBtQM
6iGLrf+OHzIpA2ffPhL8CHOZxkH6nIKNDzQ9sWnih1O4
BDSI062F8AextdeA2V0cLin43y3YDL0LK8SFaNMPKdwR
hAD3KIXtbvZRFBU1iUEUoRy6ZpO8K0HRSyQgYa5SdqP5
) ; ZSK; alg = RSASHA256; key id = 16788
networktest.com.3600 IN DNSKEY 257 3 8 (
AwEAAdAmmvkvbIIRoq48aqHToIIcGKImBoKdqUyslOyM
rRH5mxN7o0wc50ib2g6E+EtBWCn3UqrqpGcru1ZHkDoJ
eCf2JbSKViOJPRWgAx1JfVFwO6eL4lDcMGb6OF0OxPCc
9OMkUo6B/76fORJgelbpqKscHAYCo92npR+XpZMoj/Gj
S3sDn8k62eIXkbAFOXQuuGFVfQ0chKSv0QctlcnsTHkF
NRmjwVjN5xYPy0kn0bXVCC8Iiah2RqQAdV4jij2c4iM7
STwlnKYBWslQZGWi8LQgjLgUNOvh0dfWdLCYiQR7WwPf
W5Y2RxgvZ3SmG1+ntX5ps+VU7jKzXnDiPWwKp9M=
) ; KSK; alg = RSASHA256; key id = 56989
networktest.com.3600 IN DNSKEY 256 3 8 (
AwEAAdPqBf8AF3+QQAP2olQA7vCDieElo65jyWdphIuI
T2Awiwd07a83gXgL9Ezp16b8miO1eOSBOUB+0fmBSI6h
IWCyFNAuh2+P5eCCD+gJq/u2y+ItnyaKZNEFjXF8YJWl
NoLtmf48xJv9QyepbZ4hLqBlIMf//NdNc8lDyXc/iRRV
) ; ZSK; alg = RSASHA256; key id = 30795
networktest.com.3600 IN DNSKEY 257 3 8 (
AwEAAceMN3Aad/ups4QFO2JmO7cww1kx5DBQwbouQ/iC
H5M+zAfo7XddkJZkVp5A9ZKhSqf982r0En3i1lQrNESE
1ZlWPnDwW8ygBySBORkmNPqLRZG28sBaut2B6n31laWi
1mj1m6U9NNrAiQG2M19IRlaTCcO6Ud7usMyhPogKcE/3
5TjuoMv5nzI/hirzOWhOi4F9gRe8UlsVk8q1gWoWDlL5
oGAIT3VguW3Ifaa9Ywy2BWTy0qSJ6IlMuLtqT+GbJrc+
qvG9/symJYbcwAKz2Ai0Yuiwhmi6E587wsLV/HZkryMR
3GMU/6Nt0H4dyhlwCaK4y9StedVmJwHIwI0HSDE=
) ; KSK; alg = RSASHA256; key id = 20362

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Oct 08 15:58:15 PDT 2013
;; MSG SIZE  rcvd: 892



> 
> AlanC
> 
___
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: inactivating and deleting DNSSEC keys

[David Newman]

On 10/8/13 5:54 PM, Mark Andrews wrote:
> In message <52548a5d.3070...@networktest.com>, David Newman writes:
>> bind 9.9.4
>>
>> How to troubleshoot issues when keys are supposed to be invalidated or
>> deleted on specific dates, but aren't?
>>
>> In this case, a KSK was supposed to be inactivated on 29 September 2013
>> and deleted on 9 October 2013.
>>
>> >From the .key file:
>>
>> ; This is a key-signing key, keyid 56989, for networktest.com.
>> ; Created: 20130723214837 (Tue Jul 23 14:48:37 2013)
>> ; Publish: 20130723214837 (Tue Jul 23 14:48:37 2013)
>> ; Activate: 20130723214837 (Tue Jul 23 14:48:37 2013)
>> ; Inactive: 20130929201510 (Sun Sep 29 13:15:10 2013)
>> ; Delete: 20131009201510 (Wed Oct  9 13:15:10 2013)
>>
>> Problem is, dig says the key is still active, and will be until 29
>> October 2013:
> 
> Named stopped SIGNING with this record on October 29.

Since this is in the future, I think you mean "will stop signing"?

> Inception (20130929181450) is over a hour (clock skew allowance)
> before the Inactivation (20130929201510) time.

OK, do I understand correctly that because the RRSIG got created just
before the inactivate date, it will live on for sig-validity-interval
(30 days in this case), regardless of the key's deletion date?

> 
> The RRSIG will be replaced when the record is due to be re-signed
> which is based on the sig-validity-interval.
> 
> I would be extending the deletion date to 30 days (sig-validity-interval)
> after the inactivation date.

Right, understood.

In UTC terms, we've already passed the key's deletion date. Can I
retroactively extend the key's deletion date?

Thanks

dn

> 
> Mark
> 
>> $ dig networktest.com @localhost +multi rrsig | grep 56989
>>  
>> 20131029191450 20130929181450 56989 networktest.com.
>>
>> named.conf has this:
>>
>> options {
>> ..
>>  // DNSSEC stuff
>> managed-keys-directory "managed-keys";
>> dnssec-enable yes;
>> dnssec-validation auto;
>> }
>>
>> ..
>>
>> zone "networktest.com" {
>> type master;
>>  ..
>> key-directory "managed-keys/networktest.com";
>> inline-signing yes;
>> auto-dnssec maintain;
>> };
>>
>> $ ls -l managed-keys/networktest.com/ | grep 56989
>> -rw-r-  1 bind  bind   719 Jul 31 13:15 Knetworktest.com.+008+56989.key
>> -rw---  1 bind  bind  1824 Jul 31 13:15
>> Knetworktest.com.+008+56989.private
>>
>> I don't understand the disconnect between the configured inactive/delete
>> times and the ones returned by dig, and presume this is because I've
>> misconfigured something.
>>
>> Thanks in advance for troubleshooting clues.
>>
>> dn
>>
>> ___
>> 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: inactivating and deleting DNSSEC keys

[David Newman]

On 10/9/13 1:24 PM, Mark Andrews wrote:

>> In UTC terms, we've already passed the key's deletion date. Can I
>> retroactively extend the key's deletion date?
> 
> Yes.  The files are not removed.  You will need to tell named to re-read
> the .private file using "rndc signzone" after setting the time the deletion
> time.

Thanks, Mark. The signzone command didn't work, but "rndc sign "
worked fine.

dn

___
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: Install DNS Server

[David Newman]

On 10/10/13 4:26 AM, Lightner, Jeff wrote:

> CentOS does put
> bug and security fixes in (or RedHat does and CentOS gets them because
> they build from RHEL source) but you still end up with something very
> old (BIND 9.3.x) that most folks on this list don’t want to talk about
> because it is long past EOL for BIND.

Another incentive is that when you enable DNSSEC (and I hope you will,
but not until you first get DNS itself working), you'll need a current
version of bind to take advantage of its key management features.

dn

___
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: Need guidance on configuring DNSSEC

[David Newman]

On 10/11/13 7:32 AM, Vishal Gandhi wrote:

> We are planning to sign local zone (fdu.local).  Is it required to sign
> the parent zone (fdu.edu ) as well or we can live with
> it unsigned?
> What are pros and cons of signing parent zone (fdu.edu )?

DNSSEC is based on a chain of trust, where a subdomain is trusted only
if the parent domain vouches for it. So, "." validates "edu" and so on.

It is possible to create an "island of trust" for a local zone. This
works OK, but only if there's never a requirement for nonlocal traffic
to verify DNSSEC signatures.

The major advantage of signing the parent zone is that Internet-facing
hosts (and those NAT'd or proxied to face the Internet) won't be
vulnerable to most hijacking and spoofing attacks we have with DNS
today. There are also some neat DNSSEC tricks possible, such as
distributing SSH keys and even self-signed certs once a chain of trust
is established.

The downsides are (1) DNSSEC is still a little involved to configure and
manage and (2) a configuration mistake can make your zone disappear from
the global Internet.

On point 1, you'll probably want to upgrade to Bind 9.9 for better
automatic key management. You'll also need to verify that your network
is DNSSEC-ready, and that your registrar supports loading of DS keys.
For the former, there's a good check here:

https://www.dns-oarc.net/oarc/services/replysizetest

On point 2, of course it's also possible to screw up a regular DNS
configuration. DNSSEC just gives you more opportunities. . .

If you haven't got it already, I'd strongly recommend "DNSSEC Mastery"
by Michael W. Lucas. It's very readable and covers both regular and
islands-of-trust configuration with Bind 9.9.

dn


> 
> We've found information on signing zones on AD at least.  Can some one
> provide us steps to enable and configure DNSSEC for our domains.
> 
> Thanks in advance.
> OIRT Signature
> fdu logo  
> Vishal K. Gandhi
> Systems Analyst/E-Mail Specialist
> University Systems and Security
> *1000 River Road, Teaneck NJ 07666*
> Mail Stop: T-BH1-01
> phone: 201-692-2414 | fax: 201-692-2494 | email: vgan...@fdu.edu
> 
> "Fairleigh Dickinson University will never
>  ask for your password. Please do not
> share it with others!"
> 
> 
> 
> 
> ___
> 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: moving DNSSEC to a hidden master

[David Newman]

On 10/4/13 10:23 AM, David Newman wrote:
> On 10/3/13 5:27 PM, Sten Carlsen wrote:
>> This works for me and is the standard method:
>>
>> rndc freeze
>> update serial
>> rndc thaw
> 
> Bingo. Thanks!

Sorry, spoke too soon. I followed your instructions and Mark's but I'm
not seeing the zone file serial number increment on the new machine,
even after making other edits to the zone file.

Here are the steps I'm following. Both old and new nameservers run bind
9.9.4.

1. "copy the .key and .private files over" - did this with rsync -prv
and verified ownerships and permissions are unchanged

2. "Disable updating on the old master" - did this with 'rndc freeze'

3. "Transfer the zone contents by setting up as a slave using
"masterfile-format text"; or using by using dig."

- did this with 'dig axfr zone +multi +onesoa @oldmaster > zonefile',
then edited zone file to remove top and bottom lines from dig, then
changed file ownership to the named owner.

Then I edited named.conf to make the new nameserver master for this zone.

Then I ran 'rndc reload' on the new nameserver. A 'dig soa' query
returns the same serial as on the old master.

4. "Check that the new server is working and you can update
the zone by using nsupdate."

This is where things fall apart. I run 'rndc freeze' and increment the
zone file's serial number (or make any other change), and then run 'rndc
thaw' and 'rndc reload'.

There's no change in serial number, and there's no error reported in the
logs.

What am I missing?

Thanks!

dn

> 
> dn
> 
>>
>> Rndc freeze merges the .jnl files into the zone files and stops dynamic
>> updates. Thaw allows dynamic updates to resume.
>>
>> On 04/10/13 02.12, David Newman wrote:
>>> Thanks all for your responses.
>>>
>>> On 10/1/13 6:42 PM, Mark Andrews wrote:
>>>> As Alan said copy the .key and .private files over.
>>>>
>>>> Disable updating on the old master.
>>>>
>>>> Transfer the zone contents by setting up as a slave
>>>> using "masterfile-format text"; or using by using dig.
>>>> This will give you the most up to date version of the
>>>> zone.
>>>>
>>>>dig axfr zone +onesoa @oldmaster
>>>>
>>>> Check that the new server is working 
>>> Converting the new secondary to a new master worked. But incrementing
>>> the zone's serial number did not, producing an error after 'rndc reload'
>>> like this:
>>>
>>> Oct  3 16:00:29 host named[35249]: malformed transaction:
>>> dynamic/mydomain.com/mydomain.com.db.jnl last serial 2013092701 !=
>>> transaction first serial 2013092700
>>>
>>>> and you can update
>>>> the zone by using nsupdate.
>>> Although the zone file lives under dynamic/mydomain.com so DNSSEC
>>> updates can happen, I don't have dynamic updates configured, so nsupdate
>>> won't work. This arrangement -- with static zone files under the dynamic
>>> directory -- worked OK on the old master. Permissions are the same on both.
>>>
>>> This thread suggested the journal issue was separate views pointing to
>>> the same zone file:
>>>
>>> https://lists.isc.org/pipermail/bind-users/2008-June/070807.html
>>>
>>> Indeed I had pointers to the same zone file in separate views, but
>>> removing them and restarting named did not clear the issue. Now I have
>>> the zone in just one view, and still can't manually increment the serial
>>> number without that journal complaint.
>>>
>>> Thanks in advance for clues on resolving the journal version issue.
>>>
>>> dn
>>>
>>>> Convert the old master server into a slave.
>>>>
>>>> Update the other slaves to talk to a new master.
>>>>
>>> ___
>>> 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
>>
>> -- 
>> Best regards
>>
>> Sten Carlsen
>>
>> No improvements come from shouting:
>>
>>"MALE BOVINE MANURE!!!" 
>>
> 
> ___
> 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: moving DNSSEC to a hidden master

[David Newman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/13/13 1:34 AM, Alan Clegg wrote:
> 
> On Oct 12, 2013, at 7:59 PM, Alan Clegg  wrote:
> 
>> 
>> On Oct 11, 2013, at 10:54 PM, David Newman
>>  wrote:
>> 
>>> 4. "Check that the new server is working and you can update the
>>> zone by using nsupdate."
>>> 
>>> This is where things fall apart. I run 'rndc freeze' and
>>> increment the zone file's serial number (or make any other
>>> change), and then run 'rndc thaw' and 'rndc reload'.
>>> 
>>> There's no change in serial number, and there's no error
>>> reported in the logs.
>>> 
>>> What am I missing?
>> 
>> What log messages are you getting from named?

Sorry for not posting these earlier. Here's the log entry, with the
zone name redacted:

('rndc reload' after initial axfr and then becoming master)

Oct 13 11:50:27 uci named[62826]: using built-in root key for view
external-in
Oct 13 11:50:27 uci named[62826]: the working directory is not writable
Oct 13 11:50:27 uci named[62826]: zone example.org/IN/external-in
(signed): receive_secure_serial: unchanged
Oct 13 11:50:28 uci named[62826]: all zones loaded
Oct 13 11:50:28 uci named[62826]: running

('rndc reload' after incrementing serial number in zone file)

Oct 13 11:51:22 uci named[62826]: using built-in root key for view
internal-in
Oct 13 11:51:22 uci named[62826]: using built-in root key for view
external-in
Oct 13 11:51:22 uci named[62826]: the working directory is not writable
Oct 13 11:51:22 uci named[62826]: all zones loaded
Oct 13 11:51:23 uci named[62826]: running


> What is the "zone" entry in your named.conf that relates to the
> zone in question?

Here are the logging, options, and zone parts of named.conf:

options {
// All file and path names are relative to the chroot directory,
// if any, and should be fully qualified.
directory   "/etc/namedb";
pid-file"/var/run/named/pid";
dump-file   "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
transfer-format many-answers;
max-transfer-time-in 60;
masterfile-format text;
allow-query { trusted; };
allow-query-cache { trusted; };
allow-transfer { external-xfer; internal-xfer; };
version none;
// DNSSEC stuff
dnssec-enable yes;
managed-keys-directory "managed-keys";
dnssec-validation auto;

..

};

logging {

channel "default_syslog" {
// Send most of the named messages to syslog.
syslog local2;
severity debug 1;
};

channel audit_log {
// Send the security related messages to a separate file.
file "/var/log/named.log" versions 7 size 1m;
severity debug 1;
print-time yes;
};

category default { default_syslog; };
category general { default_syslog; };
category security { audit_log; default_syslog; };
category config { default_syslog; };
category resolver { audit_log; };
category xfer-in { audit_log; };
category xfer-out { audit_log; };
category notify { audit_log; };
category client { audit_log; };
category network { audit_log; };
category update { audit_log; };
category queries { audit_log; };
category lame-servers { audit_log; };

};

view "external" in {

..

zone "example.com" in {
type master;
file "dynamic/example.org/example.org.db";
allow-query { any; };
allow-transfer { external-xfer; };
notify yes;
key-directory "managed-keys/example.org";
inline-signing yes;
auto-dnssec maintain;
};

};



>> 
>> I would strongly recommend forgetting all about "freeze the zone
>> and edit" as a method of updating... move completely to dynamic
>> zones if at all possible.

I've been resisting this, mostly because I have a lot of static zones
and I'm lazy. I know ISC has been moving toward dynamic zones, but are
they really required to run DNSSEC?

> 
> And yes, I noticed that you say there are no errors in the logs...
> there may be no "errors", but if BIND isn't logging anything, I'm
> extremely curious as to what your logging stanza has in it.
> 
> If it's not logging, turn some on (or up) so that we can help you
> figure out the problem.  In worst case, strip out any keying
&

Re: moving DNSSEC to a hidden master [SOLVED]

[David Newman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Alan,

Thanks very much for your responses. Per my comments inline below,
this actually wasn't broken to begin with, but I just wasn't seeing it.

On 10/14/13 10:43 AM, Alan Clegg wrote:
> 
> On Oct 13, 2013, at 9:03 PM, David Newman 
> wrote:
> 
>>>>> This is where things fall apart. I run 'rndc freeze' and 
>>>>> increment the zone file's serial number (or make any other 
>>>>> change), and then run 'rndc thaw' and 'rndc reload'.
> 
> So, I'm going to jump back a bit here If the configuration that
> you posted is what is actually running, you should get the
> following when you try to "rndc freeze":

When I said I used 'rndc freeze' and 'rndc reload', those really were
the commands I used. I did not use 'rndc  '
specifically because this is a static zone, and as you note that
doesn't work.

In case you couldn't tell by now, I don't use dynamic zones. If the
freeze/thaw commands are superfluous here, please let me know.

My (admittedly limited) understanding is that DNSSEC inline signing
copies the contents of the static zone into a dynamic zone and then
serves that, leaving the static zone unchanged.

It sounds as though you're saying I don't need the freeze/thaw
commands with static zones. Yes?

> 
> root@server00:/etc/namedb# rndc freeze example.com rndc: 'freeze'
> failed: not dynamic root@server00:/etc/namedb#
> 
> With the associated logging:
> 
> 14-Oct-2013 17:36:00.310 received control channel command 'freeze
> example.com'
> 
> You have views... is the definition of the internal one different
> from the external one (which you posted)?

Nope, this zone appears only in the external view.

> 
> So, I re-created your zone with the following zone entry:
> 
> zone "example.com" in { type master; file "master/example.com"; 
> allow-query { any; }; allow-transfer { any; }; notify yes; 
> key-directory "keys/"; inline-signing yes; auto-dnssec maintain; 
> };
> 
> This zone isn't dynamic based on what you have posted.

Yes, that's right.

> 
> It also works fine when I make changes (no "freeze"/"thaw"
> needed):
> 
> == Commands typed == root@server00:/etc/namedb# ls bind.keys  keys
> master  named.conf  rndc.key root@server00:/etc/namedb# cd master 
> root@server00:/etc/namedb/master# ls example.com  example.com.jbk
> example.com.signed  example.com.signed.jnl 
> root@server00:/etc/namedb/master# vi example.com 
> root@server00:/etc/namedb/master# rndc reload example.com zone
> reload queued root@server00:/etc/namedb/master#


Same here, except that file locations and permissions differ a bit on
FreeBSD (e.g., DNSSEC-signed zones MUST reside in a directory owned by
bind, so not 'master' because root owns that).

> == Logging produced == 14-Oct-2013 17:39:26.565 received control
> channel command 'reload example.com' 14-Oct-2013 17:39:26.571 zone
> example.com/IN (unsigned): loaded serial 2 14-Oct-2013 17:39:26.571
> zone example.com/IN (signed): serial 4 (unsigned 2)
> 
> And for those of you that have taken the DNS and BIND class, yes,
> I'm really using the very same lab environment that you used in
> class to test things... it works!

This is the crux of the problem: I was watching serial changes from
dig, not from the Bind logs.

In this case, I started with a serial of 2013092700, incremented it to
2013092701, and reloaded. 'dig soa' would still return 2013092700.

Problem is, bind logged the current serial number as 2013092705.
Guessing here, but it looks as though my change wouldn't be seen by
dig or any other external tool because internally, Bind was already on
a larger serial number.

As soon as I advanced the serial to something ahead of the one in the
logs, everything worked again.

This is probably another thing for dynamic zone fans to snicker at us
static zone users about. But as long as the static zone file's serial
number is greater than or equal to the internal serial number (modulo
a counter wrap), this appears to work OK.

Thanks again for the pointers. Much appreciated.

dn


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJcQhAACgkQyPxGVjntI4LWBgCg4z9M6munwjcag6TtPJuk1ey7
5B8An1z+TkRuSLAUpKyUrWmKU/T7/dvl
=3lB+
-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: moving DNSSEC to a hidden master [SOLVED]

[David Newman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/14/13 12:39 PM, Alan Clegg wrote:

>> In this case, I started with a serial of 2013092700, incremented
>> it to 2013092701, and reloaded. 'dig soa' would still return
>> 2013092700.
>> 
>> Problem is, bind logged the current serial number as 2013092705. 
>> Guessing here, but it looks as though my change wouldn't be seen
>> by dig or any other external tool because internally, Bind was
>> already on a larger serial number.
>> 
>> As soon as I advanced the serial to something ahead of the one in
>> the logs, everything worked again.
> 
> So, you were able to see the  and  entries in
> the log file?

I see only the signed entry, e.g.:

14-Oct-2013 12:36:30.584 zone example.com/IN/external-in (signed):
sending notifies (serial 2013092706)

I do not have something for just the .

> 
>> This is probably another thing for dynamic zone fans to snicker
>> at us static zone users about. But as long as the static zone
>> file's serial number is greater than or equal to the internal
>> serial number (modulo a counter wrap), this appears to work OK.
> 
> You shouldn't need to keep track of the "signed" vs. "unsigned"
> serial numbers.  Inline signing is supposed to be completely (and I
> mean 100%) transparent to the process that you had in place prior
> to signing.
> 
> Now that you have (what I'll call)
> "synchronized-but-out-of-sync-due-to-inline-signing" serial numbers
> (the signed one should be a bit higher than the unsigned one but
> you'll only see that from the log messages; dig should ALWAYS
> produce the higher number), can you try incrementing the serial on
> your static/unsigned zone by one, reloading the zone and seeing
> what the logging produces?  It _should_ increment the signed
> version (otherwise your slaves will never update), when you reload
> the zone (as the SOA is resigned).   [wow, that's a horrible
> paragraph, but I think it makes sense]

Yes. When I increment by one and reload, I see the signed entry
increment in the logs. I see the same serial from dig queries to slave
servers (this is a hidden master).

> 
> Also note that the inline-signed zone (in memory and dumped out to
> zone.signed file) will continue to increment serial numbers even
> without you making changes to the static/unsigned zone because of
> internal re-signing caused by signature expiration.

That's interesting. If I understand correctly, you're saying I should
focus on the zone serial number, same as I always have with static
zones, and pay no attention to the internal signed serial numbers.

dn

> 
>> Thanks again for the pointers. Much appreciated.
> 
> No problem, AlanC
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJcTJwACgkQyPxGVjntI4IIiQCfR0CYrv1j6v4jqASIIIizpXZt
dlMAoNF8Yl4NDdgyWTxIhP1CPz7J4VnH
=LPfe
-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

DNSSEC and split DNS

[David Newman]

What is the recommended practice for adding DNSSEC to an environment
that currently uses split DNS?

Apologies as I'm sure this has come up before, but most discussion I
found on bind-users was from 1999, and this isn't covered in the ARM.

I did find this draft (not RFC) from 2007, but even the author
acknowledges that some examples given can invite misconfiguration:

http://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view-04

On the surface, split DNS and DNSSEC have seemingly opposite goals: One
seeks to provide different responses to queries for the same resource,
and the other seeks to prevent it.

Is there some way of reconciling these?

Thanks

dn

___
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 and split DNS

[David Newman]

On 10/23/13 4:28 PM, Mark Andrews wrote:
>   You sign all versions of the zone.
> 
>   As for key management you can:
> 
>   * use the same keys in all views which makes mobile device
> management simpler as there is no need to distribute keys.
> Validating from the root will work in all cases though
> there is still something to be said for distributing keys
> for local zones locally as this prevents resolution
> failures when the site is disconnected from the rest of
> the world.
> 
>   * different keys per view.  You will need to distribute the
> keys and for mobile devices they will need all sets of
> keys as they see both the internal and external views
> depending apon where they attach to the network and whether
> there is a VPN active.  For fixed devices different keys
> will cause data leakage to be rejected as the leaked data
> won't validate.
> 
>   You can change strategy if you pick the wrong one.

Thanks, makes sense.

What about delegation? Right now, there is none between external zones
and internal forward zones using RFC 1918 addresses.

I *think* option 1 would require, for example, example.org's zone to
include delegation and glue records for internal.example.org to keep the
chain of trust intact.

And I *think* option 2 in theory could be set up as an island of trust,
with no delegation from parent domains.

True?

Thanks again

dn

> 
>   Mark
> 
> In message <526857a2.8050...@networktest.com>, David Newman writes:
>> What is the recommended practice for adding DNSSEC to an environment
>> that currently uses split DNS?
>>
>> Apologies as I'm sure this has come up before, but most discussion I
>> found on bind-users was from 1999, and this isn't covered in the ARM.
>>
>> I did find this draft (not RFC) from 2007, but even the author
>> acknowledges that some examples given can invite misconfiguration:
>>
>> http://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view-04
>>
>> On the surface, split DNS and DNSSEC have seemingly opposite goals: One
>> seeks to provide different responses to queries for the same resource,
>> and the other seeks to prevent it.
>>
>> Is there some way of reconciling these?
>>
>> Thanks
>>
>> dn
>>
>> ___
>> 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 and split DNS

[David Newman]

On 10/23/13 5:20 PM, Mark Andrews wrote:
> In message <5268626c.8040...@networktest.com>, David Newman writes:
>> On 10/23/13 4:28 PM, Mark Andrews wrote:
>>> You sign all versions of the zone.
>>>
>>> As for key management you can:
>>>
>>> * use the same keys in all views which makes mobile device
>>>   management simpler as there is no need to distribute keys.
>>>   Validating from the root will work in all cases though
>>>   there is still something to be said for distributing keys
>>>   for local zones locally as this prevents resolution
>>>   failures when the site is disconnected from the rest of
>>>   the world.
>>>
>>> * different keys per view.  You will need to distribute the
>>>   keys and for mobile devices they will need all sets of
>>>   keys as they see both the internal and external views
>>>   depending apon where they attach to the network and whether
>>>   there is a VPN active.  For fixed devices different keys
>>>   will cause data leakage to be rejected as the leaked data
>>>   won't validate.
>>>
>>> You can change strategy if you pick the wrong one.
>>
>> Thanks, makes sense.
>>
>> What about delegation? Right now, there is none between external zones
>> and internal forward zones using RFC 1918 addresses.
>>
>> I *think* option 1 would require, for example, example.org's zone to
>> include delegation and glue records for internal.example.org to keep the
>> chain of trust intact.
>>
>> And I *think* option 2 in theory could be set up as an island of trust,
>> with no delegation from parent domains.
> 
> You can
> * add the delegation for internal.example.org to example.org
>   and make it visible to the world with a appropriate acl on
>   internal.example.org.
> * have two version of example.org, one with and one without the
>   delegation for internal.example.org.

I went this route, and encountered three issues:

1. After a reload, there are out-of-zone warnings for hosts in example.org:

25-Oct-2013 16:02:49.330 general: warning:
dynamic/example.org/example.org.db:133: ignoring out-of-zone data
(hostname.example.org)

Both internal and external zones are called 'example.org' but each is in
a separate view. These warnings come from the example.org zone file, the
one in the external view.

2. With two zones using the same name, I'm unsure how to use rndc to
reload just the internal or just the external version since both use the
same name.

3. Another internal nameserver gets intermittent dig +dnssec errors on
queries for internal resources. Sometimes after a restart, the result is
NOERROR and other times it's NXDOMAIN or SERVFAIL.

This is seen on an internal recursive nameserver (let's call it NS2). I
think this might be due to the presence of external servers in the
forwarding statement. If I comment out the external forwarders and
include only one other internal server (let's call it NS1), dig lookups
always work, including DNSSEC.

Problem is, NS1 is currently an authoritative and recursive server, and
I'm trying to separate these functions. Is there some other way to build
up a cache and get DNSSEC data on NS2?

Config details below. Thanks very much for additional troubleshooting clues.

dn

This is from named.conf:

acl internal-xfer {
..
}

acl external-xfer {
..
}

acl trusted {
..
}

view "internal" in {

match-clients { trusted; };
recursion yes;
additional-from-auth yes;
additional-from-cache yes;

..

   zone "example.org" in {
type master;
file "dynamic/split.example.org/split.example.org.db";
allow-query { trusted; };
allow-transfer { internal-xfer; };
// internal and external zones use same key
key-directory "managed-keys/example.org";
inline-signing yes;
auto-dnssec maintain;
};

..

};

view "external" in {

match-clients { any; };
recursion no;
additional-from-auth no;
additional-from-cache no;

..

zone "example.org" in {
type master;
file "dynamic/example.org/example.org.db";
allow-query { any; };
allow-transfer { external-xfer; };
// internal and external zones use same key
key-directory "managed-keys/example.org";
inline-signing yes;
auto-dnssec maintain;
};

..
};


Here is the internal split.example.

Re: DNSSEC and split DNS

[David Newman]

On 10/25/13 6:11 PM, David Newman wrote:
> 
> 
> On 10/23/13 5:20 PM, Mark Andrews wrote:
>> In message <5268626c.8040...@networktest.com>, David Newman writes:
>>> On 10/23/13 4:28 PM, Mark Andrews wrote:
>>>>You sign all versions of the zone.
>>>>
>>>>As for key management you can:
>>>>
>>>>* use the same keys in all views which makes mobile device
>>>>  management simpler as there is no need to distribute keys.
>>>>  Validating from the root will work in all cases though
>>>>  there is still something to be said for distributing keys
>>>>  for local zones locally as this prevents resolution
>>>>  failures when the site is disconnected from the rest of
>>>>  the world.
>>>>
>>>>* different keys per view.  You will need to distribute the
>>>>  keys and for mobile devices they will need all sets of
>>>>  keys as they see both the internal and external views
>>>>  depending apon where they attach to the network and whether
>>>>  there is a VPN active.  For fixed devices different keys
>>>>  will cause data leakage to be rejected as the leaked data
>>>>  won't validate.
>>>>
>>>>You can change strategy if you pick the wrong one.
>>>
>>> Thanks, makes sense.
>>>
>>> What about delegation? Right now, there is none between external zones
>>> and internal forward zones using RFC 1918 addresses.
>>>
>>> I *think* option 1 would require, for example, example.org's zone to
>>> include delegation and glue records for internal.example.org to keep the
>>> chain of trust intact.
>>>
>>> And I *think* option 2 in theory could be set up as an island of trust,
>>> with no delegation from parent domains.
>>
>> You can
>> * add the delegation for internal.example.org to example.org
>>   and make it visible to the world with a appropriate acl on
>>   internal.example.org.
>> * have two version of example.org, one with and one without the
>>   delegation for internal.example.org.
> 
> I went this route, and encountered three issues:

Answering two of my own questions. The final one remains unresolved.

> 
> 1. After a reload, there are out-of-zone warnings for hosts in example.org:
> 
> 25-Oct-2013 16:02:49.330 general: warning:
> dynamic/example.org/example.org.db:133: ignoring out-of-zone data
> (hostname.example.org)
> 
> Both internal and external zones are called 'example.org' but each is in
> a separate view. These warnings come from the example.org zone file, the
> one in the external view.

Root cause: An $INCLUDE statement in a zone file in the internal view
called a file with a typo in its name. That zone wasn't loading as a result.


> 2. With two zones using the same name, I'm unsure how to use rndc to
> reload just the internal or just the external version since both use the
> same name.

rndc reload zone IN view

> 
> 3. Another internal nameserver gets intermittent dig +dnssec errors on
> queries for internal resources. Sometimes after a restart, the result is
> NOERROR and other times it's NXDOMAIN or SERVFAIL.
> 
> This is seen on an internal recursive nameserver (let's call it NS2). I
> think this might be due to the presence of external servers in the
> forwarding statement. If I comment out the external forwarders and
> include only one other internal server (let's call it NS1), dig lookups
> always work, including DNSSEC.
> 
> Problem is, NS1 is currently an authoritative and recursive server, and
> I'm trying to separate these functions. Is there some other way to build
> up a cache and get DNSSEC data on NS2?

Still stuck on this one. Authoritative and recursive servers should be
separate (this is to allow trust anchors on internal zones).

If delegation only happens for a zone in the internal view, how would an
internal caching-only server build up a cache of both internal and
external responses? What should it use as forwarders?

Thanks

dn



> 
> Config details below. Thanks very much for additional troubleshooting clues.
> 
> dn
> 
> This is from named.conf:
> 
> acl internal-xfer {
> ..
> }
> 
> acl external-xfer {
> ..
> }
> 
> acl trusted {
>   ..
> }
> 
> view "internal" in {
> 
> match-clients { trusted; };
> recursion yes;
> additional-from-auth yes;
> additional-from-cache yes;
> 
> ..
> 
>zone "example.o

Re: DNSSEC and split DNS

[David Newman]

On 10/28/13 1:46 PM, Mark Andrews wrote:
> In message <526eba87.7040...@networktest.com>, David Newman writes:
>>
>>> 3. Another internal nameserver gets intermittent dig +dnssec errors on
>>> queries for internal resources. Sometimes after a restart, the result is
>>> NOERROR and other times it's NXDOMAIN or SERVFAIL.
> 
> Inconsistant use of views.  The NOERROR will probably be coming
> from a the internal view and the NXDOMAIN from the external view
> (or the other way around).

The underlying question is what forwarders to use, if any, on an
internal caching-only nameserver where DNSSEC and split DNS are in use.

In this case, per your guidance there are two versions of some zones,
with the internal version using delegation and the external not.

The only way I can think of is to allow recursion on authoritative
servers, but only from the caching-only servers, and put the
authoritative servers in their forwarders statement.

For all other clients, the only servers with recursion would be the
caching-only ones. And the authoritative servers would be the only ones
listed in the forwarders statement.

Or is there a better way to do this?

thanks

dn


> 
> As for SERVFAIL you may have badly configured firewalls that are
> dropping fragmented responses, or responses > 512 bytes resulting
> in excessive timeouts and excessive use of TCP.  This is more visible
> in a newly started server.
> 
> 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

Re: Help on DNSSEC

[David Newman]

On 11/6/13 1:06 AM, Steven Carr wrote:
> Start with chapter 11.4 "The DNS Security Extensions" in DNS & BIND
> http://www.amazon.com/DNS-BIND-5th-Edition-Cricket/dp/0596100574

Lucas' "DNSSEC Mastery" is also a useful resource, not only about DNSSEC
concepts but also about required prep work and troubleshooting:

http://www.amazon.com/DNSSEC-Mastery-Securing-Domain-System-ebook/dp/B00CE173KI

dn


> 
> Steve
> 
> On 6 November 2013 08:54, babu dheen  wrote:
>> Dear All,
>>
>>  I would like to understand DNSSEC on BIND Recusive DNS server running in
>> RHEL 5.0. Can you please let me know resource or reference to understand the
>> DNSSEC and implement it?
>>
>> Regards
>> Babu
>>
>>
>> ___
>> 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: Does anyone have DNSSEC problem with uscg.mil

[David Newman]

On 11/14/13 1:29 PM, Kevin Oberman wrote:

> Don't forget that Google will white-list domains with known (by them)
> broken DNSSEC and reply even though validation is broken, so using
> 8.8.8.8 for checking on whether validation is broken is not the best idea.

Really? Google sets the ad flag for known non-authenticated data?

Or are you saying Google will respond to any +dnssec query but without
the ad flag if that domain's configuration is broken? Or something else?

Thanks

dn

___
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

DNSSEC and upgrading/restoring

[David Newman]

Are there any recommended practices/config changes needed when upgrading
or restoring a bind 9.9.4 server using DNSSEC inline signing and auto
maintain?

Asking specifically about upgrading a server running on NanoBSD, but
this question is really about upgrading or restoring any DNSSEC server
with inline signing and auto maintain enabled.

Is this as easy as copying everything from /var/named to the NanoBSD
build machine and going from there? Or is something else required?

Thanks!

dn

___
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 and upgrading/restoring

[David Newman]

Asking again, in a different and more generic form: When rebuilding a
bind 9.9.4 server running DNSSEC with auto maintain, are there any steps
I need to take beyond just backing up /var/named/etc/namedb (this is on
FreeBSD) and restoring?

This server is authoritative and primary, and has slaves for multiple
domains.

I'm concerned about keeping keys, serial numbers, and any other dynamic
info in sync.

Thanks!

dn



On 1/23/14 10:16 AM, David Newman wrote:
> Are there any recommended practices/config changes needed when upgrading
> or restoring a bind 9.9.4 server using DNSSEC inline signing and auto
> maintain?
> 
> Asking specifically about upgrading a server running on NanoBSD, but
> this question is really about upgrading or restoring any DNSSEC server
> with inline signing and auto maintain enabled.
> 
> Is this as easy as copying everything from /var/named to the NanoBSD
> build machine and going from there? Or is something else required?
> 
> Thanks!
> 
> dn
> 
> ___
> 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 and upgrading/restoring

[David Newman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 1/28/14 3:49 AM, Alan Clegg wrote:
> 
> On Jan 27, 2014, at 7:32 PM, David Newman 
> wrote:
> 
>> Asking again, in a different and more generic form: When
>> rebuilding a bind 9.9.4 server running DNSSEC with auto maintain,
>> are there any steps I need to take beyond just backing up
>> /var/named/etc/namedb (this is on FreeBSD) and restoring?
>> 
>> This server is authoritative and primary, and has slaves for
>> multiple domains.
>> 
>> I'm concerned about keeping keys, serial numbers, and any other
>> dynamic info in sync.
> 
> Should be problem what-so-ever.
> 
> Just stop the old server, do the backup, restore it where your new
> system expects it then start the new one.  A brief outage of your
> master should be no issue is your slaves are working correctly.
> 
> Do make sure that the new version is built with the same options as
> the old one if you are replicating the file system locations of the
> data.  8-)

Thanks. This mostly worked fine.

The only gotchas:

1. On a NanoBSD box, named did not start because it couldn't write to
the old named.log file. Deleting the existing named.log cleared that
issue. I think this may be a NanoBSD-specific issue.

2. For five domains, the log contains signature-has-expired warnings.

In all five cases, these are for NSEC3PARAM records.

Is any action needed on my part, for example manually doing NSEC3
signing of these zones?

Thanks again!

dn


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJS6ucEAAoJEDoYs7vtFALacaEP/izW2EQ8rjff25TpCANlJ2Za
WSeZTRZLiWpatz1ErlKp6kOZqABpNgH764DfueRMGfPsqvthGCCt+1k0v4jzVMnr
SF3rpwH5Zue5RAkeHknyazvdrXd22psxN7J4pnqe83zMpfXY7JPdsmUKb/vIZeRY
n1x+eMDSgNPUKN5g5Is1FPaQH4X95otDiH3C79n05wNCTDTrKHZNcDTEbrPkW3SE
rNU1PBKkj1Q4g+xMcTjccUPUPzjBObhE///QZu5psfZutEAC8BUMIbNHvP5coszc
byUOBKCpini4/8gOlEC49m1tHU6H7t8dppqufMSzxA6gZEKshd03MVdCJg7D8+e/
aYAXh/uBIWtav3QRIxix3g6q7zF/hOh/FG30IYhufItTnaK8BdO9sufbBnLePmf2
NwDcLc/U7bbN/pxY/oc7TgMbjqnAAP9YUAMHmOFqiw/JnmQ1SMXYxI80hSBoKnRx
/gixPGW0qv146s4kJ0+phRl9/0igC97/S3Q0tk7erOXetw+CMHgfgBT9BCx2/I+A
9gEJ5Laqi2J6NT/QNl14WBJ/IF6a2umo47bBj0l4Orb3ivJkpsMo6k8vaytH6QDZ
t38d5RXRJ1vNbr9kRMuXQAoKwsxemPFkVL/o7MAPBu4Htv8DD3VTEYL7R3l2EkEx
K+9iLy/TKYMEPtNEetQ6
=NEkU
-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 and upgrading/restoring

[David Newman]

On 1/31/14 3:10 AM, Tony Finch wrote:

>> 2. For five domains, the log contains signature-has-expired warnings.
>>
>> In all five cases, these are for NSEC3PARAM records.
>>
>> Is any action needed on my part, for example manually doing NSEC3
>> signing of these zones?
> 
> See if named has already re-signed them - check that the first date in the
> RRSIG is in the future.

So far (~18 hours) named has not re-signed them. In all five cases the
first date in the RRSIG is in the past, from 2013.

What action, if any, is needed?

Thanks!

dn

___
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 and upgrading/restoring

[David Newman]

On 1/31/14 10:35 AM, Tony Finch wrote:
> David Newman  wrote:
>>
>> What action, if any, is needed?
> 
> Does rndc sign  make it wake up? 

Alas, no. There are a bunch of successful IXFR messages to slave servers
but the dates in that NSEC3PARAM RRSIG did not change.

> Is there anything in the logs
> reporting problems, e.g. inability to read the key files?

For these five zones, the only warnings are that the signature has expired.

The log has errors for other zones saying the serial number is
unchanged. Here's an example:

30-Jan-2014 15:25:46.490 general: error: zone
networktest.com/IN/internal (signed): receive_secure_serial: unchanged

But I think this is unrelated to the zones with stale NSEC3PARAM RRSIGs.

dn



___
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 and upgrading/restoring

[David Newman]

On 2/2/14 5:39 AM, Tony Finch wrote:
> David Newman  wrote:
>> On 1/31/14 10:35 AM, Tony Finch wrote:
>>> David Newman  wrote:
>>>>
>>>> What action, if any, is needed?
>>>
>>> Does rndc sign  make it wake up?
>>
>> Alas, no. There are a bunch of successful IXFR messages to slave servers
>> but the dates in that NSEC3PARAM RRSIG did not change.
> 
> Not good. I would try deleting and re-adding the NSEC3PARAM records.
> Slow if the zones are big but at least it should fix the problem.

Bingo. That cleared the issue.

This may have been unrelated to the system upgrade. It's possible the
stale NSEC3 records were there for a while, and I just hadn't noticed.

Thanks very much for the troubleshooting clues.

dn


___
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

changing NSEC3 salt

[David Newman]

The Michael W. Lucas DNSSEC book recommends changing NSEC3 salt every
time a zone's ZSK changes.

Is this just a matter of a new 'rndc signing' command, or is some action
needed to remove the old salt?

thanks

dn

___
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: changing NSEC3 salt

[David Newman]

On 2/11/14 7:38 AM, Chris Thompson wrote:
> On Feb 10 2014, Mark Andrews wrote:
> 
>> In message <52f94ee2.7080...@ksu.edu>, "Lawrence K. Chen, P.Eng." writes:
> [... snip ...]
>>> On 02/06/14 15:07, Timothe Litt wrote:
> [... snip ...]
>>> > Note also the RFC 5155 recommendation:
>>> >> The salt SHOULD be at least 64 bits long and unpredictable, so that
>>> >> an attacker cannot anticipate the value of the salt and compute the
>>> >> next set of dictionaries before the zone is published.
>>> > In case it wasn't obvious, I should have noted that the length
>>> would be
>>> > a config file entry.
> [...]
>>>
>>> InterestingI guess I need to keep up more on these things.
>>>
>>> I haven't changed my NSEC3 salt since I initially set up DNSSEC here,
>>> and seemed to me that the document I was working off of back then said 4
>>> hex characters.
>>>
>>> Which probably made it extra hard for me to come up with a random
>>> number.  So, its totally non-random...so all I did was take the hex for
>>> two (well-known) letters...for my salt.  Since the salt is 'public',
>>> I'll say it.  my salt is "KS", or "4b53".
>>>
>>> So now to think of how to add NSEC3 salt changing to my current
>>> automation scripts
>>
>> And for most zones it won't make a bit of difference.  Most are
>> mainly static and once you have sampled the zone enough times to
>> have (almost) all the NSEC3 records you just keep testing against
>> those NSEC3 records.  Once you find a name in the zone you can just
>> test that it still exists.  When the NSEC3 parameters change you
>> just run the know names through for a non-existing type and you
>> get confirmation of the name and a new set of NSEC3 records without
>> having to do as much sampling.
>>
>> It makes a bit of sense for zones that have names that a coming and
>> going all the time but even then you can reuse existing knowledge.
> 
> It's probably worth noticing what the big operators do, e.g.
> 
> $ dig +noall +answer +nottl NSEC3PARAM com. edu. net. org.
> com.IN  NSEC3PARAM 1 0 0 -
> edu.IN  NSEC3PARAM 1 0 0 -
> net.IN  NSEC3PARAM 1 0 0 -
> org.IN  NSEC3PARAM 1 0 1 D399EAAB
> 
> (AFAIK the salt used for "org" has never changed - and the same value
> is used for 23 other TLDs.) A quick check revealed 216 TLDs [*] with
> NSEC3PARAM records, distributed as follows:
> 
>   Extra Salt length (bytes)   Total
> iterations0234568   10   16
> 
> 0 7--------   7
> 1 ---  125--1-- 126
> 2 ---2----1   3
> 3 -3-1-----   4
> 5 1--15-   151-  23
> 8 -----2---   2
>10 245   25--1--  37
>12 ------51-   6
>13 --1------   1
>15 ---1-----   1
>17 ------1--   1
>25 ------2--   2
>   100 ------1--   1
>   150 ---1--1--   2
> 
>  Total   1076  15652   2721 216


That's interesting. It seems to contradict Lucas' advice to "always use
'1 0 10' for these [NSEC3] flags, as fewer aren't secure enough and more
aren't any more secure."

dn



> 
> 
> [*] A lot more than there used to be, due to the influx of new gTLDs.
> 
___
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

do not stupidly delete ZSK files

[David Newman]

I created then loaded then deleted a ZSK, all within an hour, so there's
no backup. Yes, that was a dumb thing to do.

Now when reloading that zone, named.log complains about the missing ZSK:

29-Jul-2015 17:18:19.439 general: warning:
dns_dnssec_keylistfromrdataset: error reading private key file
example.com/RSASHA256/36114: file not found

There are no ZSK files to revoke. Other than disabling DNSSEC for this
zone, how to remove that ZSK so the zone will load clean?

This is bind910-9.10.2P2_5 on 10.1-RELEASE-p16.

Thanks (and don't do as I did)

dn


___
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: do not stupidly delete ZSK files

[David Newman]

On 7/29/15 6:24 PM, Evan Hunt wrote:
> On Wed, Jul 29, 2015 at 05:56:20PM -0700, David Newman wrote:
>> 29-Jul-2015 17:18:19.439 general: warning:
>> dns_dnssec_keylistfromrdataset: error reading private key file
>> example.com/RSASHA256/36114: file not found
> 
> Delete that key from the DNSKEY rrset in the zone and reload.
> 
> If it's a dynamic zone, freeze it first, then edit the zone file,
> delete the key, increase the serial number, and thaw it.
> 
> If it's not dynamic, same instructions, but without the freezing
> and thawing.

Thanks very much.

It's a static zone. The zone file did not have the key in it.

I dumped the signed file like this:

named-compilezone -f raw -F text -o example.com.text example.com
example.com.db.signed

Then incremented the serial number and copied that over to the zone file
(after making a backup copy).

Same complaint in the log when reloading, though.

What else is required to get rid of this nonexistent key?

Thanks again

dn


in named.conf:

   zone "example.com" in {
type master;
file "dynamic/example.com/example.com.db";
allow-query { any; };
allow-transfer { external-xfer; };
notify yes;
key-directory "managed-keys/example.com";
inline-signing yes;
auto-dnssec maintain;
};
___
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: do not stupidly delete ZSK files

[David Newman]

On 7/30/15 9:06 AM, Evan Hunt wrote:
> On Wed, Jul 29, 2015 at 07:29:29PM -0700, David Newman wrote:
>> It's a static zone. The zone file did not have the key in it.
> 
> ... oh, it's inline-signing.

Sorry, I also didn't mention that this is a hidden primary server, which
may be relevant below...

> 
> Unfortunately, by its nature, inline-signing gives you less direct
> control over the signed side of the zone.
> 
> There are two ways you can go go:
> 
> First, since this appears to be an example zone, you could blow away the
> signed zone entirely: "rm -f example.com.db.signed.*". Start named over
> again and it'll recreate the signed zone from scratch, this time without
> the key in it.
> 
> Or second, if it's important to preserve the signed zone, then you can
> create new key files from the zone contents, then set the broken key to
> be deleted while other keys remain in place.
> 
> $ cd /tmp
> $ dig @localhost dnskey example.com | dnssec-importkey -f - example.com
> $ dnssec-settime -D now Kexample.com.+007+36114.key
> $ mv Kexample.com.+007+35114.* /path/to/key/directory
> $ rndc loadkeys example.com
> 
> "dnssec-importkey" creates a pair of key files containing the public key,
> but with the private key data omitted; named can't use it for signing
> data, but it can use it for determining what changes to make in the DNSKEY
> rrset.  "dnssec-settime" sets the timing metadata for the key so that named
> will delete it next time it reads the key file. "rndc loadkeys" tells
> it to read the file.
> 
> The key should be deleted from the zone now, and you can remove the
> key files safely.

Thanks for this.

After that second procedure (and also chown'ing the keyfiles to the bind
user), the command 'dig +dnssec +multi dnskey example.com' gives
different results depending on which nameserver gets the query:

Hidden primary (not authoritative for this zone): Key still in zone

Authoritative server for zone: Key not in zone

Google's recursive server: Key not in zone

Even after moving those 36114 key files into another directory and
rerunning 'rndc loadkeys example.com', the hidden primary still thinks
36114 is a valid key for this zone.

Is there some other step needed to remove it on the hidden primary?

Thanks again!

dn

___
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: do not stupidly delete ZSK files

[David Newman]

On 7/30/15 10:37 AM, Evan Hunt wrote:
> On Thu, Jul 30, 2015 at 10:30:33AM -0700, David Newman wrote:
>> After that second procedure (and also chown'ing the keyfiles to the bind
>> user), the command 'dig +dnssec +multi dnskey example.com' gives
>> different results depending on which nameserver gets the query:
>>
>> Hidden primary (not authoritative for this zone): Key still in zone
> 
> ... sorry, I'm confused. Which of the servers is doing the signing?

This hidden primary nameserver does the signing. The zones I've created
list only the secondary nameservers -- the ones that get zone transfers
from this hidden primary -- as authoritative.

Most zones have four authoritative nameservers, only one of which I
manage. Of the three I don't manage, I'm pretty sure at least two have
no DNSSEC-specific configuration -- a hint that any DNSSEC records they
serve come from this hidden primary.

Make sense? If not, please let me know what other info you need.

dn





___
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: do not stupidly delete ZSK files

[David Newman]

On 7/31/15 4:33 AM, Tony Finch wrote:
> David Newman  wrote:
>> On 7/30/15 10:37 AM, Evan Hunt wrote:
>>> On Thu, Jul 30, 2015 at 10:30:33AM -0700, David Newman wrote:
>>>>
>>>> Hidden primary (not authoritative for this zone): Key still in zone
> 
> I think what you mean here is that the hidden primary is not advertised in
> the zone's NS RRset. (Whether a server is authoritative for a zone or not
> depends on the server configuration, not the NS RRset.)
> 
>> Most zones have four authoritative nameservers, only one of which I
>> manage. Of the three I don't manage, I'm pretty sure at least two have
>> no DNSSEC-specific configuration -- a hint that any DNSSEC records they
>> serve come from this hidden primary.
> 
> The DNSSEC records come from the zone data like any other records. You
> don't need any special DNSSEC configuration to act as a secondary for a
> signed zone - it just works.
> 
> I don't have any particular suggestions for your problem other than
> checking zone serial numbers and transfer logs carefully.

Thanks. For reasons passing understanding, that "bad key" was gone
queries against the hidden primary after a few hours. This is running
the same dig query as before, and with no other config changes to the
server.

Unclear why the hidden primary ever returned that key after Evan's
instructions, but all is good now.

Thanks very much to everyone who responded.

dn

___
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

ZSKs sign some RRsets but not others

[David Newman]

A newly minted ZSK signs a domain's SOA but not its A or MX records.
What basic config step did I miss?

For the domain 'trikids123.com' I created and installed a new ZSK with a
key ID of 28053 using these commands:

dnssec-keygen -a 8 -b 1024 trikids123.com
chown bind:bind *   # this is bind910 on FreeBSD 10.1
chmod o-r *
rndc loadkeys trikids123.com

No complaints in the log. But then:

- 'dig +dnssec +multi soa trikids123.com' shows the RRset signed by the
new ZSK (28053).

- 'dig +dnssec +multi a trikids123.com' does not show the RRset signed
by the new ZSK (28053). Same with a query for the MX record.

The zone's definition in named.conf:

zone "trikids123.com" in {
type master;
file "dynamic/trikids123.com/trikids123.com.db";
allow-query { any; };
allow-transfer { external-xfer; };
notify yes;
key-directory "keys/trikids123.com";
inline-signing yes;
auto-dnssec maintain;
};

Thanks in advance for troubleshooting clues.

dn






___
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: intermittent failures and queries sent over TCP

[David Newman]

On 8/18/20 5:55 PM, Mark Andrews wrote:

> If you are getting RST responses check your firewall settings.  RST is often 
> forged
> when TCP is blocked.  The root servers normally accept TCP connections.
> 
> % dig +tcp gmail.com @a.root-servers.net +dnssec

Bingo. This query failed before adding a rule to the upstream firewall
to allow outbound queries, and works now.

Thanks!

dn

___
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

intermittent failures and queries sent over TCP

[David Newman via bind-users]

bind 9.11.5.P4 on Debian 10

Greetings. I recently had to migrate a nameserver from FreeBSD to
Debian. It works fine most of the time but I've noticed a few
intermittent resolution failures.

After "gmail.com" failed to resolve I took a packet capture using
tcpdump to listen to the result of the command "dig -t mx gmail.com" and
here's what I found:

1. That query over UDP, with responses over UDP pointing to Google's
nameservers

2. Nearly 200 attempts to reach root servers over TCP, followed
immediately by RST messages from the root servers.

Some time later, gmail.com started resolving succesfully again, clearing
up the issue for now.

AFAIK there's nothing in the BIND configs that would force the use of
TCP queries. I checked the docs for various TCP options and didn't see
any applied here. I don't know if the TCP queries are related to the
gmail.com resolution failure but I suspect they are (and in any event
inability to reach root servers is a problem).

This server is authoritative for several domains. It gets its zones from
a hidden primary. The system's firewall permits inbound TCP and UDP
traffic on port 53 and AFAIK does not block outbound UDP (the firewall
is nftables, which is new to me, but since I see UDP queries in the
packet capture I think it works).

What would cause the server to send queries over TCP?

Thanks in advance for troubleshooting clues.


dn



CONFIG FILES

(named.conf is just pointers to .local and .options and .default-zones)

// named.conf.local

acl "xfer" {
// redacted -- a list of IPv4 and IPv6 addresses I trust
};

controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; };
};

logging {
channel simple_log {
file "/var/log/named/named.log" versions 30 size 1m;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
category default { simple_log; };
category update { simple_log; };
category update-security { simple_log; };
category security { simple_log; };
category queries { simple_log; };
category lame-servers { null; };
};

zone  "example1.org" in {
type slave;
file "example1.org.bak";
masters { 198.18.0.53; }; // not the real address
allow-query { any; };
allow-transfer { xfer; };
};

zone  "example2.org" in {
type slave;
file "example2.org.bak";
masters { 198.18.0.53; }; // not the real address
allow-query { any; };
allow-transfer { xfer; };
};

// etc.


// named.conf.options

acl "trusted" {

// redacted -- a list of IPv4 and IPv6 addresses I trust
};

options {
directory "/var/cache/bind";
pid-file"/var/run/named/named.pid";
statistics-file "/var/run/named/named.stats";
transfer-format many-answers;
masterfile-format text;
max-transfer-time-in 60;
allow-query { any; };
allow-recursion { trusted; };
allow-query-cache { trusted; };
allow-transfer { xfer; };
version none;

disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
disable-empty-zone
"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
disable-empty-zone
"1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";


querylog yes;


};
___
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