RE: Slow zone signing with ECDSA

[Spain, Dr. Jeffry A.]

> Install and run haveged... The problem is your system doesn't have enough 
> entropy
This was clearly the problem. I built a new test server with haveged installed, 
and the bind9 completed ECDSAP256SHA256 signing in 5 seconds. I used 9.11.1 
this time since it was just released today.

___
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: Slow zone signing with ECDSA

[Spain, Dr. Jeffry A.]

> Install and run haveged... The problem is your system doesn't have enough 
> entropy in the processor or maybe it's a VM but either way there is not 
> enough entropy to produce random seeds which is why it is taking so long.

Thanks, David. The system is a Microsoft Azure VM. I assumed that while entropy 
is required for ECDSA key generation, which in any event I did on another 
system, additional entropy would not be required for the zone signing process 
itself. Jeff.
___
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

Slow zone signing with ECDSA

[Spain, Dr. Jeffry A.]

I'm testing a bind9 v11.1.0-P5 server signing 8 small zones de novo with 
ECDSAP256SHA256. The process takes about 12 hours to complete vs. signing with 
RSASHA256, which is almost immediate, but signing is ultimately successful. The 
server is running Ubuntu 16.04 LTS with current patches. I don't see any 
indication of resource starvation. I understand that ECDSAP256SHA256 is more 
computationally intensive than RSASHA256. Is bind9 throttling the signing 
process? Is such throttling configurable?

Jeffry A. Spain * Network Administrator
**
Cincinnati Country Day School * 6905 Given Road, Cincinnati, OH 45243-2898
CountryDay.net * 513 979-0299 * 513 527-7632 (f) 
(UTC-5)
PGP Public Key ID 0xD17AFA13 (4E7B 8F1E F541 43E2 
85D3 3638 76AB 9A4B D17A FA13)

___
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: BIND9 SERVFAIL Issue with Windows 2008 R2 DNS Server

[Spain, Dr. Jeffry A.]

>> Based on a Microsoft tech support case that I opened, the only way to fix 
>> this was to turn off EDNS ("dnscmd /config /EnableEDnsProbes 0").
>> This also seems to have been fixed in Windows Server 2012.

> What a bummer, this essentially stops anyone from using DNSSEC validation 
> correctly on R2. And while DNSSEC validation is a useful utility, what 
> concerns me more is the inability for other organizations / entities to be 
> able to look up our DNSSEC signed zones, especially with the fact that IPv6 
> is enabled by default on R2, causing unanticipated service failures for these 
> organizations / entities.

I think the best bet with Windows Server 2008 R2 DNS is to disable recursion, 
turn off EDNS ("dnscmd /config /EnableEDnsProbes 0"), and continue to use one 
or more DNSSEC-enabled BIND 9 recursive resolvers as a forwarders ("options { 
dnssec-validation auto; allow-query { domain-controllers; }; allow-recursion { 
domain-controllers; }; };"). If you do this, querying the domain controller 
with "dig badsign-A.test.dnssec-tools.org" does return a proper SERVFAIL 
response. DNSSEC-validation is being performed by the BIND resolver, but this 
is transparent to the Windows environment.

I have continued to do things this way with my Windows Server 2012 domain 
controllers, although as you pointed out, it hasn't been necessary to disable 
EDNS since the CD flag in queries from the domain controller to the forwarders 
is cleared by default in this version.

Back to your original question, I have a Windows Server 2008 R2 test VM 
available and so built a domain controller and attempted to confirm your 
findings with dig, shown below. All four dig queries returned NOERROR. The 
query "dig mx2.comcast.com srv +dnssec" caused the domain controller to query 
the forwarder, which returned the Authority records in the order shown below. 
This was confirmed by Wireshark, and is the same order as shown in your queries 
posted earlier. If I understand you correctly, this contradicts your hypothesis 
that Windows Server 2008 R2 DNS requires that the SOA record be returned first 
in the Authority section to avoid a SERVFAIL response.

Regards, Jeff.



Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.

PS C:\> dig mx2.comcast.com srv +dnssec

; <<>> DiG 9.9.3 <<>> mx2.comcast.com srv +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32036
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4000
;; QUESTION SECTION:
;mx2.comcast.com.   IN  SRV

;; AUTHORITY SECTION:
mx2.comcast.com.60  IN  NSECmx3.comcast.com. A RRSIG NSEC
mx2.comcast.com.3600IN  RRSIG   NSEC 5 3 3600 20130711200520 
20130704170020 2643 comcast.com. pmOHJX7dSN
uFSRiFvxNIIuhQk/Sh6/9xSiZ2wj2I6RDKkrQlDScdFjDB 
nSpeWt9068Wq+aQE36dbTsvyyCKgtrPcJIUxKVCtsXzTavXdx9XVGwG9 cKF6TrQx+MGPRwRw
jPorDmPJxImveGMeE7X4Nl1mkGk/lRJwbvk1yFWV w1w=

;; Query time: 124 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jul 07 15:46:43 Eastern Daylight Time 2013
;; MSG SIZE  rcvd: 252

PS C:\> dig '@2001:4870:20ca:158:8c2f:b9ff:31f7:3836' mx2.comcast.com srv 
+dnssec

; <<>> DiG 9.9.3 <<>> @2001:4870:20ca:158:8c2f:b9ff:31f7:3836 mx2.comcast.com 
srv +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48676
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

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

;; AUTHORITY SECTION:
mx2.comcast.com.3600IN  RRSIG   NSEC 5 3 3600 20130711200520 
20130704170020 2643 comcast.com. pmOHJX7dSN
uFSRiFvxNIIuhQk/Sh6/9xSiZ2wj2I6RDKkrQlDScdFjDB 
nSpeWt9068Wq+aQE36dbTsvyyCKgtrPcJIUxKVCtsXzTavXdx9XVGwG9 cKF6TrQx+MGPRwRw
jPorDmPJxImveGMeE7X4Nl1mkGk/lRJwbvk1yFWV w1w=
mx2.comcast.com.3600IN  NSECmx3.comcast.com. A RRSIG NSEC
comcast.com.3600IN  SOA dns101.comcast.net. 
domregtech.comcastonline.com. 2009085823 7200 3600 1
209600 3600
comcast.com.3600IN  RRSIG   SOA 5 2 3600 20130711200520 
20130704170020 2643 comcast.com. Te6jKcUXakW
pPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni 
QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6
zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=

;; Query time: 78 msec
;; SERVER: 
2001:4870:20ca:158:8c2f:b9ff:31f7:3836#53(2001:4870:20ca:158:8c2f:b9ff:31f7:3836)
;; WHEN: Sun Jul 07 15:48:32 Eastern Daylight Time 2013
;; MSG SIZE  rcvd: 502

PS C:\> dig bat.comcast.com srv +dnssec

; <<>> DiG 9.9.3 <<>> bat.comcast.com srv +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49117
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDN

RE: BIND9 SERVFAIL Issue with Windows 2008 R2 DNS Server

[Spain, Dr. Jeffry A.]

> Perhaps someone who has a Windows 2008 R2 domain can go ahead and confirm 
> this, but so far the only way I can see to mitigate this issue is either:

> 1. Disable EDNS on Windows 2008 R2 (which essentially disables the ability to 
> accept DNSSEC based responses) or 2. Disable DNSSEC support in BIND9 with 
> dnssec-enable no; (setting dnssec-validation no; has no effect)

One additional comment on this: When I first set up a DNSSEC-enabled BIND 9 
resolver and used it as a forwarder from Windows Server 2008 R2 DNS, I found 
that Windows DNS would return answers for known-bad queries, thus defeating the 
entire purpose of using a DNSSEC-enabled forwarder. DNSSEC-Tools maintains a 
test zone with various problematic records. See 
http://dnssec-tools.org/testzone/index.html. "dig 
badsign-A.test.dnssec-tools.org" issued to the BIND9 resolver returns a 
SERVFAIL response, as you would expect with an invalid RRSIG. The same query, 
however, issued to the domain controller returned the answer 75.119.216.33. 
This turned out to be happening because Windows DNS was actually sending its 
query as "dig badsign-A.test.dnssec-tools.org +dnssec +cdflag", in other words 
telling BIND not to perform DNSSEC validation. Based on a Microsoft tech 
support case that I opened, the only way to fix this was to turn off EDNS 
("dnscmd /config /EnableEDnsProbes 0"). It turned out
  not to be possible to enable DNSSEC validation on the Windows domain 
controller itself, because the mechanism for entering the DNS root trust anchor 
was also broken.

What response do you get from your domain controller with "dig 
badsign-A.test.dnssec-tools.org"?

This also seems to have been fixed in Windows Server 2012.

Thanks. Jeff.
___
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: BIND9 SERVFAIL Issue with Windows 2008 R2 DNS Server

[Spain, Dr. Jeffry A.]

> Looking at this further, it appears when EDNS is turned on in the Windows 
> 2008 R2 DNS server (default, accepting DNSSEC responses), resolution fails 
> occasionally with a SERVFAIL when NODATA is returned to BIND (i.e. 0 answers 
> with a status code of NOERROR.)

I'm using Windows Server 2012 DNS with BIND 9.9.3 forwarders, and can't 
reproduce the issue. I tested "dig mx2.comcast.com srv +dnssec" and "dig 
bat.comcast.com srv +dnssec" against a Windows domain controller (simon) and 
its BIND 9.9.3 forwarder (nr1). All four queries, shown below, returned 
NOERROR. Perhaps this will provide you a useful basis for comparison in any 
event.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School



Windows PowerShell
Copyright (C) 2012 Microsoft Corporation. All rights reserved.

PS C:\> dig '@simon' mx2.comcast.com srv +dnssec

; <<>> DiG 9.9.3 <<>> @simon mx2.comcast.com srv +dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1927
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4000
;; QUESTION SECTION:
;mx2.comcast.com.   IN  SRV

;; AUTHORITY SECTION:
comcast.com.899 IN  SOA dns101.comcast.net. 
domregtech.comcastonline.com. 2009085823 7200 3600 1
209600 3600
comcast.com.899 IN  RRSIG   SOA 5 2 3600 20130711200520 
20130704170020 2643 comcast.com. Te6jKcUXakW
pPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni 
QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6
zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=
mx2.comcast.com.899 IN  NSECmx3.comcast.com. A RRSIG NSEC

;; Query time: 31 msec
;; SERVER: 
2001:4870:20ca:158:2c59:7bdf:ab15:4270#53(2001:4870:20ca:158:2c59:7bdf:ab15:4270)
;; WHEN: Sat Jul 06 21:12:35 Eastern Daylight Time 2013
;; MSG SIZE  rcvd: 331

PS C:\> dig '@nr1' mx2.comcast.com srv +dnssec

; <<>> DiG 9.9.3 <<>> @nr1 mx2.comcast.com srv +dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38367
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

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

;; AUTHORITY SECTION:
mx2.comcast.com.2173IN  RRSIG   NSEC 5 3 3600 20130711200520 
20130704170020 2643 comcast.com. pmOHJX7dSN
uFSRiFvxNIIuhQk/Sh6/9xSiZ2wj2I6RDKkrQlDScdFjDB 
nSpeWt9068Wq+aQE36dbTsvyyCKgtrPcJIUxKVCtsXzTavXdx9XVGwG9 cKF6TrQx+MGPRwRw
jPorDmPJxImveGMeE7X4Nl1mkGk/lRJwbvk1yFWV w1w=
mx2.comcast.com.2173IN  NSECmx3.comcast.com. A RRSIG NSEC
comcast.com.2173IN  SOA dns101.comcast.net. 
domregtech.comcastonline.com. 2009085823 7200 3600 1
209600 3600
comcast.com.2173IN  RRSIG   SOA 5 2 3600 20130711200520 
20130704170020 2643 comcast.com. Te6jKcUXakW
pPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni 
QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6
zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=

;; Query time: 46 msec
;; SERVER: 
2001:4870:20ca:158:8c2f:b9ff:31f7:3836#53(2001:4870:20ca:158:8c2f:b9ff:31f7:3836)
;; WHEN: Sat Jul 06 21:12:46 Eastern Daylight Time 2013
;; MSG SIZE  rcvd: 502

PS C:\> dig '@simon' bat.comcast.com srv +dnssec

; <<>> DiG 9.9.3 <<>> @simon bat.comcast.com srv +dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26028
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4000
;; QUESTION SECTION:
;bat.comcast.com.   IN  SRV

;; AUTHORITY SECTION:
comcast.com.900 IN  SOA dns101.comcast.net. 
domregtech.comcastonline.com. 2009085823 7200 3600 1
209600 3600
comcast.com.900 IN  RRSIG   SOA 5 2 3600 20130711200520 
20130704170020 2643 comcast.com. Te6jKcUXakW
pPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni 
QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6
zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=
awrelaypool02.comcast.com. 900  IN  NSECwww.bat.comcast.com. A RRSIG 
NSEC

;; Query time: 62 msec
;; SERVER: 
2001:4870:20ca:158:2c59:7bdf:ab15:4270#53(2001:4870:20ca:158:2c59:7bdf:ab15:4270)
;; WHEN: Sat Jul 06 21:13:18 Eastern Daylight Time 2013
;; MSG SIZE  rcvd: 349

PS C:\> dig '@nr1' bat.comcast.com srv +dnssec

; <<>> DiG 9.9.3 <<>> @nr1 bat.comcast.com srv +dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60015
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

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

;; AUTHORITY SECTION:
com

RE: Bind 9.9.3 configuration message: missing 'file' entry

[Spain, Dr. Jeffry A.]

>> The brackets were wrong and we should have checked that obj was true.

> The patch you provided makes the log message go away. The bind9 service 
> appears to be working normally, and named-checkconf produces no output. 
> Thanks. Jeff.

FYI. The patch for /lib/bind9/check.c provided earlier in this thread appears 
to be applicable to 9.9.3-P1 as well. There were no changes to this file 
between the two releases. Jeff.
___
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: Bind 9.9.3 configuration message: missing 'file' entry

[Spain, Dr. Jeffry A.]

> The brackets were wrong and we should have checked that obj was true.

The patch you provided makes the log message go away. The bind9 service appears 
to be working normally, and named-checkconf produces no output. Thanks. Jeff.

___
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: Bind 9.9.3 configuration message: missing 'file' entry

[Spain, Dr. Jeffry A.]

> Have you looked carefuly enough, and to the correct file if there is no 
> missed character that makes the configuration invalid?
> Have you run named-checkconf with and without the given file as parameter?

The log message is new since bind-9.9.2-P2 with no changes to the configuration 
files. The section of code in check.c referred to in my original post has been 
changed from 9.9.2-P2 to 9.9.3. I still believe that the "if" statement in 
check.c as now coded in 9.9.3 accounts for the log messages. Named-checkconf 
gives the same messages with or without the "file" clause and whether or not 
the path to the file is correct, and this is also consistent with the way the 
"if" statement is coded. Thanks. Jeff.
___
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

Bind 9.9.3 configuration message: missing 'file' entry

[Spain, Dr. Jeffry A.]

For bind 9.9.3 build on Ubuntu 12.04LTS x64, I see log messages, for example, 
"/etc/bind/named.conf.local:4: zone 'jaspain.biz': missing 'file' entry" for 
each slave zone configured for inline signing. The file clause is, in fact, 
present in the configuration file, for example:
zone "jaspain.biz" {
type slave;
file "/var/cache/bind/jaspain.biz.db";
key-directory "/var/lib/bind/jaspain.biz";
auto-dnssec maintain;
inline-signing yes;
masters { stealthMasters; };
notify explicit;
also-notify { publicSlaves; };
allow-transfer { localhost; transferees; };
};

The message does not occur for a similar slave zone that does not have 
key-directory, auto-dnssec, or inline-signing configured. The bind9 service 
appears to be functioning normally despite this log message.

The message originates from the code in /lib/bind9/check.c starting in line 
1798.
isc_result_t res1;
obj = NULL;
tresult = cfg_map_get(zoptions, "file", &obj);
obj = NULL;
res1 = cfg_map_get(zoptions, "inline-signing", &obj);
if ((tresult != ISC_R_SUCCESS &&
(ztype == MASTERZONE || ztype == HINTZONE)) ||
(ztype == SLAVEZONE && res1 == ISC_R_SUCCESS)) {
cfg_obj_log(zconfig, logctx, ISC_LOG_ERROR,
"zone '%s': missing 'file' entry",
znamestr);
result = tresult;
}

