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.]

 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.]

 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:
; EDNS: version: 0, flags: do; udp: 4000
;; QUESTION SECTION:

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:
comcast.com.3583IN  SOA 

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

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: 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: 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.]

 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 path to key files; 
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: 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: 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 zone/IN:
 Key zone/algorithm/key tag 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 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 zone/IN: Key zone/algorithm/key tag 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

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 zone/algorithm/hey tag 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 zone and for good measure rndc 
sign zone, 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 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

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 zone 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 zone 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: 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: 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: 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: 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.the first octet 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: 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: 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: 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.]

 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: 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.]

 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.]

 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.]

 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: 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.]

 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=2start=0num=100q=colspec=ID%20Status%20Stars%20Priority%20Owner%20Reporter%20Summarygroupby=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.]

 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: 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=postst=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: 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=2start=0num=100q=colspec=ID%20Status%20Stars%20Priority%20Owner%20Reporter%20Summarygroupby=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: 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 {
ip address of slave 1;
ip address of slave 2;
...
};

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: 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

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: 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

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: 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.]

 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 
root. 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.]

 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.]

 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.]

 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

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

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

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

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 base64 key;
};

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

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

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: 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

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: 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.]

 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.]

 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: 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: 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: 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: 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: 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

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 { address of 
bind10 hidden master }; and also notify { addresses of bind10 slaves };. 
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: 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: 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 
commandchown/command utility to the same UID as that under which the named 
process is running (see commandnamed -u/command 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 
commandchown/command utility to set the user id of all DNSSEC key files, as 
these must be readable by acronymBIND/acronym. Note that the mode of 
private ke
 y files will be set to 0600 by commanddnssec-settime/command (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

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

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: 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

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.]

 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

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: 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:
 http://strotmann.de/roller/dnsworkshop/entry/take_your_dnssec_with_a

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: 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

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.]

 Does anyone provide a zone with a trust anchor that is frequently rolled
over in that way, just so that one can see whether it really works? Then
one's feelings might be warmer and less fuzzy...

I looked at the DNSSEC section of the bind test suite 
(bind-9.9.0b2/bin/tests/system/dnssec) to see if a key rollover test is part of 
it. I didn't see that, but it may be elsewhere, as the test suite is pretty 
elaborate. The test suite does contain a simulated root server (ns1), so I bet 
that with a little ingenuity you could devise a key rollover test.
___
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.]

 dig axfr dotat.at | grep -v RRSIG. Tony.
 dig axfr dotat.at | grep -v RRSIG | grep -v TYPE65534 | grep -v DNSKEY | grep 
 -v NSEC3PARAM. JP.
 dig axfr zone | awk '$4 !~ ^NSEC$|^NSEC3$|^RRSIG$ {print}'. Shumon.

Thank you, gentlemen. These are very helpful. As we are primarily Windows 
users, I have had a tendency to dig axfr from my Windows workstation and remove 
the DNSSEC-related records with a regular expression search in my text editor. 
I really should take the time to learn more about grep and awk. Happy 
Thanksgiving to all. 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.0b2 inline signing...

[Spain, Dr. Jeffry A.]

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

I wonder if it some kind of intellectual property issue. Microsoft has to be 
able to sell Windows and therefore must consider any added costs related to 
including a component that they do not own and would have to license. I suppose 
they could develop a similar application themselves, but I think they tend to 
focus more on end-user rather than administrative functionality in their 
development efforts.

This is certainly not Microsoft's only issue with DNS. They have pretty much 
developed their own DNS ecosystem over the years, starting with Active 
Directory for Windows 2000, and they have not kept up with the functionality in 
bind. For example, the current iteration of Microsoft DNS in Windows Server 
2008 R2 has a faulty implementation of DNSSEC -- you can't enter the root zone 
trust anchor. I have set up my Windows domain controllers (DNS servers) to 
forward to a DNSSEC-enabled bind recursive resolver. Even that turned out to be 
a challenge because of the way Windows uses the CD and DO flags in DNS queries. 
Supposedly DNS in Windows 8 server is going to fix these issues. We shall see. 
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.0b2 inline signing...

