Re: DNSKEY NODATA responses not cached
On Tue, 11 Jan 2011 18:46:39 +0100, Kalman Feher kalman.fe...@melbourneit.com.au said: I'm curious whether the domain in question had a DS in the parent zone? No, it didn't. The effect is there even if the parent zone does not support DNSSEC. I stumbled over this while I was checking whether my tools could properly handle turning on DNSSEC for an existing zone, which involves having to wait for cached DNSKEY NODATA to expire from caches before adding the DS. On 11/01/11 4:52 PM, Chris Thompson c...@cam.ac.uk wrote: On Jan 11 2011, Alexander Gall wrote: It appears that NODATA responses for qtype=DNSKEY are not cached if DNSSEC validation is enabled (tested with 9.7.2-P3). What is the rationale behind this? I confirm the effect (same release). Or rather, the NODATA does get cached, as shown by a !DNSKEY count in the statistics display, but a new request goes back to the authoritative servers again anyway, as shown by the outgoing queries count and by the SOA in the authority section of the NODATA response having its original value. I'm tending towards calling this a bug :) -- Alex ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC Keys - and trying to not leaving them around
There are some parts of Key management with DNSSEC that I don't quite get - so I'm hoping for some feedback. I'm using BIND 9.7.2-P3 and running dnssec-signzone -3 abcd -o example.com -p -t -A example.com I believe that:- 1 - The KSK is used to sign the ZSK. 2 - The ZSK is used to sign the rest of the data in the zone. (I'm a little unclear which parts of the KSK are needed to sign the ZSK and which parts of the ZSK need to be around to sign the rest of the zone) On a virgin zone - you'd need the private parts of the ZSK and KSK's available (either in the local directory or as the arg to a -d). Technically - the public parts (*.key) could be in the zone to be signed - so don't need to be available any more. (ie - there was a cat K*.key zone) Doesn't seem to work like that - as I'm getting the error (for each key) dnssec-signzone: warning: dns_dnssec_keylistfromrdataset: error reading private key file co.za/NSEC3RSASHA1/64250: file not found (64250 is the ZSK) If I also have the *.key parts in the same directory - all works OK. So the error message is lying to me!!! ??? - Bug? --- So now I want to resign the zone. Its already signed. How can I do that without having to have the Private KSK still around. I'd have thought that I'd just perhaps need the Private ZSK around to re-sign new zone data. (here I removed the KSK Private file - 9983) I think this works - but I get the message: dnssec-signzone: warning: dns_dnssec_keylistfromrdataset: error reading private key file example.com/NSEC3RSASHA1/9983: file not found So why is dnssec-signzone worried about the private part of a KSK that it (I believe) should not need? Bug? My zone changes quite a bit - so what I was thinking to do is Sign a very basic copy of the zone (SOA, NS records - not much else) - then move the Private KSK's off the disk completely - then add in my dynamic data and re-sign as often as I need (whenever my dynamic data changes) with just my Private ZSK available. After about 6 month (whatever) - I can then create a new KSK - bring back my original 'off-disk' Private KSK - sign a new basic copy of my zone - take the two Private KSK's offline and go through the whole KSK roll-over process. ie - I only have the private part of the KSK on the disk for a very short time - usually its off-site. I should be able to generate my very basic zone on a completely different server - perhaps not connected to the Internet at all - and just (via USB stick) copy over the basic signed zone every six months? I'm just worried about the earlier error messages Can someone please explain? (What is needed when) -- . . ___. .__ Posix Systems - (South) Africa /| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 smime.p7s Description: S/MIME cryptographic signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind 9 multiple masters setup
Hello, I have most of this worked out but I intend to setup bind in a multiple master manner. This makes me question a few things: 1. What can I use for the SOA MNAME? In the off chance a box may die, I am thinking of using a VIP which contains the multiple masters within it. However I am not sure how this would affect NOTIFY. So can I use a VIP or do I just use one of the master DNS boxes in the SOA MNAME field? 2. With that said, I intend to use rndc to push out DNS changes, should I worry about using a VIP still? I may need to use both and NOTIFY seems like it is more built-in so I want to keep rndc and NOTIFY going. Hope someone has gone through this trauma. Thank you!, Zahid Bukhari ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC's sorted zone
On Wed, 12 Jan 2011, Mark Elkins wrote: dnssec-signzone -3 abcd -o example.com -p -t -A -d keyset -g -a -N increment -s 2011061553 -e 20110210161553 -f example.com.sign-1 example.com.signed A minute later - I run the same command - but output to a different file... -f example.com.sign-2 A 'diff' of the two output files gives lots of differences - apart from the zone creation time. If I include the -n ncpus as -n 1 - then the files are the same (except for the creation time). I believe that the data is fundamentally the same - but it is partially re-ordered if there are multiple threads. This is not what I would have expected - having had it been drummed into me that dnssec-signzone will first sort the zone then generate all the RRSIG records - etc... I find this disturbing. It appears to only be doing this on CNAME records. I'd recommend preprocessing the zone with ldns-read-zone, which also sorts and canonicalises the zone. Later on, you can then also use this command to seperate unsigned data from dnssec, and merge in data (eg updates) from multiple zone versions while re-using previous RRSIGs Paul ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9 multiple masters setup
On Wed, Jan 12, 2011 at 5:13 PM, dev null devn...@cimmerii.org wrote:
Hello,
I have most of this worked out but I intend to setup bind in a
multiple master manner.
This makes me question a few things:
1. What can I use for the SOA MNAME? In the off chance a box may die,
I am thinking of using a VIP which contains the multiple masters
within it. However I am not sure how this would affect NOTIFY. So can
I use a VIP or do I just use one of the master DNS boxes in the SOA
MNAME field?
You can use any authoritative for the zone name server. One of the masters
is good enough.
2. With that said, I intend to use rndc to push out DNS changes,
should I worry about using a VIP still? I may need to use both and
NOTIFY seems like it is more built-in so I want to keep rndc and
NOTIFY going.
How do you plan to replicate the zone data between the masters? At the
slaves you can just set few masters for each zone. For example:
zone example.com {
type slave;
file /var/named/example.com.zone;
masters { master_ip_address; master_ip_address; ... };
}
When named receives NOTIFY for a zone it will check one by one the servers
from the masters list.
Hope someone has gone through this trauma.
Thank you!,
Zahid Bukhari
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
ena
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9 multiple masters setup
On 01/12/11 16:13, dev null wrote: Hello, I have most of this worked out but I intend to setup bind in a multiple master manner. This makes me question a few things: 1. What can I use for the SOA MNAME? In the off chance a box may die, I am thinking of using a VIP which contains the multiple masters within it. However I am not sure how this would affect NOTIFY. So can I use a VIP or do I just use one of the master DNS boxes in the SOA MNAME field? It's mostly ignored. All resolvers go for the NS records at the zone apex, not for MNAME. Even if the server named in MNAME dies, it won't affect resolving. You just rebuild that machine, or even build another one and change slaves to get data from new master. 2. With that said, I intend to use rndc to push out DNS changes, should I worry about using a VIP still? I may need to use both and NOTIFY seems like it is more built-in so I want to keep rndc and NOTIFY going. Isn't it simplier to just let BIND do it's job? When master loads a changed zone, it sends NOTIFY messages to slaves, and slaves seeing that they have outdated zone files download the zone from master. rndc can only tell BIND (either master or slave) to initiate that connection, it can't change zones by itself. You could of course copy zone files to slaves by some means (rsync? scp?) and then rndc reload the slave, but a) why? b) it really isn't a slave anymore, at least not in DNS terms. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
how to proper include DS record on key dnssec
hello bind network hello dnssec network admin. I correctly configure my server centos dnssec on with as a representative of encryptions dlv isc. my question is relevant and was already asked but I have not found the complete answer on google. my question is how to include the DS record in the Keys. my keys are in a separate folder. the DS record is already generated in I also wonder the utility of this good record given that my signatures are marked as good on dlv I read that a single include file in the keys was the right approach but I would like to have more precision on the proper conduct of this operation what file in the include directive must be accomplished and realize how well inclusion of the DS record (what should be the proper syntax on how to declare dlv isc) how to re-sign after the keys this is it the response on google for implement DS record with dnssec http://newsgroups.derkeiler.com/Archive/Comp/comp.protocols.dns.bind/2010-08/msg00054.html thanks for many returns who are welcome this is a relevant on my config of keys ~]# cat /var/named/dsset-fakessh.eu. fakessh.eu. IN DS 47103 3 1 CFEA04C5B91**7F2DF5225E357 fakessh.eu. IN DS 47103 3 2 68096942650C1DD89D5**09F4F1CD348 4D8ED07B ~]# ls -al /var/named/keys total 8 drwxrwxr-x 2 root named 4096 jan 1 15:41 . drwxrwx--- 7 root named 4096 jan 1 15:34 .. lrwxrwxrwx 1 root named 28 jan 1 15:41 dsset-fakessh.eu. - /var/named/dsset-fakessh.eu. lrwxrwxrwx 1 root named 34 jan 1 15:41 dsset-nicolaspichot.fr. - /var/named/dsset-nicolaspichot.fr. lrwxrwxrwx 1 root named 33 jan 1 15:41 dsset-renelacroute.fr. - /var/named/dsset-renelacroute.fr. lrwxrwxrwx 1 root named 29 jan 1 15:41 keyset-fakessh.eu. - /var/named/keyset-fakessh.eu. lrwxrwxrwx 1 root named 35 jan 1 15:41 keyset-nicolaspichot.fr. - /var/named/keyset-nicolaspichot.fr. lrwxrwxrwx 1 root named 34 jan 1 15:41 keyset-renelacroute.fr. - /var/named/keyset-renelacroute.fr. lrwxrwxrwx 1 root named 37 jan 1 15:41 Kfakessh.eu.+003+47103.key - /var/named/Kfakessh.eu.+003+47103.key lrwxrwxrwx 1 root named 41 jan 1 15:41 Kfakessh.eu.+003+47103.private - /var/named/Kfakessh.eu.+003+47103.private lrwxrwxrwx 1 root named 37 jan 1 15:41 Kfakessh.eu.+003+59773.key - /var/named/Kfakessh.eu.+003+59773.key lrwxrwxrwx 1 root named 41 jan 1 15:41 Kfakessh.eu.+003+59773.private - /var/named/Kfakessh.eu.+003+59773.private lrwxrwxrwx 1 root named 43 jan 1 15:41 Knicolaspichot.fr.+003 +02473.key - /var/named/Knicolaspichot.fr.+003+02473.key lrwxrwxrwx 1 root named 47 jan 1 15:41 Knicolaspichot.fr.+003 +02473.private - /var/named/Knicolaspichot.fr.+003+02473.private lrwxrwxrwx 1 root named 43 jan 1 15:41 Knicolaspichot.fr.+003 +07246.key - /var/named/Knicolaspichot.fr.+003+07246.key lrwxrwxrwx 1 root named 47 jan 1 15:41 Knicolaspichot.fr.+003 +07246.private - /var/named/Knicolaspichot.fr.+003+07246.private lrwxrwxrwx 1 root named 42 jan 1 15:41 Krenelacroute.fr.+003 +01827.key - /var/named/Krenelacroute.fr.+003+01827.key lrwxrwxrwx 1 root named 46 jan 1 15:41 Krenelacroute.fr.+003 +01827.private - /var/named/Krenelacroute.fr.+003+01827.private lrwxrwxrwx 1 root named 42 jan 1 15:41 Krenelacroute.fr.+003 +57237.key - /var/named/Krenelacroute.fr.+003+57237.key lrwxrwxrwx 1 root named 46 jan 1 15:41 Krenelacroute.fr.+003 +57237.private - /var/named/Krenelacroute.fr.+003+57237.private -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 signature.asc Description: Ceci est une partie de message numériquement signée ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9 multiple masters setup
If a zone is not dynamic, then the MNAME does nothing except to possibly inhibit notifies to the declared master iff you specify the option notify yes or if you do not specify any notify option (as notify yes is the default). If a zone is dynamic, then the MNAME plays a very critical role of telling all clients where to send dynamic DNS updates. I hear that support for multi-master with dynamic zones is expected in version 10. I have my own questions about how that will be done. -- Gordon A. Lang / 313-819-7978 - Original Message - From: dev null devn...@cimmerii.org To: bind-users@lists.isc.org Sent: Wednesday, January 12, 2011 10:13 AM Subject: bind 9 multiple masters setup Hello, I have most of this worked out but I intend to setup bind in a multiple master manner. This makes me question a few things: 1. What can I use for the SOA MNAME? In the off chance a box may die, I am thinking of using a VIP which contains the multiple masters within it. However I am not sure how this would affect NOTIFY. So can I use a VIP or do I just use one of the master DNS boxes in the SOA MNAME field? 2. With that said, I intend to use rndc to push out DNS changes, should I worry about using a VIP still? I may need to use both and NOTIFY seems like it is more built-in so I want to keep rndc and NOTIFY going. Hope someone has gone through this trauma. Thank you!, Zahid Bukhari ___ 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
MNAME and BIND 10 question
Does anybody happen to know. With BIND 9, if the MNAME resolves to multiple A records and notify yes is specified, do notifies get withheld from all specified NS destinations that resolve to any of the addresses associated with the MNAME? Or do notifies only get withheld from NS destinations whose fqdn's mnemonically match the MNAME field? Has it been decided yet for BIND 10 how the multiple masters will be specified? Will BIND 10 follow Microsoft's lead where the MNAME in each zone is set to match the server name on which the zone resides? Or might the MNAME be allowed to have multiple A records to give dynamic DNS clients more than one choice? Does anyone know how existing Microsoft DNS client code reacts to having the MNAME resolve to multiple A records? What about non-Microsoft DNS client codes? Does Microsoft DNS client code ever use any other DDNS target identifier other than the MNAME? I know some old codes used the NS records and/or the client's resolver list, but it is my understanding that both of those techniques have been completely abandoned -- does anyone believe otherwise? And are there any other techniques used by Microsoft that perhaps I've never heard of -- anyone know? Does anyone have any other interesting information about BIND 10 with respect to multi-master dynamic zone functionality? Thanks. -- Gordon A. Lang / 313-819-7978___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: MNAME and BIND 10 question
On Jan 12, 2011, at 11:09 PM, Gordon A. Lang wrote: Does Microsoft DNS client code ever use any other DDNS target identifier other than the MNAME? I know some old codes used the NS records and/or the client's resolver list, but it is my understanding that both of those techniques have been completely abandoned -- does anyone believe otherwise? And are there any other techniques used by Microsoft that perhaps I've never heard of -- anyone know? I believe Microsoft clients tend to try all three behaviors you've mentioned. The last standard I read for this said that the SOA MName is to be used if and only if it corresponds to an NS record of the same name. Otherwise, a random NS record is to be chosen. Of course, many actual DDNS updaters ignore this, trying the MName host regardless of whether it has an NS record; this includes the nsupdate command itself. However, ISC's dhcpd, at least version 3.1, follows the standard set forth above unless configured to do otherwise. Regards, Chris Buxton BlueCat Networks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
