Re: is TSIG key rollover possible?
Don't think TSIG Key roll-over is possible - in the DNSSEC sense. Don't think it is as necessary either. I have separate TSIG relationships between my Primary and Secondary peers. I use the same TSIG for all zones that are on both peers - the TSIG is to secure the path between the two peers. I also have 'ssh' access to the peers and in order to perform a 'roll-over' would be logged in (ssh) to both sides of a single pair of peers when doing the update. The job thus would be.. a) change the config files on both sides b) signal named to reread its config - on both sided In total - I directly look after just eight such pairs of peers - not that hard. I change the signatures every 9 months. The only Gotcha to changing from hmac-md5 to one of the other algorithms is that when checking AXFR's with 'dig' you now need to add a third argument to the '-y' option - the algorithm to use. [-y [hmac:]name:key] In real life - I run an ISP and offer paid for 'secondary' nameserver services to my clients (ie those with their own hosted servers). I thus dress all this up with Web pages and a database backend. TSIG is a free option - all made nice'n'easy (change your named.conf to look like this... cut-n-paste) even with e-mail reminders to change old signatures. Almost no one uses the TSIG option - no one seems very interested. (Hey mark - that's a very cool feature - I'll see if I have the time to get around to it one day) On Wed, 2009-09-16 at 17:08 +1200, Sebastian Castro wrote: Hi everyone: I was reading the document Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records (http://www.ietf.org/id/draft-ietf-dnsext-tsig-md5-deprecated-03.txt) and I thought Darn, I must be prepared to do a TSIG renovation, so started researching how to do it. First step was checking if BIND supported a different algorithm, but the BIND ARM for BIND9.5 and 9.6 indicates The algorithm, hmac-md5, is the only one supported by BIND. That seemed strange, considering the document indicated above was originally proposed in 2008. So I used the source and found out other algorithms are supported in 9.5 and 9.6, so there is a mistake in the documentation. Anyway, TSIG rollover is an operation needed as indicated on RFC 2385: RFC 2385 quote - 6.2. Secret keys should be changed periodically. If the client host has been compromised, the server should suspend the use of all secrets known to that client. If possible, secrets should be stored in encrypted form. Secrets should never be transmitted in the clear over any network. This document does not address the issue on how to distribute secrets. Secrets should never be shared by more than two entities. RFC 2385 quote - but again the documentation indicates: Multiple keys may be present, but only the first is used. So, to coordinate the retirement of an old TSIG key and the introduction of a new one, it seems a close coordination between peers is needed in order to make it work, within a 'maintenance window' where the operations using the TSIG are not executed (in my particular interest, zone transfers)? Is it not possible to gradually introduce a new key, use both for a period of time and later retire the old one, similar to what is done in DNSSEC? Any experience on this matter that could be shared publicly or privately will be appreciated. Kind Regards Sebastian Castro ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- . . ___. .__ Posix Systems - Sth Africa. e.164 VOIP ready /| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Modified a zone, so when it becomes available?
Robert Spangler schrieb: On Tuesday 15 September 2009 08:16, Frank Stanek wrote: Please forgive my naivety if this is totally wrong but I don't have a chrooted bind environment to verify this atm. I run a chroot environment But doesn't the init script in some distributions copy the configuration files (including zone files) into the chroot joil because bind cannot access them in /etc from there? Not that I am aware of. If you know of a distro that does this let us know. A chroot'ed bind has no knowledge of anything outside of it's chroot environment so the files have to exist there. That could explain why it works when you use the init script to restart bind but it doesn't when you do rndc reload - the modified files don't get copied into the jail with rndc reload. And they do not with the init script either. The init script is shutting down bind and then reloading it again which forces a fresh read of all the files, as rndc is just telling bind to re-read the zone. You are correct. I just had a chance to look at /etc/sysconfig/named in a SLES 10 installation and it says this: # Shall the DNS server 'named' or the LightWeight RESolver Daemon, lwresd run # in the chroot jail /var/lib/named/? # Each time you start one of the daemons with the init script, /etc/named.conf, # /etc/named.conf.include, /etc/rndc.key, and all files listed in # NAMED_CONF_INCLUDE_FILES will be copied relative to /var/lib/named/. So the configuration and key files do get copied into the chroot jail. But the zone files on SLES 10 already reside in /var/lib/named, so that could not have been the problem. Apologies and kind regards ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Need help on delegation to subdomain/external servers
Hi, i'm using BIND9 on an Ubuntu-8.10-server. I'd like to configure the following: For a given name (eg. vega.lab.ts), I'd like to forward the request to two external DNS servers, *simultaneously*, and respond with the first response that i get. Is this possible? I didn't see how to do it directly, so i tried using a subdomain, (eg. x.vega.lab.ts) and specifiying the two DNS for this subdomain: Extract from the lab.ts zone file: [...] x.lab.ts. IN NS vega-a.x.lab.ts. x.lab.ts. IN NS vega-b.x.lab.ts. vega-a.x.lab.ts.IN A 172.25.32.252 vega-b.x.lab.ts.IN A 192.168.2.3 [...] But this doesnt seem to work: named-checkzone lab.ts /etc/bind/db.lab.ts says: zone lab.ts/IN: x.lab.ts/NS 'vega-a.x.lab.ts' (out of zone) has no addresses records (A or ) zone lab.ts/IN: x.lab.ts/NS 'vega-b.x.lab.ts' (out of zone) has no addresses records (A or ) zone lab.ts/IN: loaded serial 2 OK How can i do it? Thanks, Lars ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Need help on delegation to subdomain/external servers
On Wed, Sep 16, 2009 at 05:20:21PM +0200, RUOFF LARS wrote:
Hi,
i'm using BIND9 on an Ubuntu-8.10-server.
I'd like to configure the following:
For a given name (eg. vega.lab.ts), I'd like to forward the request to
two external DNS servers, *simultaneously*, and respond with the first
response that i get.
Is this possible?
I didn't see how to do it directly, so i tried using a subdomain, (eg.
x.vega.lab.ts) and specifiying the two DNS for this subdomain:
Extract from the lab.ts zone file:
[...]
x.lab.ts. IN NS vega-a.x.lab.ts.
x.lab.ts. IN NS vega-b.x.lab.ts.
vega-a.x.lab.ts.IN A 172.25.32.252
vega-b.x.lab.ts.IN A 192.168.2.3
[...]
But this doesnt seem to work:
named-checkzone lab.ts /etc/bind/db.lab.ts says:
zone lab.ts/IN: x.lab.ts/NS 'vega-a.x.lab.ts' (out of zone) has no
addresses records (A or ) zone lab.ts/IN: x.lab.ts/NS
'vega-b.x.lab.ts' (out of zone) has no addresses records (A or )
zone lab.ts/IN: loaded serial 2 OK
How can i do it?
Thanks,
Lars
You can use `forward` zone. Check
https://www.isc.org/software/bind/documentation/arm95#zone_statement_grammar:
zone example.com IN {
type forward;
forward only;
forwarders { IPaddr; };
};
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Modified a zone, so when it becomes available?
In article mailman.508.1253094340.14796.bind-us...@lists.isc.org, Marcos Lorenzo de Santiago marcos.lore...@ayto-getafe.org wrote: El mar, 15-09-2009 a las 13:45 +0200, Udo Zumdick escribió: Am Tue, 15 Sep 2009 12:28:24 +0200 schrieb Marcos Lorenzo de Santiago marcos.lore...@ayto-getafe.org: [] After making changes to zone, updated serial, and rndc reload, I dig my zone and get always the old serial. The serial and the changes only appear when I '/etc/init.d/bind restart' it. I use bind 9.5.1 on debian 5.0.3. Any clue? Maybe there are some .jnl files (IXFR journalfiles) which could prevent bind from updating the zone ? Removing them and disabling incremental zone transfer might help. I had such problems in the past. There are no .jnl files, so I guess is turned off, but anyway, how can I know If this is enabled? I don't have any allow-update option... Thanks in advance. Have you checked your log file yet? I don't know where the debian setup puts the messages by default, but you should be able to see messages saying what named is doing when you tell it to reload the zone. Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
9.7.0a3: dnssec-signzone signs with passive keys?
I currently explore the new DNSKEY metadata and dnssec-signzone -S with BIND 9.7.0a3. This feature definitely helps making key management easier and will motivate more operators to sign their zones. Thank you for that. For this test, I created a zone with one manually timed KSK, one active ZSK and another published ZSK with an activation date in the future. When I sign the zone from an unsigned zone file, dnssec-signzone works as expected and signs the records only with the active ZSK. Re-signing the signed zone file, however, also includes signatures from the passive ZSK, *unless* I remove the DNSKEY records from the zone file before signing. I guess this is due to the keys already in the signed zone file overriding the -S switch: |key |Specify which keys should be used to sign the zone. |If no keys are specified, then the zone will be examined for |DNSKEY records at the zone apex. If these are found and |there are matching private keys, in the current directory, |then these will be used for signing. (No Fetching [...] from key repository when re-signing) My question is: Is this the supposed behaviour (ie. keys already included in a zone don't have their metadata checked, so I would need to remove DNSKEY records), did I miss an option to pass to dnssec-signzone or is it likely to change for the next release? Hauke. dnssec-settime/signzone output: KSK: | Kkeyroll.dnstest.hauke-lampe.de.+005+07849.key | | Created: Wed Sep 16 04:23:39 2009 | Publish: UNSET | Activate: UNSET | Revoke: UNSET | Unpublish: UNSET | Delete: UNSET Active ZSK: | Kkeyroll.dnstest.hauke-lampe.de.+005+42630.key | | Created: Wed Sep 16 21:19:34 2009 | Publish: Wed Sep 16 21:19:34 2009 | Activate: Wed Sep 16 21:19:52 2009 | Delete: Tue Oct 13 21:19:34 2009 Passive ZSK: | Kkeyroll.dnstest.hauke-lampe.de.+005+07701.key | | Created: Wed Sep 16 21:21:35 2009 | Publish: Wed Sep 16 21:21:35 2009 | Activate: Tue Sep 29 21:21:35 2009 | Delete: Tue Oct 13 21:21:35 2009 Signing the zone from an unsigned zone file: | + dnssec-signzone -v 3 -N unixtime -K rollkeys -e +4d -i 172800 -S -T 230042 -o keyroll.dnstest.hauke-lampe.de -f db.keyroll.signed db.keyroll | Fetching KSK 7849/RSASHA1 from key repository | Fetching ZSK 42630/RSASHA1 from key repository | Fetching ZSK 7701/RSASHA1 from key repository | dnssec-signzone: debug 1: decrement_reference: delete from rbt: 0xb7c83060 keyroll.dnstest.hauke-lampe.de | dnssec-signzone: debug 1: calling free_rbtdb(.) | dnssec-signzone: debug 1: done free_rbtdb(.) | dnssec-signzone: keyroll.dnstest.hauke-lampe.de/NSEC: | dnssec-signzone:signing with dnskey keyroll.dnstest.hauke-lampe.de/RSASHA1/42630 | dnssec-signzone: keyroll.dnstest.hauke-lampe.de/DNSKEY: | dnssec-signzone:signing with dnskey keyroll.dnstest.hauke-lampe.de/RSASHA1/7849 | dnssec-signzone:signing with dnskey keyroll.dnstest.hauke-lampe.de/RSASHA1/42630 | dnssec-signzone: keyroll.dnstest.hauke-lampe.de/SOA: | dnssec-signzone:signing with dnskey keyroll.dnstest.hauke-lampe.de/RSASHA1/42630 | dnssec-signzone: keyroll.dnstest.hauke-lampe.de/NS: | dnssec-signzone:signing with dnskey keyroll.dnstest.hauke-lampe.de/RSASHA1/42630 | Verifying the zone using the following algorithms: RSASHA1. | Zone signing complete: | Algorithm: RSASHA1: ZSKs: 2, KSKs: 1 active, 0 revoked, 0 stand-by | db.keyroll.signed | dnssec-signzone: debug 1: calling free_rbtdb(keyroll.dnstest.hauke-lampe.de) | dnssec-signzone: debug 1: done free_rbtdb(keyroll.dnstest.hauke-lampe.de) Re-Signing: | + dnssec-signzone -v 3 -N unixtime -K rollkeys -e +4d -i 172800 -S -T 230042 -o keyroll.dnstest.hauke-lampe.de -f db.keyroll.signed db.keyroll.signed | dnssec-signzone: debug 1: decrement_reference: delete from rbt: 0xb7c91060 keyroll.dnstest.hauke-lampe.de | dnssec-signzone: debug 1: calling free_rbtdb(.) | dnssec-signzone: debug 1: done free_rbtdb(.) | dnssec-signzone: keyroll.dnstest.hauke-lampe.de/SOA: | dnssec-signzone:rrsig by keyroll.dnstest.hauke-lampe.de/RSASHA1/42630 dropped - failed to verify | dnssec-signzone:resigning with dnskey keyroll.dnstest.hauke-lampe.de/RSASHA1/42630 | dnssec-signzone:signing with dnskey keyroll.dnstest.hauke-lampe.de/RSASHA1/7701 | dnssec-signzone: keyroll.dnstest.hauke-lampe.de/NS: | dnssec-signzone:rrsig by keyroll.dnstest.hauke-lampe.de/RSASHA1/42630 retained | dnssec-signzone:signing with dnskey keyroll.dnstest.hauke-lampe.de/RSASHA1/7701 | dnssec-signzone: keyroll.dnstest.hauke-lampe.de/NSEC: | dnssec-signzone:rrsig by keyroll.dnstest.hauke-lampe.de/RSASHA1/42630 retained | dnssec-signzone:signing with dnskey keyroll.dnstest.hauke-lampe.de/RSASHA1/7701 | dnssec-signzone: keyroll.dnstest.hauke-lampe.de/DNSKEY: | dnssec-signzone:rrsig by keyroll.dnstest.hauke-lampe.de/RSASHA1/7849 retained | dnssec-signzone:rrsig by keyroll.dnstest.hauke-lampe.de/RSASHA1/42630 retained |
Re: is TSIG key rollover possible?
Mark Elkins wrote: Don't think TSIG Key roll-over is possible - in the DNSSEC sense. Don't think it is as necessary either. I have separate TSIG relationships between my Primary and Secondary peers. I use the same TSIG for all zones that are on both peers - the TSIG is to secure the path between the two peers. I also have 'ssh' access to the peers and in order to perform a 'roll-over' would be logged in (ssh) to both sides of a single pair of peers when doing the update. The job thus would be.. a) change the config files on both sides b) signal named to reread its config - on both sided In total - I directly look after just eight such pairs of peers - not that hard. I change the signatures every 9 months. Thanks for sharing your experience. In my particular case, I 'own' part of the set of nameservers for my zones and the rest is provided by external DNS providers. When you have full control of your machines, you can prepare this change without issues: you change the keys, check the conf files, push the new files and reload everything. But when you have third parties involved in different time zones, is more complicated to coordinate a time to do the same task. I will investigate more based on Mark Andrews' reply and let the list know. cheers Sebastian Castro The only Gotcha to changing from hmac-md5 to one of the other algorithms is that when checking AXFR's with 'dig' you now need to add a third argument to the '-y' option - the algorithm to use. [-y [hmac:]name:key] In real life - I run an ISP and offer paid for 'secondary' nameserver services to my clients (ie those with their own hosted servers). I thus dress all this up with Web pages and a database backend. TSIG is a free option - all made nice'n'easy (change your named.conf to look like this... cut-n-paste) even with e-mail reminders to change old signatures. Almost no one uses the TSIG option - no one seems very interested. (Hey mark - that's a very cool feature - I'll see if I have the time to get around to it one day) On Wed, 2009-09-16 at 17:08 +1200, Sebastian Castro wrote: Hi everyone: I was reading the document Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records (http://www.ietf.org/id/draft-ietf-dnsext-tsig-md5-deprecated-03.txt) and I thought Darn, I must be prepared to do a TSIG renovation, so started researching how to do it. First step was checking if BIND supported a different algorithm, but the BIND ARM for BIND9.5 and 9.6 indicates The algorithm, hmac-md5, is the only one supported by BIND. That seemed strange, considering the document indicated above was originally proposed in 2008. So I used the source and found out other algorithms are supported in 9.5 and 9.6, so there is a mistake in the documentation. Anyway, TSIG rollover is an operation needed as indicated on RFC 2385: RFC 2385 quote - 6.2. Secret keys should be changed periodically. If the client host has been compromised, the server should suspend the use of all secrets known to that client. If possible, secrets should be stored in encrypted form. Secrets should never be transmitted in the clear over any network. This document does not address the issue on how to distribute secrets. Secrets should never be shared by more than two entities. RFC 2385 quote - but again the documentation indicates: Multiple keys may be present, but only the first is used. So, to coordinate the retirement of an old TSIG key and the introduction of a new one, it seems a close coordination between peers is needed in order to make it work, within a 'maintenance window' where the operations using the TSIG are not executed (in my particular interest, zone transfers)? Is it not possible to gradually introduce a new key, use both for a period of time and later retire the old one, similar to what is done in DNSSEC? Any experience on this matter that could be shared publicly or privately will be appreciated. Kind Regards Sebastian Castro ___ 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: 9.7.0a3: dnssec-signzone signs with passive keys?
Re-signing the signed zone file, however, also includes signatures from the passive ZSK, *unless* I remove the DNSKEY records from the zone file before signing. I guess this is due to the keys already in the signed zone file overriding the -S switch: Yes, that's a bug. Thank you very much, we'll address it in the next release. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Modified a zone, so when it becomes available?
On Wednesday 16 September 2009 02:52, Marcos Lorenzo de Santiago wrote: El mar, 15-09-2009 a las 17:27 -0400, Robert Spangler escribió: On Tuesday 15 September 2009 08:16, Frank Stanek wrote: Please forgive my naivety if this is totally wrong but I don't have a chrooted bind environment to verify this atm. I run a chroot environment But doesn't the init script in some distributions copy the configuration files (including zone files) into the chroot joil because bind cannot access them in /etc from there? Not that I am aware of. If you know of a distro that does this let us know. A chroot'ed bind has no knowledge of anything outside of it's chroot environment so the files have to exist there. I just link the chrooted file named.conf to /etc/bind/named.conf, so the file in /etc is actually a link to the file within then chrooted environment. In my environment I have the other way. named.conf, named.zones and rndc.key in /etc are linked to the chroot enviroment. -- Regards Robert Linux User #296285 http://counter.li.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Need help on delegation to subdomain/external servers
RUOFF LARS wrote: Hi, i'm using BIND9 on an Ubuntu-8.10-server. I'd like to configure the following: For a given name (eg. vega.lab.ts), I'd like to forward the request to two external DNS servers, *simultaneously*, and respond with the first response that i get. Is this possible? Short answer: not possible with BIND currently, that I know of. Longer answer: why would you even want to do this? Sounds like you're barking up the wrong tree. Latency of DNS response may have little or nothing to do with the latency of whatever real-time connection (HTTP, LDAP, VoIP, video, audio, whatever) is being established using that DNS information. Trying to equate DNS response latency to anything else that a user would care about, is an exercise in futility, IMO. Furthermore, have you considered caching? Once the answer is cached, then a BIND nameserver won't try to fetch the information from other servers *at*all*, until that cache entry expires. If your goal is to optimize application performance by always directing users to a best node, among a set or cluster of nodes, then put a load-balancer in front of this resource: on the back-end, it can measure latency or any other metric(s), which is most representative of the user experience for this resource (depending on the probing/measurement capabilities of the load-balancer device/package/subsystem). On the front-end, the load-balancer responds with whatever IP represents the best choice for that resource, at any particular point in time. As with any DNS-based load-balancing scheme, you might have to lower the TTLs of the relevant records to ridiculously- (possibly anti-socially-)low values in order to provide sufficiently-dynamic load balancing. I didn't see how to do it directly, so i tried using a subdomain, (eg. x.vega.lab.ts) and specifiying the two DNS for this subdomain: Extract from the lab.ts zone file: [...] x.lab.ts. IN NS vega-a.x.lab.ts. x.lab.ts. IN NS vega-b.x.lab.ts. vega-a.x.lab.ts.IN A 172.25.32.252 vega-b.x.lab.ts.IN A 192.168.2.3 [...] But this doesnt seem to work: named-checkzone lab.ts /etc/bind/db.lab.ts says: zone lab.ts/IN: x.lab.ts/NS 'vega-a.x.lab.ts' (out of zone) has no addresses records (A or ) zone lab.ts/IN: x.lab.ts/NS 'vega-b.x.lab.ts' (out of zone) has no addresses records (A or ) zone lab.ts/IN: loaded serial 2 OK I just ran a quick test, and it appears that named-checkzone actually goes out and tries to resolve glue records it encounters. Since you haven't delegated the zone yet, it's not surprising that the glue records don't resolve from the authoritative nameservers for the zone. In this respect, I think named-checkzone is being more rigorous than named itself would be, as it loads the zone. If these no addresses records [sic] errors are the *only* ones being reported for the zone, then I'd try to load it and see if those errors magically evaporate once you do that. I don't think delegation is the solution to your load-balancing requirement, however. NS'es are tried, sequentially, according to historical RTT statistics; _over_time_, faster-responding servers will tend to get tried before slow-responding ones, but this adaptivity may take time to kick in when the responsiveness of the target nameservers changes, so it would probably not be dynamic enough to meet your requirements, even _if_ the latency of DNS responses were reflective of the performance of the underlying app (which I question above). - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