Based on the code comments starting at line 1785, is the conditional expression 
of the "if" statement incorrectly parenthesized? Should it be as follows?
if (tresult != ISC_R_SUCCESS &&
(ztype == MASTERZONE || ztype == HINTZONE ||
(ztype == SLAVEZONE && res1 == ISC_R_SUCCESS))) {

Thanks. Jeff.

Jeffry A. Spain, Network Administrator
Cincinnati Country Day School

___
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: Building from source and running in chroot environment

[Spain, Dr. Jeffry A.]

> Are there relatively recent instructions on how to build BIND from source and 
> run it in a chroot environment? It sounds obvious but everything I've come 
> across assumes BIND is provided by some package manager or included with the 
> operating system. I'd like to build the latest version of BIND and run it in 
> a chroot environment.  I know you have to pre-populate the chroot directories 
> but am not entirely clear on everything that's needed.

FWIW, I've been running BIND on Ubuntu, which uses AppArmor 
(https://help.ubuntu.com/12.10/serverguide/apparmor.html) to control file 
access by applications and services. I'm not able to argue the relative merits 
of chroot vs. AppArmor vs. other alternatives such as SELinux and SMACK. But 
stipulating for the moment that AppArmor is a reasonable alternative, it is 
fairly easy to use it with BIND 9 built from source. I start by installing the 
current packaged version of BIND on a snapshotted Ubuntu virtual machine that I 
can subsequently roll back. I save the files /etc/apparmor.d/usr.sbin.named and 
/etc/apparmor.d/local/usr.sbin.named, which I then place in my 
built-from-source BIND 9 installation. For this to work without modifying the 
file user.sbin.named, I use in my build the same ancillary directories that the 
Ubuntu package uses: /etc/bind for configuration files, /var/lib/bind for 
master zone data and DNSSEC keys, and /var/cache/bind for secondary zone data. 
Otherwise y
 ou can modify the file usr.sbin.named, which you should examine in conjunction 
with the AppArmor documentation for the details. You can deconstruct the Ubuntu 
bind9 source package (http://packages.ubuntu.com/quantal/bind9) to see 
everything else that the package installer does to set up BIND 9. Note that 
Ubuntu 13.04 (Raring Ringtail), due to be released in late April, will be the 
first Ubuntu version to include a packaged BIND 9.9.x.

Jeffry A. Spain, Network Administrator
Cincinnati Country Day School
___
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: key rollover with BIND 9.9

[Spain, Dr. Jeffry A.]

> What are other people using to automate key rollovers with 9.9?

Michael: I automated mine by generating a set of 9 ZSKs and 2 KSKs for each 
zone in advance, setting the timing metadata to achieve a 90-day prepublication 
rollover cycle for the ZSKs and a 720-day rollover cycle for the KSKs. Once the 
keys are copied to a zone's key directory, bind takes care of the rollovers 
automatically. My domain registrar is GoDaddy.com, so I have to manually upload 
the DS records for the KSKs, but I only have a few domains, and the manual 
process is required only at 2-year intervals. I have a bash script that 
generates the keys and DS records using ISC's dnssec-keygen and 
dnssec-dsfromkey. Please contact me off list if you want a copy of it. Regards, 
Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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 Download and Install Nsupdate from BIND 9 Package

[Spain, Dr. Jeffry A.]

> Please tell me how to download and install Nsupdate from BIND 9 to run on an 
> Windows XP client?
 
1. Download http://ftp.isc.org/isc/bind9/9.9.1-P3/BIND9.9.1-P3.zip.
2. Expand the archive and run BINDInstall.exe.
3. Verify and change the target directory according to your preference.
4. Check the box "Tools Only" and uncheck all the other boxes.
5. Click Install.
6. On successful completion, click OK. Then click Exit.
7. On Windows 7 x64, if you left the target directory as 
C:\Windows\System32\dns, the software will have been installed in 
C:\Windows\SysWOW64\dns instead. Not sure about Windows XP. You might consider 
upgrading from that OS when you can.

Nsupdate.exe is one of the utilities installed by default. You may want to copy 
over some others manually from the installer directory (where you found 
BINDInstall.exe). For example, dnssec-*.exe, named-*.exe, and perhaps others 
that you see there.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School
___
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: Problem with DNSSEC signing zone

[Spain, Dr. Jeffry A.]

> all this step has been well done, but the last step:
> Generate DS records and provide them to your registrar.
> has not been fluent for me. I found how can i provide key to the registrar i 
> used this command:
> dnssec-dsfromkey -2 Kwillzik.co.uk KSK.key  "is it the good way to do?"

That command will generate the DS record for you. The procedure for getting the 
DS record into the parent zone, co.uk in this case, depends on your DNS 
registrar. For example, I use GoDaddy.com, and on their domain management 
website, there is a "Manage DS records" page where you can paste in the key 
digest and certain other information. Not all registrars support DNSSEC DS 
record management, so you may have to transfer your domain to one who does. See 
http://www.icann.org/en/news/in-focus/dnssec/deployment for a list.

> Please tell me how can i bring down this matter and have my AD flag when i 
> made my dig.
The key point to recognize, as stated previously in Carsten Strotmann's post, 
is that you have to query a DNSSEC-enabled recursive resolver to possibly get 
an AD flag returned. Your own authoritative name server will never return an AD 
flag. See https://www.dns-oarc.net/oarc/services/odvr for one that is available 
publicly. Also you can test your zone at http://dnsviz.net to see if there are 
any missing links in your chain of trust from the DNS root.

Best Regards, Jeff.
___
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: Problem with DNSSEC signing zone

[Spain, Dr. Jeffry A.]

> 1. Generated KSK and ZSK
> 2.Add both of keys at the end of my zone file
> 3.signing my zone with dnssec-signzone command
> 4.enable dnssec in named options
> 5.change the name of my zone in the named by namezone.signed
> 6.I got the root DNSKEY RR set before with dig command and redirect the 
> outpout in root-dnskey file
> 7.I turned the DNSKEY into DS RR set also, with dnssec-dsfromkey command.

Also consider simplifying the process as follows:
1.  Generate KSK and ZSK, setting timing metadata so that they are 
published and active. See dnssec-keygen and dnssec-settime.
2.  Place the key files in a key directory on your server.
3.  Add to your zone configuration: key directory ""; 
auto-dnssec maintain;
4.  Generate DS records and provide them to your registrar.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Listen-On and Ipv6

[Spain, Dr. Jeffry A.]

> If no listen-on statement is included, will  requests be processed and 
> logged?

>From Bv9ARM, p. 68: "If no listen-on is specified, the server will listen on 
>port 53 on all IPv4 interfaces." A client could query a quad-A or any other 
>record using IPv4 network transport, and that would be processed normally.

Also from Bv9ARM, p. 69: "If no listen-on-v6 option is specified, the server 
will not listen on any IPv6 address unless -6 is specified when named is 
invoked. If -6 is specified then named will listen on port 53 on all IPv6 
interfaces by default." This would affect any queries, including those for 
quad-A records, received over IPv6 network transport.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Seeking Advice on DNSSEC Algorithm Rollover

[Spain, Dr. Jeffry A.]

>> My experience with changing the timing metadata or removing the key 
>> files is that named issues a warning like the following: zone /IN:
>> Key // missing or inactive and has no
>> replacement: retaining signatures. In this circumstance none of the 
>> RRSIGs or NSECs are removed. They sit there indefinitely even after 
>> the RRSIGs expire.

> If I remember correctly, that was because you removed the keyfile rather than 
> just updating the timing metadata. Try updating the timing data and leaving 
> the keyfiles in place until after BIND has acted on the deletion date.

I did some additional testing over the weekend. Removing the key files without 
updating the timing metadata definitely causes this problem. Updating the 
timing metadata such that the inactive date is in the past and the deletion 
date is in the future also causes this problem. The key to success appears to 
be updating the timing metadata such that the inactive and deletion dates are 
both in the past. I still want to test this where there are no keys present for 
a second algorithm, i.e. a secure to insecure transition. Thanks. Jeff.
___
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: Seeking Advice on DNSSEC Algorithm Rollover

[Spain, Dr. Jeffry A.]

I propose the following addition to the Bv9ARM, and request review and comment 
by the experts on this list.

--

4.9.14 DNSKEY Algorithm Rollover

>From time to time new digital signature algorithms with improved security are 
>introduced, and it may be desirable for administrators to roll over DNSKEYs to 
>a new algorithm, e.g. from RSASHA1 (algorithm 5 or 7) to RSASHA256 (algorithm 
>8). The algorithm rollover must be done with care in a stepwise fashion to 
>avoid breaking DNSSEC validation.

As with other DNSKEY rollovers (sections 4.9.5 - 4.9.7), when the zone is of 
type master, an algorithm rollover can be accomplished using dynamic updates or 
automatic key rollovers. For zones of type slave, only automatic key rollovers 
are possible, but the dnssec-settime utility can be used to control the timing 
of such.

In any case the first step is to put DNSKEYs using the new algorithm in place. 
You must generate the K* files for the new algorithm and put them in the zone's 
key directory where named can access them. Take care to set appropriate 
ownership and permissions on the keys. If the auto-dnssec zone option is set to 
maintain, named will automatically sign the zone with the new keys based on 
their timing metadata when the dnssec-loadkeys-interval elapses or you issue 
the command rndc loadkeys zone. Otherwise for zones of type master, you can use 
nsupdate to add the new DNSKEYs to the zone. This will cause named to use them 
to sign the zone. For zones of type slave, e.g. on a bump-in-the-wire inline 
signing server, nsupdate cannot be used.

Once the zone has been signed by the new DNSKEYs, you must inform the parent 
zone and any trust anchor repositories of the new KSKs, e.g. you might place DS 
records in the parent zone through your DNS registrar's website.

Before starting to remove the old algorithm from a zone, you must allow the 
maximum TTL on its DS records in the parent zone to expire. This will assure 
that any subsequent queries will retrieve the new DS records for the new 
algorithm. After the TTL has expired, you can remove the DS records for the old 
algorithm from the parent zone and any trust anchor repositories. You must then 
allow another maximum TTL interval to elapse so that the old DS records 
disappear from all resolver caches.

The next step is to remove the DNSKEYs using the old algorithm from your zone. 
Again this can be accomplished using nsupdate to delete the old DNSKEYs (master 
zones only) or by automatic key rollover when auto-dnssec is set to maintain. 
You can cause the automatic key rollover to take place immediately by using the 
dnssec-settime utility to adjust the timing metadata on all key files 
associated with the old algorithm. There are five cases:
1) For keys with a deletion date in the past, do nothing.
2) For keys currently published but deactivated, set the deletion date to 
sometime in the past.
3) For keys currently published and active, set the inactive and deletion dates 
to sometime in the past.
4) For keys currently published but not yet active, set the inactive and 
deletion dates to sometime in the past.
5) For keys with a publish date in the future, do nothing.

After adjusting the timing metadata, the command rndc loadkeys zone will cause 
named to remove the DNSKEYs and RRSIGs for the old algorithm from the zone. 
Note also that with the nsupdate method, removing the DNSKEYs also causes named 
to remove the associated RRSIGs automatically.

Once you have verified that the old DNSKEYs and RRSIGs have been removed from 
the zone, the final step (optional) is to remove the key files for the old 
algorithm from the key directory.

--


Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Seeking Advice on DNSSEC Algorithm Rollover

[Spain, Dr. Jeffry A.]

>> I discovered that if there was not at least one KSK and ZSK of the same 
>> algorithm, dnssec-signzone would fail. If one goes with defaults, KSK life 
>> of one year and ZSK of one month, effectively to roll a key algorithm and 
>> without forcing the roll-over by removing all the old key/algorithm at the 
>> same time, you have to wait for a KSK to 'expire' then add a new algorithm 
>> key pair together. As soon as the last old algorithm KSK expires, there must 
>> no longer be any old algorithm ZSK's left, but old algorithm ZSK's must be 
>> around until this event.
>> That is - at the time of roll-over - you have a KSK/ZSK pair using the old 
>> algorithm and a pair using the new algorithm, obviously with appropriate 
>> DS's in the Parent.
>> (That should make sense)

> That sounds like it is worth a try. My experience is that when keys from only 
> one algorithm are in place and those keys go inactive, then named issues 
> warnings "Key // missing or inactive and has no 
> replacement: retaining signatures", and the RRSIGs and NSECs are not removed. 
> Maybe with the second algorithm's keys already in place and the zone signed 
> by them, the behavior will be different. I will report back on this.

This appears to have worked perfectly. Again I started from a position where 
there were two sets of keys in place, one for algorithm 5 and one for algorithm 
8, and the zone was signed by both. For each algorithm, I had a sequence of 
nine ZSKs with timing metadata set so that a key rollover would occur every 90 
days for a two-year period. I had two KSKs for each algorithm: one published 
and active, the other published and not yet active.

I processed the keys for algorithm 5 (the one to be removed) as follows using 
dnssec-settime:
1) For keys with a deletion date in the past, do nothing.
2) For keys currently published but deactivated, set the deletion date to 
earlier today (20120624).
3) For keys currently published and active, set the inactive and deletion dates 
to earlier today.
4) For keys currently published but not yet active, set the inactive and 
deletion dates to earlier today.
5) For keys with a publish date in the future, do nothing.

Immediately afterwards I ran "rndc loadkeys " and for good measure "rndc 
sign ", although perhaps only one of these was really necessary. An AXFR 
immediately afterwards showed no DNSKEYs or RRSIGs remaining from algorithm 5.

I think I'm good to go with this procedure. I think the proposed "resigning 
from scratch" procedure is less desirable since it would involve more 
administrative overhead and more processing by named, so I will not test that 
further at this point. I'll let my previously suggested enhancements to rndc 
stand as an alternative.

Thanks. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Seeking Advice on DNSSEC Algorithm Rollover

[Spain, Dr. Jeffry A.]

> I discovered that if there was not at least one KSK and ZSK of the same 
> algorithm, dnssec-signzone would fail. If one goes with defaults, KSK life of 
> one year and ZSK of one month, effectively to roll a key algorithm and 
> without forcing the roll-over by removing all the old key/algorithm at the 
> same time, you have to wait for a KSK to 'expire' then add a new algorithm 
> key pair together. As soon as the last old algorithm KSK expires, there must 
> no longer be any old algorithm ZSK's left, but old algorithm ZSK's must be 
> around until this event.
> That is - at the time of roll-over - you have a KSK/ZSK pair using the old 
> algorithm and a pair using the new algorithm, obviously with appropriate DS's 
> in the Parent.
> (That should make sense)

That sounds like it is worth a try. My experience is that when keys from only 
one algorithm are in place and those keys go inactive, then named issues 
warnings "Key // missing or inactive and has no 
replacement: retaining signatures", and the RRSIGs and NSECs are not removed. 
Maybe with the second algorithm's keys already in place and the zone signed by 
them, the behavior will be different. I will report back on this.

> So, if you only have a very few signed zones, its possibly easier to resign 
> them from scratch, or force a roll-over. (Avoid the pain!) If you re-do 
> everything at the same time - then DNS signing events may no longer be 
> scattered around the year - maybe not a good thing.

I'm pretty sure that I can resign from scratch as follows on the inline signing 
slave:
1) Remove the key files from the old algorithm.
2) Remove the zone files, both signed and unsigned.
3) Increment the SOA serial number on the unsigned zone on the stealth master 
to something greater than the SOA serial number of the signed zone on the 
inline signing slave.
4) Reload the zone on the inline signing slave.
I will also report back on this.

> I'd expect in-line signing to be of a similar nature unless algorithm 7 and 8 
> keys can as such 'speak for each other'.
> My advice, test mixing old and new algorithm keys by signing with 
> dnssec-signzone and presume the same rules exist for in-line signing too.
> I'd look for a solution that 'upgrades' a zone to using a new Key algorithm 
> at the scheduled time of a KSK roll-over.  

Based on testing since my initial post, I have determined that any solution 
requiring the use of nsupdate isn't going to work. In my scenario where the 
zones are slaves transferring data from a stealth master and doing inline 
signing, i.e. the bump-in-the-wire concept, named won't even start with 
"update-policy local" in the configuration. It considers "update-policy local" 
a configuration error in zones of "type slave".

As I think about this issue more, it seems like a job for rndc. For example, I 
would like to suggest that there be a command "rndc signing -algclear 
 ", which would immediately remove DNSKEY, RRSIG, 
NSEC(3), and any other records pertaining to  from . It would 
be used in the following procedure after the keys for the new algorithm are 
already in place and the zone has been signed by them:

