dns-sec and Maintaining Human Sanity
I have started looking at various ways for our organization to begin using dns-sec as this appears to be a high management priority and it will eventually become necessary to operate. We have a fairly simple structure with a official master and slave with dynamic DHCP continuously updating the zone. The one thing that impresses me about dns-sec is that it appears to be one of those things that will probably work fine after installation but getting there may be an adventure to put it mildly. There is an application called opendns-sec that appears to automate much of the key generation and rollover logic and lets you use basically an unpublished master to handle your zone with opendns-sec being the machine that takes your zone from the master, signs it and is the public master as far as the world is concerned. That is, if one can get the latest version to compile under FreeBSD8.0. So far, the configure process is one dependency after another and I have yet to see it actually finish so that is shades of years gone by when installing software was an art on good days. Opendns-sec makes sense except that you need at least one more real or virtual box to do DNS and that is an issue on small campuses. Is there any sense of the group as to how best to make this problem become an automated non-issue? Here, we only allow trusted individuals and our DHCP servers to have the tsig keys which update our zones so it may make more sense to modify our main configuration but that is why I am asking questions. Half of me understands why this is necessary and the other half just wants to automate, set and forget. We are upgrading all DNS and DHCP servers to FreeBSD8.0 and my plan was to use bind9.6x. If there is a better version for dns-sec, best to plan to use it now in order to sleigh as much of this dragon which is breathing fire on the edge of town and threatens to move in soon. The only thing set in stone right now is that we need to get on the dns-sec band wagon. I am just trying to install steps that don't break our legs as we climb up. Many thanks. Martin McCormick ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: dns-sec and Maintaining Human Sanity
I'm running 9.6 in our lab environment with DNSSEC enabled, not much difficulty at all. To make it even easier, you might want to look at the Webmin BIND module. It makes it even easier. shameless plugAlso, I went to ISC's BIND deployment workshop and found it very insightful. /shameless plug Brian -Original Message- From: bind-users-bounces+brian.atkins2=va@lists.isc.org [mailto:bind-users-bounces+brian.atkins2=va@lists.isc.org] On Behalf Of Martin McCormick Sent: Friday, August 06, 2010 7:24 AM To: bind-us...@isc.org Subject: dns-sec and Maintaining Human Sanity I have started looking at various ways for our organization to begin using dns-sec as this appears to be a high management priority and it will eventually become necessary to operate. We have a fairly simple structure with a official master and slave with dynamic DHCP continuously updating the zone. The one thing that impresses me about dns-sec is that it appears to be one of those things that will probably work fine after installation but getting there may be an adventure to put it mildly. There is an application called opendns-sec that appears to automate much of the key generation and rollover logic and lets you use basically an unpublished master to handle your zone with opendns-sec being the machine that takes your zone from the master, signs it and is the public master as far as the world is concerned. That is, if one can get the latest version to compile under FreeBSD8.0. So far, the configure process is one dependency after another and I have yet to see it actually finish so that is shades of years gone by when installing software was an art on good days. Opendns-sec makes sense except that you need at least one more real or virtual box to do DNS and that is an issue on small campuses. Is there any sense of the group as to how best to make this problem become an automated non-issue? Here, we only allow trusted individuals and our DHCP servers to have the tsig keys which update our zones so it may make more sense to modify our main configuration but that is why I am asking questions. Half of me understands why this is necessary and the other half just wants to automate, set and forget. We are upgrading all DNS and DHCP servers to FreeBSD8.0 and my plan was to use bind9.6x. If there is a better version for dns-sec, best to plan to use it now in order to sleigh as much of this dragon which is breathing fire on the edge of town and threatens to move in soon. The only thing set in stone right now is that we need to get on the dns-sec band wagon. I am just trying to install steps that don't break our legs as we climb up. Many thanks. Martin McCormick ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dns-sec and Maintaining Human Sanity
Hi, On 2010-08-06 13:24, Martin McCormick wrote: We are upgrading all DNS and DHCP servers to FreeBSD8.0 and my plan was to use bind9.6x. If there is a better version for dns-sec, best to plan to use it now in order to sleigh as much of this dragon which is breathing fire on the edge of town and threatens to move in soon. Definitely consider the 9.7 series! You can enable auto-dnssec which will maintain your signatures for you out-of-the-box. It also supports key rollover, but IIRC doesn't generate new keys at this moment. see for more details: http://www.isc.org/software/bind/new-features/9.7 http://www.isc.org/community/blog/201006/bind-972-and-and-automatic-dnssec-signing Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dns-sec and Maintaining Human Sanity
That is, if one can get the latest version to compile under FreeBSD8.0. So far, the configure process is one dependency after another and I have yet to see it actually finish so that is shades of years gone by when installing software was an art on good days. Use the port, see /usr/ports/dns/openddnssec. jaap ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dns-sec and Maintaining Human Sanity
Niobos writes: Definitely consider the 9.7 series! You can enable auto-dnssec which will maintain your signatures for you out-of-the-box. It also supports key rollover, but IIRC doesn't generate new keys at this moment. That's not much of a problem. Thanks for reminding me of 9.7. Martin McCormick ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dns-sec and Maintaining Human Sanity
On 06/08/10 12:24, Martin McCormick wrote:
The one thing that impresses me about dns-sec is that it
appears to be one of those things that will probably work fine
after installation but getting there may be an adventure to put
it mildly.
My advice is to investigate upgrading to Bind 9.7 and using the
auto-dnssec maintain option on your zones.
We do something similar to this:
zone example.com {
type master;
# file in a per-zone directory
file data/zones/example.com/zone;
# keys in the same direction
key-directory data/zones/example.com;
# tell bind to do DNSSEC maintenance
auto-dnssec maintain;
# must allow updates for online (re)signing
allow-update { key ...; };
};
...at this point, signing a zone is very simple:
NAME=example.com
ZDIR=/var/named/data/zones/$NAME
# make key-signing key
dnssec-keygen -K $ZDIR -a RSASHA1 -b 2048 -n ZONE -f KSK $NAME
# make zone-signing key
dnssec-keygen -K $ZDIR -s RSASHA1 -b 1024 -n ZONE $NAME
# fixup perms
chgrp named $ZDIR/K*
chmod 640 $ZDIR/K*
# sign it
rndc sign $NAME
Bind will automatically maintain the signatures and re-sign every $SOME
days. When you want to do a key rollover, you can use the timestamp
options to generate a new key which is valid but not used:
# make new zone-signing key
dnssec-keygen -K $ZDIR -P now -A none -s RSASHA1 -b 1024 -n ZONE $NAME
# insert key
rndc sign $NAME
# wait for cache expiry times - see RFCs for details
# roll over keys fixup perms
dnssec-settime -K $ZDIR -A now KtheNEWkeyid chmod 640 $ZDIR/K*
dnssec-settime -K $ZDIR -I now KtheOLDkeyid chmod 640 $ZDIR/K*
# wait $SOME time for the zone to be incrementally
# resigned using the new key, and the old key is redundant,
# and any old RRs have expires from caches
# remove the old key
dnssec-settime -K $ZDIR -D now KtheOLDkeyid
rndc sign $NAME
Obviously there is some care and attention needed, but the above
procedures are very quick to test. Play around with it a bit - I think
you'll be pleasantly surprised how easy the stuff in bind 9.7 is.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Question on query-source, transfer-source, notify-source
In message 20100804184239.4ee3b47...@britaine.cis.anl.gov, Barry Finkel write s: Another question about query-source: Is there a difference between query-source address 1.2.3.4; and query-source 1.2.3.4; No. My reading of the ARM simplies that the two are the same, but I may be getting different results. I am not sure. Two of my colleagues ran a test last week that seemed to imply a difference, but I was not around to see exactly what tests they ran. This is BIND 9.7.1-P2. I have looked at querylogs on a server with one DNS address and one non-DNS address. I have tried both formats of query-source above; I see no difference. What I do see is this - an SOA query via the DNS address followed by an IXFR via the DNS address. This IXFR is REFUSED because this is a test server, and the master server (not under my control) does not allow zone transfers from this test address. Then I see an SOA query and an AXFR query, both on the DNS address. This AXFR is also REFUSED. Then I see an SOA query and an IXFR query via the non-DNS address! I have not looked at the code to see what BIND might be doing in sending a DNS packet via the non-DNS address. The BIND config on this machine has transfer-source 1.2.3.4 port 53; so it should not be sending an IXFR or AXFR request via the non-DNS address. See alt-transfer-source and use-alt-transfer-source. An addendum to my recent postings about two machines each with three addresses. The only reason I need all three addresses on each machine is that I have published all six addresses, and these addresses are configured in all of the machines on the three Class-B subnets that my DNS server manages. I do not want to have all of the system administrators change their machine DNS server IP addresses. -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarding to two servers
Joseph S D Yao wrote:
If you have two forwarders, as you listed, your server will try to
forward first to one and then to the other. If it gets any answer at
all from one - even an error answer - it will not try the other.
So forwarding works exactly the same as listing both servers in
resolv.conf? That behavior is exactly what I'm trying to avoid.
There are many ways to try to cascade name servers and try them one at a
time. By the good design of BIND, none of them work.
If BIND won't do the job, can you suggest another server that will? I
can't be the only one wanting to do something like this.
On your new server:
zone . { type hint; file root.hints; };
zone private.example.com { type forward; forward only;
forwarders { private.domain.server.IP; }; };
and put the IP address for this name server and no other in your
/etc/resolv.conf.
Ah, that might work -- in other circumstances. I understand the basic
idea to be using separate zones to force forwarding to different servers
for different domains. Did I understand correctly?
But an unfortunate characteristic of my PRIV server is that it doesn't
use /any/ domain. It only resolves simple, unqualified names like HOST1.
This was clearly a mistake in design (from before my time), but I have
no ability to change it (in the next five years, anyway).
--
Dave Close
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarding to two servers
On 8/6/2010 1:05 PM, CLOSE Dave (DAE) wrote:
Joseph S D Yao wrote:
If you have two forwarders, as you listed, your server will try to
forward first to one and then to the other. If it gets any answer at
all from one - even an error answer - it will not try the other.
So forwarding works exactly the same as listing both servers in
resolv.conf? That behavior is exactly what I'm trying to avoid.
There are many ways to try to cascade name servers and try them one at a
time. By the good design of BIND, none of them work.
If BIND won't do the job, can you suggest another server that will? I
can't be the only one wanting to do something like this.
On your new server:
zone . { type hint; file root.hints; };
zone private.example.com { type forward; forward only;
forwarders { private.domain.server.IP; }; };
and put the IP address for this name server and no other in your
/etc/resolv.conf.
Ah, that might work -- in other circumstances. I understand the basic
idea to be using separate zones to force forwarding to different servers
for different domains. Did I understand correctly?
But an unfortunate characteristic of my PRIV server is that it doesn't
use /any/ domain. It only resolves simple, unqualified names like HOST1.
This was clearly a mistake in design (from before my time), but I have
no ability to change it (in the next five years, anyway).
Ah, so you want to implement something new, but not willing to fix the
old broken design which is incompatible with what you're trying to
implement. Gotcha.
The only halfway-reasonable way I see for your to work around this
broken design is to define each of those unqualified names
individually in your nameserver config, e.g.
zone HOST1 {
type master;
file HOST1;
};
and hope they don't change too often.
- Kevin
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarding to two servers
On 06/08/10 19:59, Kevin Darcy wrote:
On 8/6/2010 1:05 PM, CLOSE Dave (DAE) wrote:
Joseph S D Yao wrote:
If you have two forwarders, as you listed, your server will try to
forward first to one and then to the other. If it gets any answer at
all from one - even an error answer - it will not try the other.
So forwarding works exactly the same as listing both servers in
resolv.conf? That behavior is exactly what I'm trying to avoid.
There are many ways to try to cascade name servers and try them one
at a
time. By the good design of BIND, none of them work.
If BIND won't do the job, can you suggest another server that will? I
can't be the only one wanting to do something like this.
On your new server:
zone . { type hint; file root.hints; };
zone private.example.com { type forward; forward only;
forwarders { private.domain.server.IP; }; };
and put the IP address for this name server and no other in your
/etc/resolv.conf.
Ah, that might work -- in other circumstances. I understand the basic
idea to be using separate zones to force forwarding to different servers
for different domains. Did I understand correctly?
But an unfortunate characteristic of my PRIV server is that it doesn't
use /any/ domain. It only resolves simple, unqualified names like HOST1.
This was clearly a mistake in design (from before my time), but I have
no ability to change it (in the next five years, anyway).
Ah, so you want to implement something new, but not willing to fix the
old broken design which is incompatible with what you're trying to
implement. Gotcha.
The only halfway-reasonable way I see for your to work around this
broken design is to define each of those unqualified names
individually in your nameserver config, e.g.
zone HOST1 {
type master;
file HOST1;
};
and hope they don't change too often.
I believe you could use forwarding to the internal server for each
individual name:
zone HOST1 {
type forward;
forwarders{ private.domain.server.IP; };
}
This should do the trick but not elegant, not easy. I would start
hinting to management that changes are needed as this is not manageable
in the long term. Think also about adding search domains to the hosts
that need these lookups.
- Kevin
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Best regards
Sten Carlsen
No improvements come from shouting:
MALE BOVINE MANURE!!!
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarding to two servers
On Thu, 5 Aug 2010, Lyle Giese wrote:
zone mydomain.com{
type forward;
forward only;
forwarders { ip address of priv server;}; };
The priv server needs to be authorative(and probably master) for
mydomain.com.
As I understand it, BIND makes recursive queries to forwarding servers. If
the target is authoritative, you configure the zone as a stub. This is not
documented.
Neither stub nor forward zones work if you are doing DNSSEC validation and
the parent zone is secure and there is no delegation from the parent zone.
In this case you have to make the server authoritative for the child zone
(i.e. you must be the master or a slave) because BIND does not validate
authoritative zones so it does not trip over the lack of delegation.
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
WIGHT PORTLAND PLYMOUTH NORTH BISCAY: SOUTHWESTERLY VEERING WESTERLY OR
NORTHWESTERLY, 4 OR 5, OCCASIONALLY 6 AT FIRST. MODERATE, OCCASIONALLY ROUGH
IN PLYMOUTH AND NORTH BISCAY. RAIN OR SHOWERS, FAIR LATER. MODERATE OR GOOD,
OCCASIONALLY POOR.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dns-sec and Maintaining Human Sanity
On Fri, 6 Aug 2010, Martin McCormick wrote: I have started looking at various ways for our organization to begin using dns-sec as this appears to be a high management priority and it will eventually become necessary to operate. We have a fairly simple structure with a official master and slave with dynamic DHCP continuously updating the zone. Phil Mayers is right. Use BIND 9.7's built-in automated signing and follow Phil's suggested setup. BIND's DNSSEC support is designed to work well with a zone that is maintained using dynamic updates. Switching from static files to dynamic updates is one of the keys to working well with BIND and DNSSEC. You have already done that so you should feel happy :-) OpenDNSSEC predates BIND's auto-signing functionality, so it has become partly obsolete - but not completely. (As far as I can tell from a couple of looks at its documentation, it does not do large and/or dynamic zones very well. It seems to be designed to cope with spreading the CPU load of signing a very large number of mostly static zones using PKCS#11 crypto hardware.) It also does key management, and BIND does not yet do that for you. All you need to add is a cron job to run dnssec-keygen every so often with the right options. Sadly key management and rollover is still one of the most difficult areas of DNSSEC because there are so many interacting variables to get to grips with and the documentation is poor. For BIND the key things you need to know about are the sig-validity-interval option which controls the lifetime of RRSIG records, and dnssec-settime which sets the lifetime parameters of a DNSKEY. http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing and http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis explain how the parameters interact but are a bit intimidating. I don't know of any tutorials or documents that cut down the parameter space to something managable without sweeping the whole lot under the carpet. You also need to know that there is a lot of obsolete cruft in the dnssec-keygen manual page related to discarded bits of pre-4035 DNSSEC and the only non-trivial options you need to understand are -a -b -3 -e -f. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ WIGHT PORTLAND PLYMOUTH NORTH BISCAY: SOUTHWESTERLY VEERING WESTERLY OR NORTHWESTERLY, 4 OR 5, OCCASIONALLY 6 AT FIRST. MODERATE, OCCASIONALLY ROUGH IN PLYMOUTH AND NORTH BISCAY. RAIN OR SHOWERS, FAIR LATER. MODERATE OR GOOD, OCCASIONALLY POOR. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