[Spain, Dr. Jeffry A.]

Evan: I'd like to ask for clarification. My understanding is that 
inline-signing yes: is necessary to cause bind to keep separate signed and 
unsigned zone files, and that the source of the unsigned zone file can be a 
disk file in the case of a master, or a zone transfer in the case of a slave. I 
further understand that update-policy local; is necessary to allow the use of 
nsupdate on the local machine to operate on the applicable master zone. 
Therefore if you want to use nsupdate locally and have separate signed and 
unsigned master zone files, you need both of the above statements in the zone 
configuration. Would you please comment on any misunderstanding on my part 
about this.

By the way, I think there is a typo on page 99 of Bv9ARM.pdf: For 
inline-signing inline-signing, read inline-signing.

Thanks. Jeff.

-Original Message-
From: bind-users-bounces+spainj=countryday@lists.isc.org 
[mailto:bind-users-bounces+spainj=countryday@lists.isc.org] On Behalf Of 
Evan Hunt
Sent: Wednesday, November 23, 2011 12:01 PM
To: Jan-Piet Mens
Cc: bind-users@lists.isc.org
Subject: Re: Bind 9.9.0b2 inline signing...

  I did something similar, using nsupdate to modify the unsigned zone 
  instead of a manual edit. [...]  rndc reload is not necessary.
 
 `rndc reload' never is necessary if you use DDNS to update master zones.

True, but in that situation 'inline-signing' isn't necessary either.  

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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
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.]

 Now, you can *also* turn on DDNS and use nsupdate on an inline-signing 
 zone...  but, if you're going to be using DDNS anyway, then I'm unclear what 
 operational need is being served by separating the data.  With or without 
 inline-singing, your master file will be overwritten, and you'll have to 
 concern yourself with freezing and thawing... and *with* inline-signing, 
 there are more moving parts.  So, I'd probably just use DDNS, turn off 
 inline-signing, and let the zone take care of itself.

Thank you for your detailed response, Evan. Here's my operational plan. First 
of all we are a small organization with a few DNS zones that we manage for 
ourselves. I have also grown accustomed to using nsupdate -- the changes to the 
zone files are few and infrequent. From time to time I want to review the 
current state of the zone files. I have been accustomed with v9.8 to taking a 
copy of a signed zone file and stripping out the DNSSEC-related records in a 
text editor for easy review. I have been using dnsviz.net to verify 
periodically that DNSSEC is operating properly. Now in v9.9, I can eliminate 
this somewhat tedious step with my text editor because with inline signing, 
there is always an unsigned zone file available to me. If I am in a hurry to do 
my review after making an update, I can use rndc sync myzone. Similarly in my 
nightly backup cron job, I can now backup both the signed and unsigned zone 
files after rndc freeze myzone to make sure they have incorporated th
 e latest changes. I'm assuming that rndc freeze myzone freezes both the 
signed and unsigned zone files. I'm not worried about the freezing and thawing 
-- my cron job has been doing that with v9.8 with no apparent problems. I am 
also not worried about the increased number of moving parts -- I think it is 
reasonable to rely upon ISC to get this all working correctly. In v9.9.0b2, 
there is a problem with rndc freeze (reported earlier as [ISC-Bugs #26632]) 
so I will continue to test this with subsequent versions. Thanks again. 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

socket.c error in bind 9.9.0b2

[Spain, Dr. Jeffry A.]

When bind 9.9.0b2 starts up, the syslog shows the following messages:

Nov 22 10:18:19 nstest2 named[17190]: using default UDP/IPv6 port range: [1024, 
65535]
Nov 22 10:18:19 nstest2 named[17190]: listening on IPv6 interfaces, port 53
Nov 22 10:18:19 nstest2 named[17190]: socket.c:5728: unexpected error:
Nov 22 10:18:19 nstest2 named[17190]: setsockopt(513, IPV6_V6ONLY) failed: 
Invalid argument

The section of bind-9.9.0b2/lib/isc/unix/socket.c referenced in the error 
message is:
#ifdef IPV6_V6ONLY
if (sock-pf == AF_INET6) {
if (setsockopt(sock-fd, IPPROTO_IPV6, IPV6_V6ONLY,
   (void *)onoff, sizeof(int))  0) {
char strbuf[ISC_STRERRORSIZE];
isc__strerror(errno, strbuf, sizeof(strbuf));
UNEXPECTED_ERROR(__FILE__, __LINE__,
 setsockopt(%d, IPV6_V6ONLY) 
 %s: %s, sock-fd,
 isc_msgcat_get(isc_msgcat,
ISC_MSGSET_GENERAL,
ISC_MSG_FAILED,
failed),
 strbuf);
}
}
FIX_IPV6_RECVPKTINFO(sock); /* AIX */
#endif

I have reproduced this on Ubuntu 11.04 (Natty) and 11.10 (Oneiric) amd64. The 
error does not occur with bind 9.8.1-P1. This same section of code appears in 
bind-9.8.0-P1/lib/isc/unix/socket.c and is identical to the above. My systems 
are operating in an IPv6/IPv4 dual-stack environment. The configuration file 
named.conf.options contains listen-on-v6 { any; };. These systems seem to 
respond normally to IPv6 queries. Thanks for any advice you may have about how 
to troubleshoot further. 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: Bind 9.9.0b2 inline signing...

[Spain, Dr. Jeffry A.]

Kevin: I did something similar, using nsupdate to modify the unsigned zone 
instead of a manual edit. The myzone.db, myzone.db.jnl, myzone.db.signed, and 
myzone.db.signed.jnl files all get updated appropriately. rndc reload is not 
necessary. It is interesting to note that the serial number in the signed zone 
gets incremented more than the serial number in the unsigned zone. A dig 
request for the SOA record returns the serial number from the signed zone.

To allow for this I have the following in my configuration file:

zone myzone {
type master;
file /var/lib/bind/myzone/myzone.db;
key-directory /var/lib/bind/myzone;
update-policy local;
auto-dnssec maintain;
inline-signing yes;
};

I'll give it a try with a manual edit and let you know. Jeff.

From: bind-users-bounces+spainj=countryday@lists.isc.org 
[mailto:bind-users-bounces+spainj=countryday@lists.isc.org] On Behalf Of 
McConville, Kevin
Sent: Tuesday, November 22, 2011 11:58 AM
To: bind-users@lists.isc.org
Subject: Bind 9.9.0b2 inline signing...

I have opened up a Bug ticket with ISC on this - #26676, but I just wanted to 
make sure that I'm not doing anything wrong that may be causing the issue.

Has anyone been able to get inline-signing to work on a static master zone 
using an authoritative server?

When we manually change the Master static zone file - ualbanytest.org - the 
signed and signed.jnl files are not getting an update - as shown by the 
time/date stamps below (just using rndc reload).

-rw-rw-r-- 1 named root   1077 Nov 22 11:22 ualbanytest.org
-rw--- 1 named named  9415 Nov 22 11:14 ualbanytest.org.signed
-rw--- 1 named named 12041 Nov 22 11:02 ualbanytest.org.signed.jnl

The log shows the correct serial for the unsigned zone, but then pulls the 
wrong signed file.

22-Nov-2011 11:25:28.314 general: info: received control channel command 
'reload'
22-Nov-2011 11:25:28.314 general: info: loading configuration from 
'/etc/named.conf'
22-Nov-2011 11:25:28.315 general: info: using default UDP/IPv4 port range: 
[1024, 65535]
22-Nov-2011 11:25:28.315 general: info: using default UDP/IPv6 port range: 
[1024, 65535]
22-Nov-2011 11:25:28.316 general: info: sizing zone task pool based on 4 zones
22-Nov-2011 11:25:28.318 general: info: zone ualbanytest.org/IN (signed): 
(master) removed
22-Nov-2011 11:25:28.318 general: info: reloading configuration succeeded
22-Nov-2011 11:25:28.318 general: info: reloading zones succeeded
22-Nov-2011 11:25:28.320 general: info: zone ualbanytest.org/IN (unsigned): 
loaded serial 202201
22-Nov-2011 11:25:28.320 general: info: zone ualbanytest.org/IN (signed): 
loaded serial 202114 (DNSSEC signed)
22-Nov-2011 11:25:28.320 general: notice: all zones loaded
22-Nov-2011 11:25:28.320 general: notice: running
22-Nov-2011 11:25:28.320 general: info: zone ualbanytest.org/IN (signed): 
reconfiguring zone keys
22-Nov-2011 11:25:28.321 general: info: zone ualbanytest.org/IN (signed): next 
key event: 22-Nov-2011 11:35:28.321
22-Nov-2011 11:25:28.321 notify: info: zone ualbanytest.org/IN (signed): 
sending notifies (serial 202114)


From Named.conf:


options {
directory   /conf;
pid-file/var/run/named.pid;
statistics-file /var/run/named.stats;
dump-file   /var/run/named.db;
version [secured];
dnssec-enable yes;
sig-validity-interval 10;
dnssec-loadkeys-interval 10;
empty-zones-enable no;
};

# DNSSEC Zone
zone ualbanytest.org {
 type master;
 file ualbanytest.org;
 auto-dnssec maintain;
 inline-signing yes;
 key-directory /conf;
 serial-update-method increment;
};



Has anyone gotten this to work on an authoritative (meaning that I am missing 
something) or is it a real bug? I just don't want to be claiming it's a bug 
if it's something that I messed up or fat fingered :)

Thanks you all in advance.

Thanks,

-Kevin


Kevin McConville

University at Albany


___
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: RPZ configuration examples

[Spain, Dr. Jeffry A.]

 1. Do you have  basic example/steps to configure RPZ in Bind? ( I need couple 
 of examples like /etc/named.conf file and zone files for rpz
 2. If I use RPZ, recursive DNS will contact remote RBL database for every DNS 
 query?
 3. Is it possible to download DNS RBLs locally on the DNS server 
 automatically daily and then allow RPZ query locally to give malware domain 
 lookup response?

Here's a technical note with some configuration examples: 
http://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt. As I understand it, when you 
configure a response policy zone on your recursive resolver, your resolver uses 
the master-slave mechanism to get a copy of the response policy zone file from 
your RPZ provider. It keeps that copy updated based on notify messages and 
incremental transfers from the RPZ provider. For each query, your resolver 
consults your local copy of the RPZ or your cache as part of the recursive 
resolution process. ISC had a webinar on RPZ. See 
http://www.isc.org/files/imce/DNSRPZ-2011-03-01-Webinar.pdf. In it they 
mentioned http://www.surbl.org/ as an RPZ data provider. I worked with RPZ 
several months ago and had difficulty determining how well it was working. What 
was lacking at the time was a test domain name or set of such names guaranteed 
to be in the RPZ data that would generate an NXDOMAIN response. Would you 
please post information about your experiences as you proceed with your RPZ 
project. 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: Puzzeling about IPv6

[Spain, Dr. Jeffry A.]

If you are concerned about a repeat of the IPv4 address exhaustion problem, 
this is a different issue. The 64-bit IPv6 interface identifier has to be 
unique for each device on an IPv6 subnet. Even if you choose the IIDs randomly 
for, say, 1000 devices, the probability of a duplicate is very low. There are 
actually 62 bits available, not counting the universal and group bits. The 
probability is 1 - ( 2^62 x 2^62-1 x 2^62-2 x ... x 2^62-999 ) / ((2^62)^1000) 
= 1.08 x 10^-13. See Brithday Problem 
http://en.wikipedia.org/wiki/Birthday_problem.

IPv6 address exhaustion would be related to the remaining 64 bits of the 
address, which identifies the subnet. Ignoring for the moment that not all of 
this is unicast address space, you still have on the order of one subnet per 
square centimeter of the earth's surface. I guess this may become a problem, 
for example, when we are assembling things like houses and cars out of nanobots.

-Original Message-
From: bind-users-bounces+spainj=countryday@lists.isc.org 
[mailto:bind-users-bounces+spainj=countryday@lists.isc.org] On Behalf Of ?? 
??
Sent: Saturday, November 19, 2011 1:48 PM
To: bind-users@lists.isc.org
Subject: Re: Puzzeling about IPv6

 Oh, and given you've got 64bits to play with, so long as your random
 numbers are up to scratch no need to worry about collisions.  You'ld
 need to be assigning millions of addresses before you ran into that problem.

Not to be an ass and this is likely a decade too early, but... this is 
direct echoes of what I heard 20 years ago.

Does systematic thinking belong in /32+ IPv6 addressing or is it in fact 
safe to just random it all away willy-nilly?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

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

9.9.0b1 inline-signing questions

[Spain, Dr. Jeffry A.]

I am testing bind 9.9.0b1 compiled on Ubuntu Oneiric x64 (nstest.jaspain.net). 
I configured a zone as follows:

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

On initial startup, bind created jaspain.net.db.signed and 
jaspain.net.db.signed.jnl. Looking at the latter with named-journalprint, the 
entries appear to be consistent with the zone signing process. I used nsupdate 
-l to create a new A record, and that succeeded. The file jaspain.net.db.jnl 
was created in the process. I attempted to freeze the zone using rndc freeze 
jaspain.net, and this resulted in the error message rndc: 'freeze' failed: 
not dynamic. rndc thaw jaspain.net yielded no messages, but added a syslog 
entry that it was successful. The freeze failure is contrary to what I would 
have expected. Are update-policy local; and inline-signing yes; 
incompatible?

The serial numbers in the SOA records in the various zone-related files are 
different, but I believe they are consistent. In jaspain.net.db, the SOA serial 
number was originally 201501. Looking at jaspain.net.db.signed.jnl, the SOA 
serial number got updated to 201504 as a result of the initial signing 
process. Following the record addition with nsupdate, the SOA serial number in 
jaspain.net.db.jnl was updated to 201502. Twelve minutes later bind rewrote 
jaspain.net.db with this same serial number and the added A record. Immediately 
after the nsupdate, jaspain.net.db.signed.jnl showed the signing activity for 
the new A record and an update of the SOA serial number to 201505. This is 
the serial number that is returned by a dig of the SOA record. The 
named-journalprint output for both jaspain.net.db.jnl and 
jaspain.net.db.signed.jnl starts with the line BITWS=201502. What does that 
mean?

Fourteen minutes after the nsupdate, bind rewrote jaspain.net.db.signed. Is 
there a utility akin to named-journalprint that would display the contents of 
jaspain.net.db.signed in human-readable form?

Thanks for providing this interesting new feature, which I hope to understand 
more fully.

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.0b1 inline-signing questions

[Spain, Dr. Jeffry A.]

Thanks, Evan. Can you also comment about the meaning of BITWS=201502 at 
the beginning of the output of named-journalprint? Jeff.

-Original Message-
From: Evan Hunt [mailto:e...@isc.org] 
Sent: Friday, November 18, 2011 1:59 PM
To: Spain, Dr. Jeffry A.
Cc: bind-users@lists.isc.org
Subject: Re: 9.9.0b1 inline-signing questions

 I attempted to freeze the
 zone using rndc freeze jaspain.net, and this resulted in the error 
 message rndc: 'freeze' failed: not dynamic. rndc thaw jaspain.net
 yielded no messages, but added a syslog entry that it was successful. 
 The freeze failure is contrary to what I would have expected. Are 
 update-policy local; and inline-signing yes; incompatible?

It shouldn't be, that's probably a bug.  Can you open a ticket at 
bind9-b...@isc.org about it?

 Fourteen minutes after the nsupdate, bind rewrote jaspain.net.db.signed.
 Is there a utility akin to named-journalprint that would display the 
 contents of jaspain.net.db.signed in human-readable form?

It's a raw-format zonefile; you can convert it to text using
named-checkzone:

named-checkzone -D -f raw jaspain.net jaspain.net.db.signed

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

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