1) "rndc signing -pause " (to pause temporarily "auto-dnssec maintain" 
signing activities). In my previous post I had suggested the syntax "rndc 
pause-signing " but this seems more consistent with existing "rndc 
signing" syntax.
2) Remove the key files belonging to the old algorithm.
3) "rndc signing -algclear  "
4) "rndc sign " (to immediately resume "auto-dnssec maintain" signing 
activities) or wait for dnssec-loadkeys-interval to elapse.

> I'm sure you'll post the results here!
I will. Thanks again for your input. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Seeking Advice on DNSSEC Algorithm Rollover

[Spain, Dr. Jeffry A.]

> I don't think that bind trying to sign with non-existent key will do any harm 
> - probably just warning.
> But it's simpler - change metadata of the key - set deletion time to the time 
> you want the key to be deleted (like DS deletion time+TTL).
> Bind with auto-dnnsec allow re-reads the metadata and should remove the key 
> and all the signatures at that time.
> You don't need nsupdate nor update-policy for that.

Thanks very much. My experience with changing the timing metadata or removing 
the key files is that named issues a warning like the following:
zone /IN: Key // missing or inactive and has no 
replacement: retaining signatures.
In this circumstance none of the RRSIGs or NSECs are removed. They sit there 
indefinitely even after the RRSIGs expire.
Best regards, Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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

Seeking Advice on DNSSEC Algorithm Rollover

[Spain, Dr. Jeffry A.]

I'm experimenting with rolling over my DNSKEYs from algorithm 7 to 8. The 
Bv9ARM doesn't discuss this procedure explicitly as far as I can tell, but 
section 4.9 presents some clues. I'd like to ask the experts on this list if 
the following procedure might accomplish an algorithm rollover cleanly.

The zones on my server (BIND 9.9.1-P1) are set up as slaves for inline signing. 
Unsigned zone data is received from a stealth master via inbound zone transfer. 
Each zone is configured for "auto-dnssec maintain" and "inline-signing yes". A 
series of ZSKs and KSKs are stored in key directories by zone with timing 
metadata set to keep two ZSKs and KSKs published and one active. There is no 
"update-policy" statement in place. Both the unsigned and signed zone files are 
in raw format by default. The dnssec-loadkeys-interval is not specified and so 
defaults to 60 minutes.

First of all, the procedure for adding the new algorithm 8 seems simple, and I 
already did this successfully:

a) Create the required algorithm-8 ZSKs and KSKs and place them in the key 
directories, carefully setting ownership and permissions.
b) "rndc sign " for all zones or wait for dnssec-loadkeys-interval to 
elapse.
c) After verifying that the new DNSKEYs, RRSIGs, and NSECs are in place, 
publish the required algorithm-8 DS records in the parent zones.

The procedure for removing the old algorithm 7 keys seems trickier. I believe 
nsupdate will be required, and so "update-policy local" will need to be added 
to the configuration of each zone followed by "rndc reload". I think the option 
"dnssec-secure-to-insecure yes" may also need to be configured for this to work:

a) Remove the algorithm-7 DS records from the parent zones.
b) Wait for the maximum TTL to expire. From inspection this varies among gTLDs 
and may be as long as 24 hours.
c) Remove all the algorithm 7 keys from the key directories.
d) Using nsupdate, delete all of the algorithm 7 DNSKEYs from each zone. All 
algorithm-7 RRSIGs and NSECs should be automatically removed when the updates 
are sent.

I am concerned that step c) may cause a problem if named decides to carry out 
any signing activities prior to the completion of step d). One could examine 
all the RRSIGs and confirm based on sig-validity-interval that no signing 
activity is immanent, but that seems tedious. One could also temporarily change 
auto-dnssec from maintain to allow, but that also seems cumbersome if there are 
lots of zones.

Perhaps another rndc command could be developed to help with this. For example, 
"rndc pause-signing " might disable signing activities temporarily until 
a subsequent "rndc sign" command was sent, or as a safety valve, until the next 
dnssec-loadkeys-interval elapsed. The dnssec-update-mode option seems to 
incorporate this idea, but it must be statically configured, and is said to 
work only for master zones (as opposed to the inline-signed slave zones that I 
have).

I would be grateful for your additional thoughts on this. Thanks. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Understanding cause of DNS format error (FORMERR)

[Spain, Dr. Jeffry A.]

> I'm a BIND novice and I'm trying to understand what causes my BIND9 resolver 
> (bind97-9.7.0-10.P2) to return an error when queried for the A record of 
> vlasext.partners.extranet.microsoft.com:

FWIW I'm not able to reproduce this using a BIND 9.9.1-P1 recursive resolver. 
On this system "dig @localhost vlasext.partners.extranet.microsoft.com a" 
returns the answer 70.42.230.20 and identifies dns11.one.microsoft.com 
(94.245.124.49) as one of four authoritative servers. "dig @94.245.124.49 
vlasext.partners.extranet.microsoft.com a" also returns the answer 
70.42.230.20, but no authority or additional records (except EDNS UDP 4000), 
and with no AA flag set. On the contrary querying one of my own authoritative 
servers, also running BIND 9.9.1-P1, for a record for which it is authoritative 
("dig @ns2.countryday.net countryday.net a") does return the answer along with 
authority and additional records for the name servers and does have the AA flag 
set. Finally querying one of my internal Microsoft DNS servers (Windows Server 
2008 R2 SP1) for a record for which it is authoritative gives me a correct 
answer, no authority or additional records (except EDNS UDP 4000), but does ha
 ve the AA flag set.

> Is it related to the "AA bit strictness"[1] ? 94.245.124.49 is 
> dns11.one.microsoft.com and does indeed reply without setting the AA bit.
> As far as know the 'strictness' was removed in P2, correct me if I'm wrong.

I don't know enough about the history of BIND functionality to answer this. I'm 
sure others will comment.

>From what I observed I would conclude that dns11.one.microsoft.com is a 
>Windows DNS server since it behaves like mine except for the AA flag not being 
>set in theirs. The missing AA flag and lack of authority and additional 
>records in their response seems like improper behavior to me, but I don't know 
>whether or not the DNS protocol actually requires this. Apparently BIND 
>9.9.1-P1 is able to handle this situation.

Hope this is at least somewhat helpful. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Verify raw data within slaves on 9.9.x

[Spain, Dr. Jeffry A.]

> However - I guess its a little less efficient than the new default 'raw' 
> mode, especially for large zones. Consider a change of approach and if its 
> just an automated check - try 'dig'? I'm finding with in-line signing that 
> zones are often spread about in journal files - which makes options like 
> 'dig' a better way to go. Otherwise - you may have to first run 'rndc sync 
> -clean the.zone'.

I understand that "named-checkzone -j" will incorporate the contents of the 
journal file, if any. Jeff.
___
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: Verify raw data within slaves on 9.9.x

[Spain, Dr. Jeffry A.]

> Would an option be to do a dig axfr on the zone?

That works if "allow-transfer" is set appropriately. It gives you the zone data 
in canonical rather than relative format. Jeff.
___
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: Verify raw data within slaves on 9.9.x

[Spain, Dr. Jeffry A.]

> What tools/commands I can run to get plain ascii/text data out of modern 
> raw/binary on BIND 9.9.x slaves?
> I just want to verify that changes are correct down to the slaves. So - I can 
> check-in these changes into svn etc.

See the ARM under named-checkzone. 
http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/man.named-checkzone.html.
For example "named-checkzone -f raw -F text -s relative -j -o 
example.com.dumped.db example.com /var/lib/named/example.com.db"

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School
___
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: Bind 9.9.x inline signing

[Spain, Dr. Jeffry A.]

> I didn't like the fact that the unsigned serial (which I manage) was lower 
> than that of the signed zone. Making it bigger than the signed zones version 
> appears to have gotten the zones back in sync - however the slave is still 
> not getting any Notifies (and has not yet caught up).

With "inline-signing yes;" and "auto-dnssec maintain;" in place, the SOA serial 
number of the signed zone will always be ahead of the unsigned zone. BIND 9 
periodically carries out signing and key maintenance activities, and in the 
process automatically increments the SOA serial number of the signed zone.

When you manually edit the unsigned zone, you can set the SOA serial number to 
any value larger than the previous value, including incrementing by one, and 
everything should work. BIND 9 tracks the SOA serial numbers of the unsigned 
and signed versions of the zone separately.

Note that you can also use nsupdate to edit the unsigned zone, and nsupdate 
will automatically increment the unsigned zone's SOA serial number for you.

> I also expect that in the future, any 'magic bind key-signing' may also 
> de-sync my unsigned zone's concept of the current SOA Serial as well. 

> Its the apparent lack of NOTIFY's thats really bugging me, I did modify the 
> secondary zone config in named.conf and added "masterfile-format text;" - 
> which saves the zone in nice, easy to debug, ascii. 
> Is the NOTIFY from 'Inline-signing' zones currently broken?

This has been working for me, but with some different configuration settings. 
Because my DNS servers are behind an IPv4 NAT firewall, I have not been relying 
on BIND 9's default notification scheme. The name server addresses in the zone 
files are external IPv4 addresses not reachable from inside the firewall. 
Instead I have configured "notify explicit;" and "also-notify { ... };" to 
control the notification process. This issue also affects the addresses in 
"allow-transfer { ... };" and "masters { ... };" statements.

Did you happen to look at your syslog (cat /var/log/syslog | grep named)? It is 
possible that your slaves are not receiving notifies, or are not able to do 
zone transfers, or both.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Bind 9.9.x operation with dnssec

[Spain, Dr. Jeffry A.]

> With "auto-dnssec maintain", I expect the Zone Signing Keys and the 
> individual RRSIGs to be completely managed and rotated as needed by bind, per 
> https://kb.isc.org/article/AA-00626/0/Inline-Signing-in-ISC-BIND-9.9.0-Examples.html
and the Admin Reference, however, at the end of 4.9.7, it says:

> "By default, this rollover completes in 30 days, after which it will be safe 
> to remove the old key from the DNSKEY RRset."

> This implies that I'm going to have to go in and do housekeeping in the keys 
> directory, though I'm not sure when - I set this up in early March (according 
> to the key activation comments - who remembers details that far back? ;-) ) 
> and they haven't rotated yet...

I don't think you will need to do any housekeeping if you have your key timing 
metadata set up in a reasonable way. There are four relevant timestamps in the 
metadata: Publish, Activate, Inactive, and Delete. You can see this by listing 
the contents of your *.key files. My practice with ZSKs, which has been 
successful over the past year, has to been to generate a series of nine ZSKs 
with timing metadata computed from the following:
* Choose an inception date for DNSSEC operations, for example, today.
* Choose an active lifetime for the keys (90 days for me).
* Choose an introduction time, the number of days prior to activation that a 
key is published. (4 days for me).
* Choose a retirement time, the number of days after inactivation that a key is 
deleted (35 days for me. This needs to be at least 30 days, as you stated 
above, to allow record sets to be resigned with the new key as the old 
signatures expire.)
* Choose a rollover time, the number of days from activation of a key to 
inactivation of its predecessor (1 for me).

Rather than go through the computation process, see the attached dnssec-keyset 
bash script that sets the timing metadata appropriately for each key. For 
example you might run:
./dnssec-keyset 90 4 35 1 raindrop.us 9

For the KSKs, I have been using active lifetime 720, introduction time 7, 
retirement time 35, rollover time 7, so for example:
./dnssec-keyset -k 72- 7 35 1 raindrop.us 2

> When it comes to the DS records registered at the registrar, I'm not sure 
> where that comes from: the only way I can see to get it is to do a DS query 
> from the nameserver (and at least one document basically said that).  First, 
> I'd like to know where it comes from, and second, it seems much too small, 
> given ksks are supposed to be bigger as a result of being longer lived.

You would use the dnssec-dsfromkey utility to generate your delegation signer 
(DS) record data. The attached dnssec-keyset script shows how this fits in. The 
DS data is a digest of your public key. Its length depends on the digest 
algorithm you specifiy, typically SHA1 and/or SHA256. The digest length is 
fixed and not related to the length of your public key. The authenticity of 
your DNSKEY records is therefore predicated on the fact that the DS record is 
signed by the parent zone and the likelihood of a digest collision with two 
different keys is vanishingly small.

> When it comes time to roll the DS key, it looks like I pick a lifetime, say 3 
> months, generate a new DS key (how, such that 9.9.x will use it?

When BIND 9.9 rolls over your KSK, you need to have anticipated that and have 
published your new DS record in the parent zone prior to that. My practice has 
been to generate two KSKs, both of which are published but only the first of 
which is active, and to publish both DS records in the parent. As I understand 
it, there is no significant security risk to publishing a public key that is 
not being used for signing.

> Next, I have a DS record configured at my registrar obtained with dig from my 
> nameserver, but that doesn't seem to be right...

Again, use the results of dnssec-dsfromkey. Typically you will enter this on 
your registrar's website. You will need the key identifier, algorithm, and DS 
data field.

I hope this is helpful. This is complicated. It took me quite a while to 
understand, and I still don't get it completely. However, inline-signing can be 
made to work well for you and pretty much automatic once you set up a proper 
series of keys with appropriate timing metadata. 

Regards, Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School



dnssec-keyset
Description: dnssec-keyset
___
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: different between views and having multiple instances

[Spain, Dr. Jeffry A.]

>> I need to understand the difference between configuring bind views and 
>> having multiple instances of bind. I have 5 network interfaces on my 
>> server and I want to have 2 instances of DNS server (just for testing) 
>> and I don't know which one to do ?

> BIND views are powerful, but configuring them can become complex.

> If your machine has the resources for doing so, I'd recommend running 
> multiple instances of BIND, which will enable you to stop/start your 
> test-instances at will.  Furthermore you'll probably find configuration of 
> individual BIND name servers easier to create and manage. On the down-side 
> you'll need monitoring for the N instances, you'll probably have N logs, etc.

> Knowing what I do from your description, I would chose the N instances.

Rather than running multiple bind instances on one server, is virtualization an 
option for you? Thus you could build multiple virtual machines each running a 
single bind instance.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Bind9.9.1 Dependences

[Spain, Dr. Jeffry A.]

> How can I find out which Unix files/libraries bind requires before I do the 
> compile?

I have successfully built Bind 9.9.1 on Ubuntu 12.04 LTS (Precise Pangolin). 
Since Ubuntu comes with a previous version of the Bind 9 utilities installed, I 
uninstall the following packages:
apt-get purge bind9-host dnsutils libbind9-80 libdns81 libisc83 libisccc80 
libisccfg82 liblwres80

To be able to build bind9, I install the following tools for building software 
packages:
apt-get install build-essential autoconf libtool pkg-config

Bind9 has a dependency on OpenSSL:
apt-get install libssl-dev

After that you should be able to download Bind 9.9.1, configure, make, and make 
install. See bind-9.9.1/README for info on options to configure.

Hopefully this provides some general guidance regardless of distribution. I 
have a script and some ancillary files that I can send you if you are in fact 
using Ubuntu 12.04 LTS.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Bind 9 configuration

[Spain, Dr. Jeffry A.]

> (I hope that it's fine to ask about issues connected with the previous 
> version of bind.)
Bind9 has its own listserv at bind-users@lists.isc.org. There are many DNS 
experts available there.

> Could you confirm that my settings are correct?
> I'm using this guide (my configuration scenario is primary master server):
> https://help.ubuntu.com/community/BIND9ServerHowto
See also the definitive bind9 documentation at 
http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.pdf. This is for the 
current version 9.9 of bind. See http://www.isc.org/software/bind/documentation 
for earlier versions.

> Questions:
> 1. My /etc/hosts doesn't contain anything related to ns.example.com. Is this 
> OK?
Probably ok. Your /etc/resolv.conf should contain the addresses of recursive 
resolvers that can resolve ns.example.com and any other domain name.

> 2. How to configure bind to support IPv6?
You should have a file /etc/named.conf.options. It should contain by default:
options {
listen-on-v6 { any; };
};
Beyond this if your network where your example.com hosts are located supports 
IPv6 and you have IPv6 Internet connectivity, then add  records to your 
zone files so that your domain names can be resolved to IPv6 addresses.

> 3. I have joe.example.com in db.example.com. Will it be my email address 
> (e.g. j...@example.com)?
The domain name joe.example.com doesn't correlate to the mailbox 
j...@example.com. You have specified your mail exchanger as mail.example.com. 
That host needs to know how to deliver messages to the mailbox j...@example.com.

> 4. Is it possible (and necessary) to have several ns (and mx) records on the 
> same machine?
Possible and recommended but not necessary. With multiple NS records and thus 
multiple authoritative DNS servers, you have redundancy in the case of a DNS 
server failure. Typically you would configure one as a master with one or more 
slaves, or have a stealth master with two or more slaves. With multiple MX 
records, each of which should have a different priority, you can specify 
preferred and backup mail exchangers to mitigate against mail host failures.

> 5. What should I write in /etc/bind/db. file? Could you 
> provide an example?
This is a reverse DNS zone file for purposes of resolving IP addresses to 
domain names. It must contain an SOA and NS records like your forward zone file 
and PTR records. For this to work properly, your ISP will need to delegate 
reverse DNS resolution for your address space to you.

> 6. Is there a need for additional tweaking?
Seems like there is always a need for tweaking. Start by seeing how things are 
working. Check your log file "cat /var/log/syslog | grep named". Use the "dig" 
utility to look up domain names on your server, e.g. "dig @ns.example.com 
www.example.com". See the above-cited Bv9ARM.pdf for more info on dig and other 
bind utilities. Here's a good book for you to read: 
http://www.amazon.com/DNS-BIND-5th-Edition-Cricket/dp/0596100574.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Multiple zones with single key pair

[Spain, Dr. Jeffry A.]

> Multiple zones with a single key - is possible with BIND ?

There was a recent discussion on this topic. See thread beginning at 
https://lists.isc.org/pipermail/bind-users/2012-April/087481.html. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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 does a child find its parent?

[Spain, Dr. Jeffry A.]

> Reading the section on delegation in the O'Reilly book, I'm confused about
> something: The parent is configured to delegate the subdomain to the child
> with glue records, etc. But how does the child know who to ask if a host in 
> the
> subdomain requests a record in the parent zone? They don't show any
> configuration example for that other than making the child a slave for the 
> parent zone.

I think the confusion relates to the separate roles of authoritative name 
servers and recursive resolvers. A host in the subdomain would ask a recursive 
resolver to find a record in the parent domain, or for that manner any record, 
and the resolver would find it through the standard recursive resolution 
process starting from the DNS root. The slave server, which is not a recursive 
resolver but an authoritative server, would not be a party to that. If the 
slave needed to contact the parent for any reason, it would also use a 
recursive resolver to find the parent's address. That recursive resolver would 
be configured in /etc/resolv.conf or in Windows as a DNS entry in the network 
interface configuration.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School
___
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 for

[Spain, Dr. Jeffry A.]

> 1. In down level Windows, everything is OK.
> 2. In upper level dns(bind), ns record, and A record of nameserver is fine.
> 3. But A record in WIndows Server can not resolved by upper level BIND.
> I think maybe I have to do something in my windows server to "connect" 
> windows with linux bind?

If you configured your Windows DNS server as a slave authoritative server to 
your BIND master, then I would not expect that an A record added to the slave 
would be reflected in the master. If it is your intention to continue to do 
zone updates on the Windows DNS server, then make it the master and the BIND 
server the slave. If you are operating a Windows Active Directory domain 
environment, then dynamic updates to your Windows DNS zones are going to happen 
frequently.

In Windows DNS you would do this configuration on the General tab of the zone 
properties page. Set the zone type to Primary and make it Active-Directory 
integrated if you are running it on a domain controller. Then on the Zone 
Transfers tab, configure it to allow transfers only to servers listed on the 
Name Servers tab and also configure it to automatically Notify the servers on 
the Name Servers tab.

Note also that Windows DNS servers by default are configured as recursive 
resolvers as well as authoritative servers for any zones you set up on them. 
Operating these two functions on the same server is not recommended for 
security reasons. You can mitigate this by setting up one or more BIND servers 
as a recursive resolvers and configuring the Windows DNS server to use them as 
forwarders. You should then uncheck the box "Use root hints if no forwarders 
are available" on the Forwarders tab of the DNS server properties page.

There is a lot of information about this on Microsoft TechNet, as a little 
Google searching will reveal.

Regards, Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School
___
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: Inline Signing does not update SOA?

[Spain, Dr. Jeffry A.]

> When I update the SOA record of the master zone file, if I reload the zone 
> with "rndc reload", the SOA record is updated. If I perform a stop/start of 
> the named executable, the SOA change is not updated.

Ralph: There was a lot of discussion about this issue on the bind forum around 
the first of the year. My recollection is that with inline-signing enabled, 
stopping named, editing the zone file, and restarting named isn't a supported 
method of updating zone data. I am aware of two supported options: 1) as you 
did above, edit the zone file and run 'rndc reload', 2) use 'nsupdate'. Others 
will probably recall this in more detail and more accurately. Regards, Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Question about KSK

[Spain, Dr. Jeffry A.]

> We are authoritative for a few dozen small zones.  Is it possible to use the 
> same KSK for all of them?  I can see where if it gets compromised we would 
> need to resign all zones using the KSK at once.  How much effort would I be 
> saving sharing the KSK?

My sense is that you would be creating more effort, at least more concentrated 
effort, for yourself on the back end. When the shared KSK needed to be rolled 
over, you would have to process DS records in the parents of your few dozen 
zones all at the same time. Instead you could script dnssec-keygen to create 
unique KSKs for each zone, and in so doing you could adjust the timing metadata 
for each to spread this rollover workload over a suitable period of time. My 
sense is that keeping track of the KSK files themselves does not create a large 
amount of administrative overhead.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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 Generating Zone Key hanging

[Spain, Dr. Jeffry A.]

> I was setting up BIND DNSSEC and when I issue the following command the 
> process never finishes.
> dnssec-keygen -a RSASHA1 -b 1024 -n ZONE example.com

Take a look at the Entropy Key (http://www.entropykey.co.uk/). See also a 
discussion (http://jpmens.net/2012/01/24/entropy-random-data-for-dnssec/) by a 
frequent poster to this forum.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: testing validation

[Spain, Dr. Jeffry A.]

> Though I am still curious about this from the end of sigchase output:
> Launch a query to find a RRset of type DS for zone: .
> ;; NO ANSWERS: no more
> ;; WARNING There is no DS for the zone: .
> Isn't the "DS for the zone: ." what the "managed-keys" clause provides?

Now I think I see what you mean. It is my understanding that DS records exist 
in parent zones and refer to child zones that are to be trusted. Thus there is 
no DS record referring to the root zone, as it by definition has no parent. The 
root trust anchor provided by managed-keys or dnssec-validation serves the same 
purpose as this non-existent DS record. The warning above makes sense in this 
context. Jeff.
___
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: testing validation

[Spain, Dr. Jeffry A.]

> Why would 149.20.64.20 return ad then?  It's not authoritative either...

As I understand it, you need a dnssec-enabled recursive resolver to get an AD 
flag returned. An authoritative-only server will never return an AD flag. Jeff.
___
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: testing validation

[Spain, Dr. Jeffry A.]

> Isn't the "DS for the zone: ." what the "managed-keys" clause provides?
> Though putting it back in didn't make the warning go away, so I must be 
> missing something else here...

Any difference with dnssec-validation auto and removing the managed-keys and 
root hint zone? Jeff.
___
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: testing validation

[Spain, Dr. Jeffry A.]

Alan: Comments on your configuration file:

I believe that managed-keys... and zone "." { type hint... are built into bind 
9.9.0 recursive resolvers and therefore not needed. You can enable the built in 
root trust anchor by changing dnssec-validation from yes to auto.

I think that listen-on { 127.0.0.1; }; will prevent your resolver from 
accepting queries from network sources, and so is inconsistent with your 
allow-query statement. Consider omitting listen-on and changing listen-on-v6 to 
{any;}.

Consider adding zones for 
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 and 
localhost.

Jeff.


___
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: testing validation

[Spain, Dr. Jeffry A.]

> I'm testing out dnssec with bind 9.9.0's auto signing and a test domain; this 
> appears to be working (see below, RRSIG records returned from the actual 
> nameserver), however and attempt to validate fails with:
> # dig +dnssec +sigchase soa raindrop.us
> When I simply try to validate the root:

> # dig +dnssec +sigchase .
> ;; NO ANSWERS: no more

> # dig +dnssec @ns6.peak.org raindrop.us
> ;; WARNING: recursion requested but not available

Your post is somewhat unclear to me. Querying from my bind 9.9.0 recursive 
resolver "dig @localhost raindrop.us +dnssec", I get an AD flag returned, 
suggesting that dnssec is working for raindrop.us. In your query "dig +dnssec 
+sigchase soa raindrop.us", is the resolver dnssec-enabled? I assume this would 
be one of the resolvers listed in your resolv.conf file. It appears that 
ns6.peak.org is not a recursive resolver. Does it have a zone file for 
raindrop.us?

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School
___
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: fermat primes and dnssec-keygen bug?

[Spain, Dr. Jeffry A.]

> There's quite a bit about choosing e in this presentation:
> http://www.esiea-recherche.eu/Slides09/slides_iAWACS09_Erra-Grenier_How-to-compute-RSA-keys.pdf

> However, I don't understand the math, so I can't say whether any of the 
> advice is reasonable :(

Interesting document, although I'm not a mathematician either. Slide 15 is the 
key, I think, saying in essence that there's no way to be certain that any 
given RSA key is secure. To be less uncertain about one's RSA keys, it suggests 
among other things reviewing recommendations from various national agencies. On 
slide 21 are some recommendations for the public key exponent: an odd integer 
not less than 65537 (Fermat number 4) and less than 2^256 (Fermat number 8 
minus 1). Slide 23 describes a minor flaw when the exponent is greater than F4, 
but indicates that it is not a serious threat. Based on this document I don't 
see any reason to believe that exponent F4 (dnssec-keygen default) is any more 
or less secure than F5 (dnssec-keygen -e). Signature verification with exponent 
F5 would take more CPU time, but we don't have any benchmarking data to 
indicate whether or not this is significant.

Other posts have alluded to the Debian openssl flaw reported in May 2008 
(http://www.debian.org/security/2008/dsa-1571). This led to predictable random 
primes being used to generate RSA moduli, and was not related to any specific 
public key exponent. It affected openssl version 0.9.8c-1, but only the Debian 
version.

Regards, Jeff.
___
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: fermat primes and dnssec-keygen bug?

[Spain, Dr. Jeffry A.]

> Well, go argue with Adam Langly in the bug report I submitted (and Paul 
> quoted in this thread).

You're making an argumentum ad verecundiam, which I can't reasonably pursue. In 
the bug report 
(http://code.google.com/p/go/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Status%20Stars%20Priority%20Owner%20Reporter%20Summary&groupby=&sort=&id=3161),
 Adam Langly (assuming that is who "agl" is) refers to the article "Ron was 
wrong, Whit is right" (http://eprint.iacr.org/2012/064.pdf). That article 
discusses RSA public exponents in section 3, and states that the exponent 
2^127+3 is used in a small percentage public keys, a fact to which agl alludes 
in his post. It doesn't address the security implications of any particular 
public key exponent, other than a few cases of what appear to be RSA 
implementation errors. The article focuses mainly on problems with the RSA 
modulus, rather than the exponent. Based on the facts presented so far in this 
thread, I can't find support for your assertion that keys created with 
'dnssec-keygen -e' are insecure. Please post any additional ev
 idence you may have that would further the discussion. Thanks. Jeff.
___
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: fermat primes and dnssec-keygen bug?

[Spain, Dr. Jeffry A.]

> Its not about integer overflow, it's about the fact that F5 does not add to 
> the security, but does use up a lot of CPU cycles.

I'd like to study this issue more. Would you please provide a reference that 
discusses your assertion that using an F5 public exponent does not add to the 
security of RSA encryption vs. F4 or perhaps F0.

With regard to CPU utilization, from the description of the modular 
exponentiation algorithm at 
http://en.wikipedia.org/wiki/Modular_exponentiation#Right-to-left_binary_method,
 it appears that the number of modular multiplications required for a modular 
exponentiation is the total number of bits in the exponent plus the number of 
one bits. This is 19 for an F4 exponent and 35 for F5. Given this, it's not 
obvious to me that the CPU utilization differences are significant. If you can 
point me to a reference that benchmarks this, that would be much appreciated.

Thanks. Jeff.
___
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: fermat primes and dnssec-keygen bug?

[Spain, Dr. Jeffry A.]

> I would recommend that dnssec-keygen starts ignoring the "-e" parameter that 
> everyone has put in their scripts to prevent exponent 3 keys, who are not 
> getting keys with exponent 4294967296 + 1 (F5)

> Alternatively, if this is done on purpose, I guess we should all migrate the 
> 64 bit machines :)

As background, see the discussion of Fermat Numbers, e.g. F4 and F5, at 
http://en.wikipedia.org/wiki/Fermat_number. See also the role of the exponent 
in RSA public-key cryptography at http://en.wikipedia.org/wiki/RSA_(algorithm).

This is interesting, if I correctly understand your point, but it appears that 
dnssec-keygen computes F5 differently than you do in your example in 
http://code.google.com/p/go/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Status%20Stars%20Priority%20Owner%20Reporter%20Summary&groupby=&sort=&id=3161.

In your example:
pubkey := new(rsa.PublicKey)
pubkey.N = big.NewInt(0)
pubkey.E = 4294967296 + 1
which results in 32-bit integer overflow.

In bind-9.9.0/lib/dns/opensslrsa_link.c, starting at line 750:
if (exp == 0) {
/* RSA_F4 0x10001 */
BN_set_bit(e, 0);
BN_set_bit(e, 16);
} else {
/* F5 0x10001 */
BN_set_bit(e, 0);
BN_set_bit(e, 32);
}
where exp is nonzero if option -e is set in the original call to dnssec-keygen 
and e is a BIGNUM pointer initialized as 'BIGNUM *e = BN_new();'. I would 
surmise that e is not subject to integer overflow in its representation of F5. 
The BIGNUM type is a component of OpenSSL. See 
http://www.openssl.org/docs/crypto/bn.html. According to this document it 
supports arbitrary precision integer arithmetic subject only to memory 
allocation limits with no indication of a dependency on 32-bit or 64-bit CPU 
architecture. If there is a problem, I think it would be with OpenSSL rather 
than dnssec-keygen.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: DKIM in TXT record

[Spain, Dr. Jeffry A.]

> What is the proper format to write a DKIM TXT?

There seems to be quite a bit of information about this available via Google 
search. Here's one reference I found that gives some step-by-step instructions:
Creating DKIM TXT Records in Linux/UNIX Bind
http://forum.unifiedemail.net/default.aspx?g=posts&t=72

Here's the official site: http://www.dkim.org/.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: reverse dns for IPV6 ranges

[Spain, Dr. Jeffry A.]

> But if only some IP have e reverse..what about the other server who have 
> received an IP in the range? Ip that can be changed every x hours.
> IF no reverse, it can be blacklisted for some reasons or having some problems 
> with services asking a reverse dns resolution.

In my ip6.arpa zone, all of the entries are for servers whose IPv6 addresses 
never change. If you are going to register PTR records for clients with 
changeable IPv6 addresses, then you need a dynamic update mechanism. Mark 
Andrews made a recommendation earlier in this regard. I don't think there is 
any reason to have PTR records that have no corresponding  records in the 
forward lookup zone. That would be computationally infeasible anyway. Jeff.
___
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: A question for the reference

[Spain, Dr. Jeffry A.]

I tested this by capturing network traffic on a bind 9.9.0 recursive resolver. 
The commands 'rndc flush' followed by 'dig @localhost funnygamesite.com' 
resulted in the following:
1. A query to m.gtld-servers.net.
2. The same referral response that you got below.
3. A follow-up query 500 microseconds after the response to ns1.dnsbed.com.
4. Ns1.dnsbed.com then provided the answer (127.0.0.1).

Thus it appears that bind 9.9.0 is relying on the data in the Authority and 
Additional sections of the first query for the addresses of funnygamesite.com's 
authoritative name servers. It is not making any additional queries for the 
addresses of those name servers. Jeff.

-Original Message-

Please see this case:

$ dig funnygamesite.com @k.gtld-servers.net

; <<>> DiG 9.7.3 <<>> funnygamesite.com @k.gtld-servers.net ;; global options: 
+cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35540 ;; flags: qr rd; 
QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion 
requested but not available

;; QUESTION SECTION:
;funnygamesite.com. IN  A

;; AUTHORITY SECTION:
funnygamesite.com.  172800  IN  NS  ns1.dnsbed.com.
funnygamesite.com.  172800  IN  NS  ns2.dnsbed.com.

;; ADDITIONAL SECTION:
ns1.dnsbed.com. 172800  IN  A   174.140.172.238
ns2.dnsbed.com. 172800  IN  A   50.31.252.20

;; Query time: 188 msec
;; SERVER: 192.52.178.30#53(192.52.178.30) ;; WHEN: Tue Mar  6 09:30:42 2012 ;; 
MSG SIZE  rcvd: 110


When a resolver query funnygamesite.com from one of the gtld name servers, will 
the resolver use the reference (AUTHORITY SECTION and ADDITIONAL SECTION) 
directly? or it make another query for ns1.dnsbed.com and ns2.dnsbed.com and 
get the authorative answers for them?
___
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

bind9.9.0 named-checkzone usage message

[Spain, Dr. Jeffry A.]

root@ns0s:~ # named-checkzone
usage: named-checkzone [-djqvD] [-c class] [-f inputformat] [-F outputformat] 
[-t directory] [-w directory] [-k (ignore|warn|fail)] [-n (ignore|warn|fail)] 
[-m (ignore|warn|fail)] [-r (ignore|warn|fail)] [-i 
(full|full-sibling|local|local-sibling|none)] [-M (ignore|warn|fail)] [-S 
(ignore|warn|fail)] [-W (ignore|warn)] [-o filename] zonename filename

FWIW, the options [-h] [-L serial] [-s style], as described in Bv9ARM.pdf, page 
158, are missing from the usage message. Same with named-compilezone.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: reverse dns for IPV6 ranges

[Spain, Dr. Jeffry A.]

> Can anyone help me with  its experience on reverse dns for IPV6?
> Presently, when we reverse an IPV4 subnet for clients, we configure all the 
> reverse for the whole subnet.
> It is a lot of PTR's but perfectly manageable.
> With IPV6,  the number of IP's that we will receive is amazing
> So...it seems impossible for every single IPV6 inthe range to configure a PTR.
> So...what to do?
> What is the common practice?
> What is possible with BIND?

For our IPv6 address space 2001:4870:20ca::/48, I created a reverse lookup zone 
a.c.0.2.0.7.8.4.1.0.0.2.ip6.arpa and arranged for delegation from our ISP.  I 
included PTR records only for those hosts accessible from the outside. Internal 
DNS is Windows Active Directory integrated. Here's a sample from the zone file, 
which contains about 25 PTR records in all:

$ORIGIN .
$TTL 3600   ; 1 hour
a.c.0.2.0.7.8.4.1.0.0.2.ip6.arpa IN SOA ns1.countryday.net. 
hostmaster.countryday.net. (
2012030101 ; serial
86400  ; refresh (1 day)
3600   ; retry (1 hour)
1209600; expire (2 weeks)
3600   ; minimum (1 hour)
)
NS  ns1.countryday.net.
NS  ns2.countryday.net.
$ORIGIN 9.0.0.0.a.c.0.2.0.7.8.4.1.0.0.2.ip6.arpa.
a.5.6.9.f.9.e.4.3.4.3.e.f.a.0.8 PTR ns2.countryday.net.
$ORIGIN 8.5.1.0.a.c.0.2.0.7.8.4.1.0.0.2.ip6.arpa.
2.9.1.f.1.d.2.1.b.f.7.5.7.f.8.0 PTR ns1.countryday.net.

I would also be interested in hearing about the practices of others. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: BIND 9.9.0 Inline-Signing Out of Control

[Spain, Dr. Jeffry A.]

> We thought of two other differences between this zone and the others:

> 1. this zone has NS records with servers that are in the zone itself, and 2. 
> our global "also-notify" option contain IP addresses that resolve to host 
> names in this zone.

I don't have a handle on the underlying problem, but you can tamp down the 
notification process.

For your master zones:

acl peskySlaves {
;
;
...
};

zone "pesky.zone" {
type master;
...
notify explicit;
also-notify { peskySlaves; };
allow-transfer { peskySlaves; };
...
};

And for your slave zones:

options {
notify no; (or notify master-only;)
...
};

See ftp://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.pdf, pages 15 and 62.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: RFC 6303 and bind 9.9.0

[Spain, Dr. Jeffry A.]

> Didn't the answer to the NS query include the addresses in the Additional 
> Section?  It does when I perform the query manually.  It gets cut off with 
> the default packet size, but if EDNS0 is used it will include them all.

The addresses are included in the additional section. Missed that earlier. The 
UDP datagram length is of the response is 865. The request included EDNS0 UDP 
payload size 4096. Jeff.
___
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: RFC 6303 and bind 9.9.0

[Spain, Dr. Jeffry A.]

>> No, it requires a rebuild after changing lib/dns/rootns.c. But using a 
>> mildly out-of-date hints file is usually harmless - it is only a *hint*.

> Right. One of the first things BIND does after starting up is query one of 
> the root servers to get the current set of root servers.

Thanks. This is not what I am seeing using tcpdump and capturing port 53. Using 
a test bind9.9.0 resolver, I restarted the bind9 service to clear the cache and 
load the built-in root hints. There was no DNS traffic for a minute until I 
issued the first dig query to the server. The first DNS packet transmitted was 
to send this query to the IPv4 address of i.root-servers.net (192.36.148.17). 
The second query, 300 microsec later also to i.root-servers.net, was for "NS 
". I didn't see any packets querying for addresses of the root servers. 
It might be that if that second query returned the name of a new root server 
not in the built-in hints, bind9.9.0 would query for its address at some point.

> So the only potential problem would be if someone were to hijack one (or
> more) of the root servers and make it give out a bogus answer.

___
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: RFC 6303 and bind 9.9.0

[Spain, Dr. Jeffry A.]

>> If the root hints are updated on ftp://rs.internic.net/domain/, would 
>> it require a new build of bind to incorporate them, or is bind able to 
>> update its built-in root hints by some other means?

> No, it requires a rebuild after changing lib/dns/rootns.c. But using a mildly 
> out-of-date hints file is usually harmless - it is only a *hint*.

> [Having said that, I admit I specify an explicit root hints file and keep it 
> up to date in most of my own nameserver configurations.]

Interesting. I compared the contents of character array root_ns[] in 
bind-9.9.0/lib/dns/rootns.c with the contents of 
ftp://ftp.internic.net/domain/named.root (dated Jun 8, 2011). Bind9.9.0 is 
missing "D.ROOT-SERVERS.NET. 360 IN  2001:500:2D::D\n" and 
some of the TTLs in bind9.9.0 are 518400 instead of 360, as all of them are 
in the named.root. Jeff.
___
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: RFC 6303 and bind 9.9.0

[Spain, Dr. Jeffry A.]

> In my named.conf I have set up empty zones for the whole of 240/4. I view RFC 
> 6303 as the minimum necessary for a hygienic name server, but there are a 
> number of other permanent bogon address ranges which it makes sense to stub 
> out locally.

Would you please elaborate on how you are managing your bogon-related empty 
zones. According to http://www.team-cymru.org/Services/Bogons/bgp.html, there 
are 5500 IPv4 and 49000 IPv6 bogon prefixes. Thanks. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: RFC 6303 and bind 9.9.0

[Spain, Dr. Jeffry A.]

>> Just for clarification, do I understand correctly that if none of the 
>> empty zones described in RFC 6303 are set up explicitly in the bind 
>> 9.9.0 configuration file, then bind 9.9.0 will process them as such 
>> anyway using built-in generic zone processing rules?

> Yes.  To expand a bit on Mark's answer, all of the namespaces covered by RFC 
> 6303 have built-in empty zones in BIND 9.9, and these zones are activated by 
> default in any view that supports recursion.  No configuration should be 
> necessary.

> If you want to set up reverse DNS for a private network in a nonroutable 
> address space, you can go ahead and do so; zones that you configure override 
> the built-in zones.

Thanks. This works as you say if I remove the explicit configuration for the 
empty zones, as verified by adding the option 'zone-statistics yes;' and 
running 'rndc stats'.

Also I see that bind 9.9.0 uses built-in root hints if those are not explicitly 
configured. If the root hints are updated on ftp://rs.internic.net/domain/, 
would it require a new build of bind to incorporate them, or is bind able to 
update its built-in root hints by some other means?

Finally it appears that aside from the built-in empty zones, a forward lookup 
zone for 'localhost.' is  still required to prevent bind from attempting to 
resolve this name over the Internet. Reverse lookup zones for 127.0.0.1 and ::1 
are also required if it is necessary to resolve those addresses to the name 
'localhost.' Is it still considered a best practice to explicitly configure 
these localhost-related zones on recursive resolvers? I see this point 
addressed in RFC 1912, but don't see anything in RFC 5735 and RFC 6303, which 
have superseded it.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: RFC 6303 and bind 9.9.0

[Spain, Dr. Jeffry A.]

>> Changing the second line ('@ 10800 IN NS @') to '@ 10800 IN NS localhost.' 
>> eliminates the errors.
> The built in empty zone processing is aware of the special case of NS records 
> without address records.  The generic zone processing rules treat this as a 
> error condition.

Just for clarification, do I understand correctly that if none of the empty 
zones described in RFC 6303 are set up explicitly in the bind 9.9.0 
configuration file, then bind 9.9.0 will process them as such anyway using 
built-in generic zone processing rules?

>> (Empty zone 255.255.255.255.in-addr.arpa (RFC 6303) vs. 255.in-addr.arpa. 
>> (RFC 1912)
> BCP 163 (RFC 6303) is based on BCP 153 (RFC 5735) which trumps RFC 1912.

RFC 5735 allocates 240.0.0.0/4, which would include 255.0.0.0/8 except for 
255.255.255.255, as "Reserved for Future Use". Based on this, it makes sense to 
me not to have an empty zone for 255.in-addr.arpa.

Thanks. Jeff.

___
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

RFC 6303 and bind 9.9.0

[Spain, Dr. Jeffry A.]

I reviewed RFC 6303, which recommends configuring a number of zones using an 
empty zone file as follows:

@ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
@ 10800 IN NS @

In bind 9.9.0 this results in errors for each zone referring to the empty zone 
file as follows:
Feb 29 19:24:30 ns0s named[6044]: zone 10.in-addr.arpa/IN: NS '10.in-addr.arpa' 
has no address records (A or )
Feb 29 19:24:30 ns0s named[6044]: zone 10.in-addr.arpa/IN: not loaded due to 
errors.

Changing the second line to '@ 10800 IN NS localhost.' eliminates the errors.

This question was raised several weeks ago (see 
https://lists.isc.org/pipermail/bind-users/2012-January/086321.html), but no 
explanation was offered as to why '@ 10800 IN NS @' causes these errors. What 
additional thoughts does anyone have?

Another question with regard to RFC 6303: 255.255.255.255.in-addr.arpa is 
recommended for an empty zone. RFC 1912, on the contrary, and stipulating to 
the fact that this document is 15 years old, recommends 255.in-addr.arpa. Going 
with the recommendations in RFC 6303 results in 'dig @localhost -x 225.x.y.z' 
sending a query out to the Internet for any 255.x.y.x other than 
255.255.255.255. Which of these alternative empty zones should be used in the 
current DNS environment and why?

Thanks. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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

bind9.9.0rc4 rndc retransfer appears to be fixed

[Spain, Dr. Jeffry A.]

> With the properly patched bind 9.9.0rc3 running, 'rndc retransfer 
> jaspain.biz' generated no output, presumably indicating success.

> The log showed some related error messages, however...

> Seems like it is confusing the serial numbers of the signed and unsigned 
> zones.

I installed the bind9.9.0rc4 early release code. I retested a bind10 zone 
update followed by 'rndc retransfer' on the bind9.9.0rc4 inline signing server. 
The command executed successfully, there were no errors reported in the log, 
and the unsigned and signed zone contents as displayed by named-checkzone look 
as they should. Thanks. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School
___
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: bind 9.9.0rc3 inline signing server not updating unsigned zone

[Spain, Dr. Jeffry A.]

Mark: Your patch version 3 is included below to confirm that this is the 
correct one. Initially the patch didn't work properly due to a missing line 
break before "@@ -5993,6 +5994,12 @@". I fixed that and ran the bind9.9.0rc3 
installation again. A manual inspection of server.c afterwards indicated that 
the patch executed correctly.

With the properly patched bind 9.9.0rc3 running, 'rndc retransfer jaspain.biz' 
generated no output, presumably indicating success.

The log showed some related error messages, however:
Feb 22 13:50:43 nsb0s named[8594]: received control channel command 'retransfer 
jaspain.biz'
Feb 22 13:50:43 nsb0s named[8594]: zone jaspain.biz/IN (unsigned): Transfer 
started.
Feb 22 13:50:43 nsb0s named[8594]: transfer of 'jaspain.biz/IN (unsigned)' from 
2001:4870:20ca:158:14ff:7695:9632:e9ec#53: connected using 
2001:4870:20ca:158:383e:4365:e3fe:ef7e#45705
Feb 22 13:50:43 nsb0s named[8594]: zone jaspain.biz/IN (unsigned): transferred 
serial 2012013004: TSIG 'nsb0-nsb0s'
Feb 22 13:50:43 nsb0s named[8594]: transfer of 'jaspain.biz/IN (unsigned)' from 
2001:4870:20ca:158:14ff:7695:9632:e9ec#53: Transfer completed: 1 messages, 10 
records, 392 bytes, 0.005 secs (78400 bytes/sec)
Feb 22 13:50:43 nsb0s named[8594]: zone jaspain.biz/IN (signed): zone serial 
(2012013004/2012013006) has gone backwards
Feb 22 13:50:43 nsb0s named[8594]: zone jaspain.biz/IN (signed): loaded serial 
2012013004
Feb 22 13:50:43 nsb0s named[8594]: zone jaspain.biz/IN (signed): 
receive_secure_serial: unchanged
Feb 22 13:50:43 nsb0s named[8594]: zone jaspain.biz/IN (signed): 
receive_secure_serial: unchanged
Feb 22 13:50:43 nsb0s named[8594]: zone jaspain.biz/IN (signed): reconfiguring 
zone keys
Feb 22 13:50:43 nsb0s named[8594]: malformed transaction: 
/var/cache/bind/jaspain.biz.db.signed.jnl last serial 2012013006 != transaction 
first serial 2012013004
Feb 22 13:50:43 nsb0s named[8594]: zone jaspain.biz/IN (signed): 
zone_rekey:dns_journal_write_transaction -> unexpected error
Feb 22 13:50:43 nsb0s named[8594]: zone jaspain.biz/IN (signed): sending 
notifies (serial 2012013004)

Seems like it is confusing the serial numbers of the signed and unsigned zones. 
2012013004 is the incremented serial number of the unsigned zone. The signed 
zone had serial number 2012013006 prior to the retransfer attempt. Tcpdump 
showed a successful AXFR of the unsigned zone with serial number 2012013004.

Thanks. Jeff.

--

Patch version 3:
Index: bin/named/server.c
===
RCS file: /proj/cvs/prod/bind9/bin/named/server.c,v
retrieving revision 1.638.4.3
diff -u -r1.638.4.3 server.c
--- bin/named/server.c  7 Feb 2012 00:58:40 -   1.638.4.3
+++ bin/named/server.c  21 Feb 2012 23:05:47 -
@@ -5986,6 +5986,7 @@
 ns_server_retransfercommand(ns_server_t *server, char *args) {
isc_result_t result;
dns_zone_t *zone = NULL;
+   dns_zone_t *raw = NULL;
dns_zonetype_t type;
 
result = zone_from_args(server, args, NULL, &zone, NULL, ISC_TRUE); @@ 
-5993,6 +5994,12 @@
return (result);
if (zone == NULL)
return (ISC_R_UNEXPECTEDEND);
+   dns_zone_getraw(zone, &raw);
+   if (raw != NULL) {
+   dns_zone_detach(&zone);
+   dns_zone_attach(raw, &zone);
+   dns_zone_detach(&raw);
+   }
type = dns_zone_gettype(zone);
if (type == dns_zone_slave || type == dns_zone_stub)
dns_zone_forcereload(zone);

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

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

RE: bind 9.9.0rc3 inline signing server not updating unsigned zone

[Spain, Dr. Jeffry A.]

> Ok.  The retransfer code needs to look at the unsigned zone rather than the 
> signed one which should fix the not found issue.  The following should fix 
> the issue.  It compiles but otherwise has not been tested.

Thanks, I will try it and get back to you with the result.

> As to soa refresh queries they are not immediate for slave zones for which we 
> have a backup copy of the zone.  Think about a slave service with 10 
> zones and the resulting startup traffic if they all made refresh queries at 
> once.

That, of course, makes sense. My thinking is biased by the fact that I am 
working with only a few small zones. It looks like it sent the SOA refresh 
query and attempted to transfer the zone about 36 minutes after startup. The 
transfer failed, and it has been retrying and failing in the same manner about 
every half hour. I will capture this traffic to see what the problem might be.

Feb 21 10:27:27 nsb0s named[30314]: starting BIND 9.9.0rc3 -u bind
...
Feb 21 11:03:19 nsb0s named[30314]: zone jaspain.biz/IN (unsigned): Transfer 
started.
Feb 21 11:03:19 nsb0s named[30314]: transfer of 'jaspain.biz/IN (unsigned)' 
from 2001:4870:20ca:158:14ff:7695:9632:e9ec#53: connected using 
2001:4870:20ca:158:383e:4365:e3fe:ef7e#34734
Feb 21 11:03:19 nsb0s named[30314]: transfer of 'jaspain.biz/IN (unsigned)' 
from 2001:4870:20ca:158:14ff:7695:9632:e9ec#53: resetting
Feb 21 11:03:19 nsb0s named[30314]: transfer of 'jaspain.biz/IN (unsigned)' 
from 2001:4870:20ca:158:14ff:7695:9632:e9ec#53: connected using 
2001:4870:20ca:158:383e:4365:e3fe:ef7e#45878
Feb 21 11:03:19 nsb0s named[30314]: transfer of 'jaspain.biz/IN (unsigned)' 
from 2001:4870:20ca:158:14ff:7695:9632:e9ec#53: failed while receiving 
responses: end of file
Feb 21 11:03:19 nsb0s named[30314]: transfer of 'jaspain.biz/IN (unsigned)' 
from 2001:4870:20ca:158:14ff:7695:9632:e9ec#53: Transfer completed: 0 messages, 
0 records, 0 bytes, 0.001 secs (0 bytes/sec)

Thanks. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: bind public/private domain question

[Spain, Dr. Jeffry A.]

> I'm looking for advice on an issue.  I have a publicly registered domain 
> which we also use internally.  I have bind configured as a caching DNS 
> server.  Bind is configured to use four other Windows DNS servers as 
> forwarders for the domain.  Bind should be using the root servers for 
> anything not configured to forward.

I'm having difficulty understanding your configuration. Would you please 
provide relevant portions of your bind configuration files and some 
configuration details for your Windows DNS servers. In particular with regard 
to the Windows DNS servers, are they authoritative for your Active Directory 
domain? Are the zones for which they are authoritative Active Directory 
integrated? What is their forwarding configuration? Do their Forward Lookup 
Zones contain internal or external addresses?

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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

bind 9.9.0rc3 inline signing server not updating unsigned zone

[Spain, Dr. Jeffry A.]

The configuration below is for a bind 9.9.0rc3 server named nsb0s providing 
inline signing service for a hidden master nsb0 and slaves nsb1 and nsb2. The 
latter three are running bind10-devel-20120119. Nsb1 and nsb2 are also known as 
ns1.jaspain.net and ns2.jaspain.net.

In an effort to test the response of these systems to a zone update, I 
incremented the serial number for the unsigned zone jaspain.biz on server nsb0 
and reloaded the zone data. The current SOA for jaspain.biz on nsb0 is:
jaspain.biz. 3600 IN SOA ns1.jaspain.net. hostmaster.countryday.net. 2012013003 
86400 3600 1209600 3600

Unfortunately bind10 is not sending notifies properly, so I restarted bind9 on 
nsb0s an an attempt to have it check for updates itself. On nsb0s, the unsigned 
zone jaspain.biz is not being updated. 'named-checkzone -f raw -F text -o - -j 
jaspain.biz jaspain.biz.db' shows in part:
jaspain.biz. 3600 IN SOA ns1.jaspain.net. hostmaster.countryday.net. 2012013001 
86400 3600 1209600 3600
jaspain.biz. 3600 IN NS ns1.jaspain.net.
jaspain.biz. 3600 IN NS ns2.jaspain.net.

After restarting bind9 on nsb0s, I see the following related log entries:
Feb 21 10:27:27 nsb0s named[30314]: zone jaspain.biz/IN (unsigned): loaded 
serial 2012013001
Feb 21 10:27:27 nsb0s named[30314]: zone jaspain.biz/IN (signed): loaded serial 
2012013004 (DNSSEC signed)
Feb 21 10:27:27 nsb0s named[30314]: zone jaspain.biz/IN (signed): 
receive_secure_serial: unchanged
Feb 21 10:27:27 nsb0s named[30314]: zone jaspain.biz/IN (signed): reconfiguring 
zone keys
Feb 21 10:27:27 nsb0s named[30314]: zone jaspain.biz/IN (signed): next key 
event: 21-Feb-2012 11:27:27.248
Feb 21 10:27:27 nsb0s named[30314]: zone jaspain.biz/IN (signed): sending 
notifies (serial 2012013004)

Using tcpdump, I don't see any communication between nsb0s and nsb0 in the 
aftermath of the restart.

I also tried ' rndc retransfer jaspain.biz', which resulted in the following 
error message:
rndc: 'retransfer' failed: not found

Thanks for any suggestions about further troubleshooting steps or errors that 
you may see in the nsb0s configuration, which follows. Regards, Jeff.

acl transferees {
2001:4870:20ca:a:dc72:3ddd:1cbc:5ef0;   // noc1.countryday.net
2001:4870:20ca:200:940a:afef:ba57:ff15; // jaspain.countryday.net
2001:4870:20ca:158:4423:f19d:4ead:5c20; // nsb1.countryday.net
2001:4870:20ca:9:1890:f431:72c9:caaf;   // nsb2.countryday.net
};

options {
directory "/var/cache/bind";
auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
version none;
recursion no;
notify explicit;
allow-transfer { transferees; };
};

key nsb0-nsb0s {
algorithm hmac-sha256;
secret "";
};

key nsb0s-nsb1 {
algorithm hmac-sha256;
secret "";
};

key nsb0s-nsb2 {
algorithm hmac-sha256;
secret "";
};

server 2001:4870:20ca:158:14ff:7695:9632:e9ec {
keys { nsb0-nsb0s; };
};

server 2001:4870:20ca:158:4423:f19d:4ead:5c20 {
keys { nsb0s-nsb1; };
};

server 2001:4870:20ca:9:1890:f431:72c9:caaf {
keys { nsb0s-nsb2; };
};

zone "jaspain.biz" {
type slave;
file "/var/cache/bind/jaspain.biz.db";
masters {
2001:4870:20ca:158:14ff:7695:9632:e9ec; // nsb0.countryday.net
};
also-notify {
2001:4870:20ca:158:4423:f19d:4ead:5c20; // nsb1.countryday.net
2001:4870:20ca:9:1890:f431:72c9:caaf;   // nsb2.countryday.net
};
key-directory "/var/lib/bind/jaspain.biz";
auto-dnssec maintain;
inline-signing yes;
};

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Query Regarding NSEC RR in DNSSEC

[Spain, Dr. Jeffry A.]

> We have a Authenticated Response in DNSSEC through trust chain.
> Now my question is why we itself need a NSEC when we get response from DNSSEC 
> enabled server authentically.

> Means, if a Record exist in DNSSEC, then it replies the answer along with 
> RRSIG of that RR. 
> AND if domain doesn't exist, then it can simply give NXDOMAIN and our job 
> will be done as we trust that nameserver through trust chain.
> So what's the need of NSEC??

Be sure you are not confusing the roles of your stub resolver and the recursive 
resolver to which it is sending its queries. The recursive resolver needs to 
analyze DNSSEC data that it gets from various authoritative servers and from 
its cache. These include DS, DNSKEY, RRSIG, and NSEC records. It then returns 
an answer to your stub resolver with the AD flag if DNSSEC validation succeeds, 
or an NXDOMAIN response if DNSSEC validation fails. Your stub resolver doesn't 
need to see any of the DNSSEC records used in the validation process, but the 
recursive resolver can't do without them for purposes of DNSSEC validation.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School
___
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: dig -- only RRSIG present.

[Spain, Dr. Jeffry A.]

>> Ok, thanks a lot. I thought it was a client process. Now I can query 
>> for the DS, DNSKEY records from isc.org.

>> Final question -- bind.odvr.dns-oarc.net is a cache right? Does bind 
>> has such a caching program? Do we have a DNSSEC capable resolver in BIND?

> Bind *is* a caching program.

> Yes, bind is a DNSSEC-capable resolver.

Given your interest in the internals of the DNSSEC validation process, you 
should consider building your own bind recursive resolver. You could use 
wireshark to see all the information flow between it and the various 
authoritative servers it queries following a 'dig @localhost ...' command. You 
could use 'rndc flush' between queries so that the cache does not obscure what 
is happening. Jeff.

___
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: dig -- only RRSIG present.

[Spain, Dr. Jeffry A.]

>> Try this one: dig @bind.odvr.dns-oarc.net. isc.org +dnssec You should 
>> get an AD flag returned and a variety of RRSIG records. Jeff.

> I hope I'm not missing any concepts here, but there should be a public key to 
> verify the RRSIG, where's that? Shouldn't the server return additional DNSKEY 
> records?
The public key is the DNSKEY record whose private key was used to create the 
RRSIG. It's in the zone data but won't be returned in response to a query from 
dig unless you ask for it, e.g. 'dig @bind.odvr.dns-oarc.net. isc.org dnskey 
+dnssec'. That doesn't mean that the recursive resolver, in this case 
bind.odvr.dns-oarc.net, isn't looking at the DNSKEY records as part of its 
internal DNSSEC validation process.

> Also if I replace bind.odvr.dns-oarc.net. with one of the root nameservers, 
> why is it that AD flag is not set? The root nameservers are DNSSEC capable.
The AD flag is only set by recursive resolvers that are capable of validating a 
DNSSEC chain of trust. The root servers are DNSSEC-capable but are 
authoritative servers, i.e. they only return information from their own zone 
files and can't validate a chain of trust.

Here's a possibly missing concept. There are three entities involved in your 
dig queries:
1. A stub resolver, which is your system running dig.
2. A recursive resolver, which is bind.odvr.dns-oarc.net, and which issues a 
series of queries on your behalf in order to get the answer you asked for and 
do DNSSEC validation on it. It does so without returning to you the internals 
of that process.
3. A series of authoritative name servers, which bind.odvr.dns-oarc.net queries 
to get the answer you want. Again you don't see this activity with dig.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: dig -- only RRSIG present.

[Spain, Dr. Jeffry A.]

> Using this DNS server, I'm still not getting the DNSKEY for any DNSSEC 
> capable domain; infact this server has issues - 
> dig +dnssec -t A dnssec.net @bind.odvr.dns-oarc.net.
> I'd be really happy if I could get some domains which are signed.

Try this one: dig @bind.odvr.dns-oarc.net. isc.org +dnssec
You should get an AD flag returned and a variety of RRSIG records. Jeff.
___
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: dig -- only RRSIG present.

[Spain, Dr. Jeffry A.]

> But another question remains, where's the DNSKEY record which's the missing 
> link as of the current time.
> Querying --
> dig +dnssec -t DNSKEY yahoo.com @198.41.0.4
> Does not return anything.

I think that yahoo.com is probably not a DNSSEC-signed zone and so has no 
DNSKEY records. Otherwise the query below would return DNSSEC-related records 
and probably an AD flag. By the way, bind.odvr.dns-oarc.net is a 
publicly-available DNSSEC-enabled recursive resolver that is good to use for 
testing purposes. See https://www.dns-oarc.net/oarc/services/odvr. Jeff

PS C:\> dig '@bind.odvr.dns-oarc.net.' yahoo.com +dnssec

; <<>> DiG 9.9.0rc2 <<>> @bind.odvr.dns-oarc.net. yahoo.com +dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6844
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 1

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

;; ANSWER SECTION:
yahoo.com.  3600IN  A   72.30.2.43
yahoo.com.  3600IN  A   98.137.149.56
yahoo.com.  3600IN  A   98.139.183.24
yahoo.com.  3600IN  A   209.191.122.70

;; AUTHORITY SECTION:
yahoo.com.  161515  IN  NS  ns1.yahoo.com.
yahoo.com.  161515  IN  NS  ns5.yahoo.com.
yahoo.com.  161515  IN  NS  ns4.yahoo.com.
yahoo.com.  161515  IN  NS  ns3.yahoo.com.
yahoo.com.  161515  IN  NS  ns2.yahoo.com.

;; Query time: 795 msec
;; SERVER: 2001:4f8:3:2bc:1:0:64:20#53(2001:4f8:3:2bc:1:0:64:20)
;; WHEN: Sun Feb 12 23:39:39 2012
;; MSG SIZE  rcvd: 192

___
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: dig -- only RRSIG present.

[Spain, Dr. Jeffry A.]

> As Tony Finch pointed out to me a few days ago, the Google public servers 
> don't understand that fact about DS records, and don't know to ask for them 
> in the parent. But here's something interesting - as of my testing just now, 
> they *do* respond with DS records

This thread has been kind of confusing, but looking again at the original post 
(https://lists.isc.org/pipermail/bind-users/2012-February/086586.html), the 
author was concerned about the lack of DS records in response to his queries. 
Those two queries, directed to Google's server at 8.8.8.8, were:
dig +dnssec -t SOA org
dig +dnssec -t SOA org 198.41.0.4

I don't think any DS records should have been provided in the answers since SOA 
records were being requested. Your query:
dig isc.org @8.8.8.8 ds +dnssec
is requesting and receiving DS records, on the other hand.

I also see Mark's post just now where 'dig @8.8.8.8 ds org.' returns SERVFAIL 
while 'dig @8.8.8.8 ds isc.org.' returns the appropriate DS records. The same 
thing happens for me with 'dig @8.8.8.8 ds net.' and 'dig @8.8.8.8 ds 
jaspain.net.', and with 'dig @8.8.8.8 ds com.' and 'dig @8.8.8.8 ds 
countryday.com.'. Clearly Google's server is malfunctioning in this regard.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: State diagram for DNSsec key lifecycle

[Spain, Dr. Jeffry A.]

>>> I recommend "activate" + "publish" at the same time.
>> I'd appreciate knowing your reasoning for preferring this
> You are going from unsigned to signed.  There is no benefit in publishing, 
> waiting then activating.

The IETF draft "DNSSEC Key Timing Considerations" 
(http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing-02) goes into 
great detail about all of this. This draft document expired on 9/11/2011. Is 
there a successor document and/or other references that you would recommend on 
this topic? Thanks.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

[Spain, Dr. Jeffry A.]

> It's because a few load balancer vendors don't read freely available 
> specifications but instead appear to reverse engineer the protocol and get it 
> wrong.

> BIND 9.7.0 fixed a long standing of accepting glue promoted to answer by 
> parent nameservers.  Once we did that there was no need to accept none "aa" 
> answers from servers that have been listed as being authoritative for the 
> zone.  This allowed the resolver to ignore broken authoritative servers.

> This got relaxed in later release of BIND 9.7.

It's fairly easy for me to deploy a VM and build a particular version of bind. 
Below is your query run on 9.7.0-P1 and 9.7.4-P1. It fails on the former and 
succeeds on the latter, as suggested by Mark Andrews above. Are you in a 
position to upgrade bind? Jeff.


; <<>> DiG 9.7.0-P1 <<>> @localhost winqual.partners.extranet.microsoft.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28201
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;winqual.partners.extranet.microsoft.com. IN A

;; Query time: 1744 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Feb  9 19:36:51 2012
;; MSG SIZE  rcvd: 57


; <<>> DiG 9.7.4-P1 <<>> @localhost winqual.partners.extranet.microsoft.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47557
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;winqual.partners.extranet.microsoft.com. IN A

;; ANSWER SECTION:
winqual.partners.extranet.microsoft.com. 10 IN A 131.107.97.31

;; AUTHORITY SECTION:
partners.extranet.microsoft.com. 3600 IN NS dns11.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns12.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns10.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns13.one.microsoft.com.

;; Query time: 668 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Feb  9 19:15:58 2012
;; MSG SIZE  rcvd: 157

___
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: State diagram for DNSsec key lifecycle

[Spain, Dr. Jeffry A.]

> Please comment on this state diagram:
> https://www.chaos1.de/svn-public/repos/network-tools/DNSsec/trunk/dnssec_key_states.pdf

For greater clarity, I suggest that for the state transitions (captions on the 
arrows), you refer specifically to the four metadata timestamps that are 
present in the keys: Publish, Activate, Inactive, and Delete, since these 
govern what bind does with the keys.

I think it would help also to add some information about how you will set the 
values for these timestamps when the keys are generated with dnssec-keygen.

You don't address the issue of key revocation, but perhaps that should wait for 
later.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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 validate DNSSEC signed record with dig?

[Spain, Dr. Jeffry A.]

William: In my tests of DNSSEC, I have used 'auto-dnsssec maintain;' rather 
than explicitly signing the zone with dnssec-signzone. I believe I recall that 
you are using bind 9.8, so this should work for you as well. Here's something 
you can try:

In your bind configuration use the following zone stanza:
zone "toto.com" {
type master;
file "/var/lib/bind/toto.com/toto.com.db";
key-directory "/var/lib/bind/toto.com";
auto-dnssec maintain;
};

You will probably want to add some access control to this as well.

Now in the directory /var/lib/bind/toto.com (or the directory of your choice as 
long as it is specified in the configuration above), place all of your *.key 
and *.private files. Also place your unsigned zone file toto.com.db with 
contents as follows (Omit the DNSSEC info you currently have at the bottom):

$ORIGIN .
$TTL 17200  ; 4 hours 46 minutes 40 seconds
toto.com. IN SOA  ns10.boom.fr. postmaster.boom.com. (
2012020802 ; serial
216000 ; refresh (2 days 12 hours)
3600   ; retry (1 hour)
360; expire (5 weeks 6 days 16 hours)
172800 ; minimum (2 days)
)
NS  ns.boom.fr.
NS  ns2.boom.fr.
A   217.128.32.85
$ORIGIN toto.com.
*   A   217.128.32.85

If you are running bind under a UID other than root, make sure all the files 
are readable, and that the zone file is writable, by that UID. Restart the bind 
service, and bind will sign your zone using the keys you have provided as long 
as their metadata is timed appropriately, i.e. Publish and Activate dates are 
in the past, and Inactive and Delete dates in the future. To see the metadata, 
execute 'dnssec-settime -p all your_key_file_name.private'. If you need to 
change the timing metadata, use dnssec-settime again. See the ARM for details. 
Caution: dnssec-setime will 'chmod 600' your private key files.

I have been successful with this approach, and hope it works well for you also. 
Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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 validate DNSSEC signed record with dig?

[Spain, Dr. Jeffry A.]

> dnssec-signzone: fatal: key myKSK.key not at origin

What are the contents of myKSK.key?
The format is "mydomain.com. IN DNSKEY ..." where mydomain.com is the domain 
origin.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Windows 2008 R2 validating DNSSEC resolvers

[Spain, Dr. Jeffry A.]

> I know this is a bind list, but does anyone know any public information about 
> when/if Microsoft is going to release a SHA2 compatible DNS server so it can 
> be used as a validating DNSSEC resolver without forwarders? Since the root 
> trust anchor is published in SHA2, currently it can't be used (unless someone 
> knows a workaround).

We ran into the same roadblock and are using a bind9.8.1P1 server as a 
forwarder. Perhaps Windows Server 8 will offer something new a year from now. I 
haven't heard of anything for Windows Server 2008 R2, although SP2 is 
supposedly due for release in mid-2012. On the other hand forwarding to a bind 
system as the recursive resolver for Windows may ultimately be a more secure 
configuration. ISC has been pretty transparent and responsive with regard to 
DNS security issues and functionality updates. The fact that Microsoft *still* 
hasn't updated their DNS service to properly handle DNSSEC tells you something 
about their priorities, I think. The root zone was signed 18 months ago, after 
all.

I'm curious about your experience with the following in this context. We found 
that by default the Windows DNS service would forward queries to bind with the 
DO bit set in the OPT pseudo-resource record and the CD query flag set. In 
other words, Windows DNS was saying to bind "give me the DNSSEC info and I'll 
validate it." Of course without the root trust anchor in place, Windows could 
never do this. Bind would dutifully obey the request, however, so you never got 
the SERVFAIL response you would want with a DNSSEC validation failure. I opened 
a tech support case with Microsoft around this issue. It turns out that the 
command 'dnscmd /config /EnableEDnsProbes 0' fixes the problem by omitting the 
OPT pseudo-resource record and coincidentally clearing the CD query flag in all 
forwarded queries. See "Dnscmd" at 
http://technet.microsoft.com/en-us/library/cc772069(WS.10).aspx for further 
details. You can test for this on your systems as follows: 'dig 
@bind.odvr.dns-oarc.net badsign
 -a.test.dnssec-tools.org' with return a SERVFAIL response from this publicly 
accessible DNSSEC-validating recursive resolver. Now on one of your Windows 
systems: 'dig badsign-a.test.dnssec-tools.org' (or use nslookup if you haven't 
installed the ISC DNS utilities for Windows). This will work through your 
Windows DNS infrastructure, and if it returns the answer 75.119.216.33 instead 
of SERVFAIL, then you are subject to this problem.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: zone serial (0) unchanged. zone may fail to transfer to slaves.

[Spain, Dr. Jeffry A.]

>> Feb  4 15:53:46 nsb0s named[9090]: zone jspain.us/IN (signed): zone serial
>> (2012013003) unchanged. zone may fail to transfer to slaves.

> I suspect that is is benign.  Had you just thawed the server/zone?

After a review of the logs over the past several days, I see that this message 
occurred only once for each zone following an 'rndc reload'. The slaves had not 
yet been configured at the time. Now that the slaves are operational, this 
message does not recur with 'rndc reload'. So I guess the message was an 
accurate cautionary note at the time. Thanks. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: zone serial (0) unchanged. zone may fail to transfer to slaves.

[Spain, Dr. Jeffry A.]

>> named (BIND 9.7.4-P1)
>>  err named[9964]: 05-Feb-2012 17:23:16.586 general: error: zone
>> 127.IN-ADDR.ARPA/IN/internal: zone serial (0) unchanged. zone may fail 
>> to transfer to slaves.

> Ignore it.  The message is suppressed in the next maintence release.

I see similar messages in 9.9.0rc2, where I have configured a server to receive 
unsigned zones for DNSSEC inline signing from a bind10-devel-20120119 hidden 
master and to serve the signed zones to two bind10-devel-20120119 slaves:

Feb  4 15:53:46 nsb0s named[9090]: zone jspain.us/IN (signed): zone serial 
(2012013003) unchanged. zone may fail to transfer to slaves.

The 9.9.0rc2 server is configured with the option "notify explicit;" and the 
zones, which are of type slave, are configured with masters {  }; and "also notify {  };". 
Is it this particular configuration that triggers this message? or should I 
look for other issues? or should this message be ignored in this context as 
well? Thanks. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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 validate DNSSEC signed record with dig?

[Spain, Dr. Jeffry A.]

> I am trying to validate DNSSEC signature on ns record using dig.
> Domain nox.su is properly signed using DNSSEC. 
> I am trying to validate it as dicribed here:
> http://bryars.eu/2010/08/validating-and-exploring-dnssec-with-dig/
> $ dig +nocomments +nostats +nocmd +noquestion -t dnskey . > trusted-key.key $ 
> dig +topdown +sigchase  nox.su
> but it gives me ";; DSset is missing to continue validation: FAILED" error 
> while processing the whole hierarchy of zones.

> $ cat /etc/resolv.conf
> # Generated by NetworkManager
> domain router
> search router
> nameserver 8.8.8.8
> nameserver 78.46.213.227

Checking your two name servers, 8.8.8.8 (google-public-dns-a.google.com) 
doesn't appear to offer DNSSEC validation, and 78.46.213.227 (rms.coozila.com) 
doesn't respond to my query at all.

A known-good publicly accessible DNSEC-validating recursive resolver is 
available at bind.odvr.dns-oarc.net. If I run "dig @bind.odvr.dns-oarc.net 
nox.su +dnssec", I get an AD (authenticated data) flag returned for the A 
record with IPv4 address 50.16.193.159. This is a prima facie indication that 
DNSSEC is working for nox.su. The "+topdown" option isn't available to me (bind 
9.9.0rc2 version of dig).

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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

9.9.0rc2 Windows Installer Tools Only Installation Issues

[Spain, Dr. Jeffry A.]

The BIND9.9.0rc2.zip Windows installer allows for a "Tools Only" installation. 
With this you can avoid having to enter the service account information that 
will not be needed. However, the only tools you get are dig.exe, nslookup.exe, 
and a couple of others.

It would be nice to also include dnssec-*.exe and named-*.exe to facilitate 
DNSSEC key management and zone troubleshooting without having to do the full 
named service installation. As it stands, if you want these tools but don't 
want to run the named service on Windows, you do have to do the full service 
installation. This includes specifying a service account name and password, and 
then unchecking "Automatic Startup" and "Start BIND Service After Install."

With the 9.9.0 release just around the corner, perhaps this could be considered 
for 9.9.1.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School


___
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: Recovering from over enthusiastic key cleanup...

[Spain, Dr. Jeffry A.]

> So, is there:
> A: an easy way to figure out what keyfiles are no longer being used / 
> referenced?
> B: a simpler way to recover from this when one *does* make a boo boo?

What a fun evening. For the sake of interest, which version of bind is in use? 
With regard to item A, how about executing the following from your key 
directory:

for f in *.private; do echo; echo $f; dnssec-settime -p all "$f"; done

Any key file for which the Inactive time is in the past would not be needed for 
signing. Bind would publish it in the zone if the key file were present and the 
Delete time were in the future (and the Publish time in the past). Any key for 
which the Delete time is in the past would not need to be retained in the key 
directory, as it would not be needed for publication or signing.

With regard to B, I don't understand why restoring the deleted key files didn't 
fix the problem, and so will leave further comment to the experts.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: trying DNSSEC with 9.9-rc1

[Spain, Dr. Jeffry A.]

> Any suggestions, folks? What am I not understanding?

Michael: To determine why there is no DNSSEC information being returned by your 
dig query, consider the following:

What are the timestamps in your key metadata? Are they currently published and 
active?
nstest/etc/namedb/keys;dnssec-settime -p all 
Ktransnetworks.net.+005+54607.private

What are the file modes and ownership of your keys? Can named running under 
whatever UID it is using read the keys?

What are the full contents of your unsigned and signed zone files? Any clues 
there?
nstest/etc/namedb/keys;named-checkzone -j -o - transnetworks.net 
transnetworks.net
nstest/etc/namedb/keys;named-checkzone -j -f raw -o - transnetworks.net 
transnetworks.net.signed

Are there syslog messages that indicate any problems signing your zone?
nstest/etc/namedb/keys;cat /var/log/syslog | grep named

Ultimately with dnssec-dsfromkey, you may wish to leave out "-2" and generate 
both SHA-1 and SHA-256 digests. Depending on your registrar, they may accept 
one, the other, or both. The DS record submission is usually done on your 
registrar's web site.

With dnssec-keygen, I used "-b 2048". I don't think there is a compelling 
argument for using a shorter key.

Note that dig +dnssec queries targeted at your authoritative server will 
ultimately return DNSSEC records but will never return an AD flag. Eventually 
you will want to see the AD flag to know that all is well with the chain of 
trust though "net." up to the DNS root zone, and for this you will need a 
DNSSEC-enabled recursive resolver. You can use DNS-OARC's open validating 
resolver to test: https://www.dns-oarc.net/oarc/services/odvr. You can fairly 
easily set up another bind server as a recursive resolver for your own use as 
well. Two other good tests for your DNSSEC-enabled zones are at 
http://dnsviz.net/ and http://dnssec-debugger.verisignlabs.com/.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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

Bind 9.9rc2 notification gone wild

[Spain, Dr. Jeffry A.]

>> I can install bind 9.9.0rc2 tomorrow and test with both nsupdate and 
>> rndc reload. I would also like to test DNSSEC automatic key rollover 
>> with inline signing again. I imagine this will be fixed in rc2, given 
>> the success of the patch you provided earlier. My next ZSK activation 
>> date is 3/10/2012 with inactivation of the previous key on 3/11 and deletion 
>> on 4/15. I will move those dates up 5 weeks on one of the zones in the 
>> hope of getting test results sooner, although ultimately the timing 
>> depends on individual signature expiration dates.

> Thank you.  9.9.0rc2 is now available to BIND Forum members for initial 
> testing before we roll it out to the public tomorrow.

I created a comedy of errors modifying the key metadata for the test described 
above. Bind's behavior in the face of this may or may not be something you want 
to address in the run-up to the bind 9.9.0 release, but I think it does also 
demonstrate that the problem with expired signatures in inline-signed zones in 
9.9.0rc1 has been fixed. Here's what happened.

I made metadata changes to two keys using dnssec-settime yesterday morning. 
Yesterday evening, as previously posted, I discovered that bind couldn't read 
the private key files due to the mode change to 0600 made by dnssec-settime. 
The syslog contained a series of helpful messages in this regard:

Jan 31 11:52:52 nstest named[845]: dns_dnssec_keylistfromrdataset: error 
reading private key file jaspain.us/RSASHA1/55158: permission denied
Jan 31 11:52:52 nstest named[845]: dns_dnssec_keylistfromrdataset: error 
reading private key file jaspain.us/RSASHA1/30795: permission denied
Jan 31 11:52:52 nstest named[845]: dns_dnssec_findmatchingkeys: error reading 
key file Kjaspain.us.+005+55158.private: permission denied
Jan 31 11:52:52 nstest named[845]: dns_dnssec_findmatchingkeys: error reading 
key file Kjaspain.us.+005+30795.private: permission denied

These were repeated hourly with each "next key event". Yesterday evening I 
fixed the permissions on the private keys and a new series of errors began to 
appear. It turns out that by mistake I had set the currently active key (55158) 
to become inactive 24 hours before its published successor (30795) was due to 
be made active. This resulted in the following series of log messages, also 
very helpful and informative:

Feb  1 06:19:17 nstest named[845]: zone jaspain.us/IN (signed): Key 
jaspain.us/RSASHA1/55158 missing or inactive and has no replacement: retaining 
signatures.
Feb  1 06:19:17 nstest named[845]: zone jaspain.us/IN (signed): sending 
notifies (serial 201512)
Feb  1 06:19:52  named[845]: last message repeated 7 times
Feb  1 06:20:53  named[845]: last message repeated 12 times
Feb  1 06:21:53  named[845]: last message repeated 12 times
Feb  1 06:22:53  named[845]: last message repeated 12 times
... and many more such.

Apparently bind found the need to update some signatures on the signed zone 
jaspain.us but could not do so without an active ZSK. Despite its inability to 
update the signed zone and despite no increment in the serial number, it 
started sending notifies to its slave server every five seconds. Looking at the 
slave server logs confirms this, with entries like the following being present 
every five seconds:

Feb  1 06:19:52 nstest2 named[735]: client 
2001:4870:20ca:158:4423:f19d:4ead:5c20#29061/key nstest-nstest2.countryday.net: 
received notify for zone 'jaspain.us': TSIG 'nstest-nstest2.countryday.net'
Feb  1 06:19:52 nstest2 named[735]: zone jaspain.us/IN: notify from 
2001:4870:20ca:158:4423:f19d:4ead:5c20#29061: zone is up to date

When I observed this behavior this morning, I corrected the key metadata making 
ZSK 30795 active at 8:30 a.m. Almost immediately afterwards the master server 
made some modifications to the signed zone, incremented its serial number, sent 
another notify, and transferred the zone:

Feb  1 08:30:03 nstest named[845]: zone jaspain.us/IN (signed): sending 
notifies (serial 201513)
Feb  1 08:30:03 nstest named[845]: client 
2001:4870:20ca:9:1890:f431:72c9:caaf#37863/key nstest-nstest2.countryday.net 
(jaspain.us): transfer of 'jaspain.us/IN': IXFR started: TSIG 
nstest-nstest2.countryday.net
Feb  1 08:30:03 nstest named[845]: client 
2001:4870:20ca:9:1890:f431:72c9:caaf#37863/key nstest-nstest2.countryday.net 
(jaspain.us): transfer of 'jaspain.us/IN': IXFR ended

The slave's log also shows that this transfer was successful:

Feb  1 08:30:03 nstest2 named[735]: client 
2001:4870:20ca:158:4423:f19d:4ead:5c20#32186/key nstest-nstest2.countryday.net: 
received notify for zone 'jaspain.us': TSIG 'nstest-nstest2.countryday.net'
Feb  1 08:30:03 nstest2 named[735]: zone jaspain.us/IN: Transfer started.
Feb  1 08:30:03 nstest2 named[735]: transfer of 'jaspain.us/IN' from 
2001:4870:20ca:158:4423:f19d:4ead:5c20#53: connected using 
2001:4870:20ca:9:1890:f431:72c9:caaf#37863
Feb  1 08:30:03 nstest2 named[735]: zone jaspain.us/IN: transferred serial

RE: Permissions change after running dnssec-settime bind 9.9.0rc2

[Spain, Dr. Jeffry A.]

>> Now the private key is inaccessible to the named process, which is 
>> running as user bind. User bind is a member of group bind.

> Any time a private key file is rewritten, the mode is changed to 600.
> There's no rule that it has to be owned by root, though; could you just chown 
> it to user bind?

>> Aside from this, is the permissions change made by dnssec-settime a 
>> feature or a bug?

> I consider it a feature, though opinions may vary.

After a more careful review of Bv9ARM.pdf, this behavior is documented on p. 
150 in the "Description" section of dnssec-settime: "The private file's 
permissions are always set to be inaccessible to anyone other than the owner 
(mode 0600)." In light of some of the other responses to your post, perhaps it 
would be useful to give this statement greater emphasis typographically in the 
ARM, e.g. a "Note" box. You might also consider adding the following statement: 
"We therefore recommend that the owner of all key files be set using the 
chown utility to the same UID as that under which the named 
process is running (see named -u in section B.11)." This 
issue also merits a comment in section 7.2.2 "Using the setuid Function" on 
page 116. A second and third sentence might read: "Use the 
chown utility to set the user id of all DNSSEC key files, as 
these must be readable by BIND. Note that the mode of 
private ke
 y files will be set to 0600 by dnssec-settime (section 
B.7)."

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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

Permissions change after running dnssec-settime bind 9.9.0rc2

[Spain, Dr. Jeffry A.]

I ran dnssec-settime from bind 9.9.0rc2 today to change the metadata on two of 
my ZSKs. Before running dnssec-settime, using one of these keys as an example, 
the file permissions were:

-rw-r--r-- 1 root bind   535 2012-01-31 11:47 Kjaspain.us.+005+30795.key
-rw-r- 1 root bind  1058 2012-01-31 11:47 Kjaspain.us.+005+30795.private

Afterwards the permissions on the private key were changed by dnssec-settime to:

-rw-r--r-- 1 root bind   535 2012-01-31 11:47 Kjaspain.us.+005+30795.key
-rw--- 1 root bind  1058 2012-01-31 11:47 Kjaspain.us.+005+30795.private

Now the private key is inaccessible to the named process, which is running as 
user bind. User bind is a member of group bind.

What do you recommend as a best practice? I could do "chmod 640" on any private 
keys modified by dnssec-time to fix this, or I could probably do "chown 
bind:bind" on all the keys and not have to worry about it. Aside from this, is 
the permissions change made by dnssec-settime a feature or a bug?

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: bind9.9.0rc2 inline signing tests

[Spain, Dr. Jeffry A.]

> Hostnames can't begin with a hyphen (RFC 952).  Domain names can start with 
> anything.

I guess that makes the syntax "rndc sync [-clean] [zone [class [view]]]" 
unavoidably ambiguous. Maybe a way around this would be a new command "rndc 
clean [zone [class [view]]]".

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: bind9.9.0rc2 inline signing tests

[Spain, Dr. Jeffry A.]

>> 2. Prior to the second test, in an attempt to get rid of the journal 
>> files, I issued the command "rndc sync -clear jaspain.net". This 
>> generated an error "rndc: 'sync' failed: unknown class/type. I found 
>> that "rndc sync" and "rndc sync jaspain.net" both worked, so I think 
>> rndc just doesn't recognize the -clear parameter as described in the 
>> rndc usage message. With the journal files still present, I decided to 
>> use "rndc freeze jaspain.net" prior to the next test.

> It's supposed to be rndc sync -clean, not -clear.  I thought we'd fixed that, 
> darn it...

Also, for consideration along with a fix to the usage message, it would be more 
clear if the error message error "rndc: 'sync' failed: unknown class/type" 
could be changed to something like "rndc: 'sync' failed: unknown option 
-clear". Apparently, using the above example, rndc's parameter parser regards 
"-clear" as the zone name and "jaspain.net" as the class name. As I read RFC 
1035, domain names can't begin with a hyphen, so rndc should in theory be able 
to correctly discern this error.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School


___
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: bind9.9.0rc2 inline signing tests

[Spain, Dr. Jeffry A.]

> It's supposed to be rndc sync -clean, not -clear.  I thought we'd fixed that, 
> darn it...

Thanks. "rndc sync -clean jaspain.net" works and does remove the journal files. 
Jeff
___
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

bind9.9.0rc2 inline signing tests

[Spain, Dr. Jeffry A.]

I compiled and installed bind 9.9.0 rc2 on Ubuntu Oneiric x64. The zone 
jaspain.net used for testing was configured as a master zone with update-policy 
local, auto-dnssec maintain, and inline-signing yes. I tested by making changes 
to the unsigned zone, and used named-checkzone to output the unsigned and 
signed zone files before and after each change.

1. In the first test I used nsupdate -l to add an A record to the unsigned 
zone. Nsupdate added the record and incremented the serial number of the 
unsigned zone. The signed zone was updated appropriately including a serial 
number increment, resignature of the SOA, addition of the new A record, signing 
of the new A record, and addition/modification/signing of NSEC records. This is 
consistent with the results with bind 9.9.0rc1.

2. Prior to the second test, in an attempt to get rid of the journal files, I 
issued the command "rndc sync -clear jaspain.net". This generated an error 
"rndc: 'sync' failed: unknown class/type. I found that "rndc sync" and "rndc 
sync jaspain.net" both worked, so I think rndc just doesn't recognize the 
-clear parameter as described in the rndc usage message. With the journal files 
still present, I decided to use "rndc freeze jaspain.net" prior to the next 
test.

3. With the zone frozen, I manually edited the unsigned zone file, and my only 
change was to increment the SOA serial number. I then issued the command "rndc 
reload". In the interest of saving time, I issued "rndc sync" to merge the 
journal file into the signed zone file. The unsigned zone file was unchanged 
after the reload. The signed zone file had its serial number incremented and 
the SOA record was resigned. I believe this demonstrates that the issue 
described in the thread "bind 9.9 & inline-signing issue.." for bind 9.9.0rc1 
has been fixed in rc2.

4. Finally with regard to ZSK rollover testing, my zone jaspain.us has several 
RRSIGS that will be expiring on February 8. Currently ZSKs 30795 and 55158 are 
published, and 55158 is active. I am altering the metadata so that ZSK 30795 
goes active on February 1, and 55158 goes inactive on February 2. By February 
9, it should be apparent whether or not the inline-signing-related key rollover 
problem, for which you previously sent me an rc1 patch, has stayed fixed in rc2.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: bind 9.9 & inline-signing issue..

[Spain, Dr. Jeffry A.]

> I suspect that something was wrong with the unsigned zone, 'rndc reload' 
> failed to catch the problem, and so the zone got itself into a weird state. 
> The exact circumstance in which I've seen this happen involved a failure to 
> update the SOA serial, but there may be other triggers for it as well. Having 
> 'rndc reload' behave correctly *should* prevent this sort of problem from 
> repeating itself in the future.

In my scenario, where inline signing is in operation and I am using nsupdate to 
modify the unsigned zone files, the serial numbers of the unsigned zones are 
always incremented by nsupdate. According to your description this would 
prevent the zone file "weird state" issue, and indeed I have never seen a 
problem with my signed zones being properly updated.

> Our current plan is to roll a BIND 9.9.0rc2 release that includes this fix; 
> it should be available by tomorrow.  We'd love it if as many people as 
> possible tested this, particularly the inline-signing features.  If you're 
> participating in this thread we'd like your input.  The target date for final 
> release is quite soon, so the more testing we can get in the next few days, 
> the better.

I can install bind 9.9.0rc2 tomorrow and test with both nsupdate and rndc 
reload. I would also like to test DNSSEC automatic key rollover with inline 
signing again. I imagine this will be fixed in rc2, given the success of the 
patch you provided earlier. My next ZSK activation date is 3/10/2012 with 
inactivation of the previous key on 3/11 and deletion on 4/15. I will move 
those dates up 5 weeks on one of the zones in the hope of getting test results 
sooner, although ultimately the timing depends on individual signature 
expiration dates.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: bind 9.9 & inline-signing issue..

[Spain, Dr. Jeffry A.]

> After setting up a zone with DNSSEC using inline-signing, I have run into the 
> issue where if I do anything that updates the unsigned file that is input 
> into BIND, that it never seems to update the signed data it generated.

> As an example, I had serial number of 2012012701 in the test zone file, and 
> when I started named up it happily created the signed zone.   So then I went 
> in and changed this serial to 2012012801, and performed an 'rndc reload' and 
> nothing, it saw the updated unsigned zone, but never kicked off an event to 
> resign the signed data it was dishing out when asked, so the changes were
not available.

I have been using inline signing successfully, but am using a different method 
to make changes to the unsigned data. My zone configuration contains 
"update-policy local;" and I have been using "nsupdate -l" to make changes to 
the unsigned zone. Nsupdate automatically increments the serial number on the 
SOA record in the unsigned zone. The signed zone typically has a different and 
higher serial number due to signing activity that occurs automatically, e.g. 
resigning a record with an expired signature.

With regard to "rndc reload" not working for you, see 
https://lists.isc.org/pipermail/bind-users/2011-November/085739.html. Per that 
message, try "rndc reload leadmon.org". Also verify that the UID under which 
the named process is running is the owner of the various zone data and journal 
files.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Extracting key tag from DNSKEY

[Spain, Dr. Jeffry A.]

> Can I extract the key tag from a DNSKEY, obtained via dig?

Try the following:
dig @bind.odvr.dns-oarc.net. isc.org dnskey +multiline

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: 9.9.0rc1: example from arm 4.8.3 does not validate

[Spain, Dr. Jeffry A.]

> I tried the example from page 23 with a local zone, a trusted key and 
> inline-signing, ...
> But I'm getting no ad-flag

I think that is expected behavior when you query an authoritative server 
directly. For example, our authoritative server:
dig @ns1.countryday.net countryday.net dnskey +dnssec
also returns no ad flag, but if you run the same query from a DNSSEC-enabled 
recursive resolver, you will get an ad flag.

Regards, Jeff
 
Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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

bind9.9.0rc1 DNSSEC key rollover failure

[Spain, Dr. Jeffry A.]

A couple of weeks ago I found a DNSSEC key rollover problem with bind 9.9.0b2. 
See https://lists.isc.org/pipermail/bind-users/2011-December/086063.html. This 
appears to have persisted after upgrading to bind 9.9.0rc1 this afternoon.

See http://dnsviz.net/d/jaspain.net/dnssec/. The RRSIGs on the jaspain.net 
, A, and TXT RRSets signed by ZSK 35297 expired on 12/17/2011, and those 
RRSets have not been resigned with the new ZSK 42152.

The metadata for ZSK 35297 calls for it to have become inactive on 12/12/2011 
(at zero hours UTC) and for it to be deleted on 1/16/2012. The metadata for the 
new ZSK 42152 calls for it to have been published on 9/8/2011 and activated on 
12/11/2011. The jaspain.net SOA RRSet was signed by ZSK 35297 on 12/10/2011 and 
by ZSK 42152 at the same time. Following today's upgrade to RC1 the signature 
by ZSK 35297 on the SOA RRSet was removed.

As I understand it, bind should be resigning RRSets automatically to prevent 
such signature expirations.

This particular zone is configured for in-line signing from a locally stored 
copy of the unsigned zone:

zone "jaspain.net" {
type master;
file "/var/lib/bind/jaspain.net/jaspain.net.db";
key-directory "/var/lib/bind/jaspain.net";
update-policy local;
auto-dnssec maintain;
inline-signing yes;
also-notify { 2001:4870:20ca:158:14ff:7695:9632:e9ec; };
};

Thanks for any ideas you may have about what has gone wrong.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Take your DNSSEC with a grain of salt ...

[Spain, Dr. Jeffry A.]

> I've taken some time to write down my knowledge on NSEC3 use of the "salt" 
> and "iteration" parameters:
> 

Thanks, Carsten. This is a very clear, concise, and informative article.

Given the recommendation to change NSEC3 salt values with each ZSK rollover, I 
would like to make the following suggestion for bind9 and bind10. Enhance bind9 
dnssec-keygen (and whatever the equivalent turns out to be for bind10) to 
include a random or specified salt as part of the key metadata. When the key 
activation date/time is reached for NSEC3 zones, automatically modify the 
NSEC3PARAM record and regenerate the NSEC3 chain with the new salt value.

Happy New Year to all. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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 key rollover problems

[Spain, Dr. Jeffry A.]

This issue relates to the server nstest.jaspain.net (74.203.156.157), which is 
running bind 9.9.0b2. Please refer to http://dnsviz.net/d/jaspain.net/dnssec/. 
The RRSIGs on the jaspain.net , A, and TXT RRSets signed by ZSK 35297 
expired on 12/17/2011, and those RRSets have not been resigned with the new ZSK 
42152.

The metadata for ZSK 35297 calls for it to have become inactive on 12/12/2011 
(at zero hours UTC) and for it to be deleted on 1/16/2012. The metadata for the 
new ZSK 42152 calls for it to have been published on 9/8/2011 and activated on 
12/11/2011. The jaspain.net SOA RRSet was signed by ZSK 35297 on 12/10/2011 and 
by ZSK 42152 at the same time.

First of all is it correct that the time stamps shown by dig for RRSIG records 
are in local time? Otherwise, if the time stamps show UTC, then the RRSIG for 
jaspain.net SOA for ZSK 42152 was generated at 2011121023, one hour prior 
to that key's activation.

Second, can you offer an explanation as to why ZSK 42152 has not been used to 
sign the jaspain.net , A, and TXT RRSets when that key is published, 
activated, and has been used to sign the SOA RRSet, and the existing signatures 
by ZSK 35297 have expired?

For the sake of comparison, see http://dnsviz.net/d/countryday.net/dnssec/. 
This zone, which is served by bind9.8.1-P1, seems to have negotiated the ZSK 
rollover successfully with the same set of dates in the key metadata... so far 
at least.

Thanks for your thoughts on this. Happy New Year to all.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School


___
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-keygen not responding

[Spain, Dr. Jeffry A.]

> I'd be rather wary of keys made from /dev/urandom but I am often times a 
> paranoid security freak.

Inexpensive USB-attachable RNG: http://www.entropykey.co.uk/

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
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: Bind 9.9.0b2 inline signing...

[Spain, Dr. Jeffry A.]

> > > I don't understand why Windows doesn't include dig by default, even now.  
> > > Free software hate?

> > And grep and logrotate!  At least the GnuWin32 project has a good  version 
> > of grep.

> I think that if I had to use a Windows workstation my first installs would be 
> the ISC binary kit and wireshark, since AFAIK Windows doesn't come with a 
> packet capture program either. . .

Bill: Microsoft Network Monitor 3.4 is available. See 
http://support.microsoft.com/kb/933741. I do prefer Wireshark myself.

Windows PowerShell offers similar functionality to grep in the Select-String 
cmdlet. See http://technet.microsoft.com/en-us/library/dd315403.aspx. This goes 
somewhat against the object-oriented grain of PowerShell, however.

The Windows event viewer can be configured to archive event logs when they 
reach a certain size, but I don't think this matches the functionality of 
logrotate.

Jeff.

___
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: Configuration RPZ using BIND RPM package

[Spain, Dr. Jeffry A.]

> Is it possible in configure RPZ by download Bind.tar.gz file from isc 
> website. if yes, do i need to remove completely all running configuration 
> including /etc/named.rfc1912.zones and /etc/named.caching-nameserver.conf 
> files? Kindly suggest. Regards Babu

Babu: While I am an Ubuntu user, I will speculate that the situation with 
Redhat would be similar. I examined the standard Ubuntu bind package and wrote 
a short bash script to download, compile, and install a bind tarball of choice. 
The script starts by removing all existing bind-related packages. There are 
some extra directories that you have to create and some extra files you have to 
install to make it all work. If you extract and examine your bind RPM, you 
should find all the files you need, including zones.rfc1918. You can probably 
reuse your configuration files after reviewing them for any required changes 
relating to the newer version of bind and the RPZ functionality you want to 
add. I'll send you a copy of my installation script if that would be helpful. 
Regards, Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School
 

___
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: Exercising RFC 5011 rollovers

[Spain, Dr. Jeffry A.]

> There are tools for this.  E.g. libfaketime

Looks like libfaketime (http://www.code-wizards.com/projects/libfaketime/) lets 
you accelerate the system time. Adapting one of their examples: 
LD_PRELOAD=./libfaketime.so.1 FAKETIME="x5000" /bin/bash -c 'while true; do 
echo $SECONDS ; sleep 43200 ; done'. This should make time pass at a rate of 
one day every 17 seconds and a month in 9 minutes.
___
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