Re: tsig zone sharing between zones check + scream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.08.2015 um 03:06 schrieb Lawrence K. Chen, P.Eng.: > > > On 2015-08-07 10:08, Heiko Richter wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> Am 07.08.2015 um 08:52 schrieb Lawrence K. Chen, P.Eng.: >>> Gjust noticed that about 12 hours ago, the business >>> office person finally update our KSK with registrar. (where >>> window was last month.) >>> >>> Well, apparently history must repeat >>> >>> 3 years ago, we rolled over from RSASHA256 to RSASHA256... but >>> the person that did all the interaction with >>> registrarswhere the criteria is that they be in position >>> to pay as needed (which did used to be dns >>> administrator/department manager/etcbut when they left the >>> new manager he didn't want us to continue to have that >>> responsibility...but would've taken it...anyhoo) They >>> selected algorithm type as RSASHA1-NSEC3... >>> >>> Which caused a bit of an outage, especially since they went on >>> vacation right after having left it to the last minute. we >>> had a 60 day rollover window)...original I had gone around end >>> of fiscal year, but decided to shift it... >>> >>> >>> Well, this timestill going RSASHA256 to RSASHA256 (I >>> had done the roll from RSASHA1-NSEC to RSASHA256 before it was >>> possible to register do such things with registrar...so only >>> DLV was involvedthough I did run into a problem since I >>> had a DS record in my zone, etc. the mismatch doing one than >>> the other apparently was the wrong way to go...or soemething.) >>> >>> So this time...RSASHA1 (#5) got selected. >>> > >> If you change the algorithm of your KSK it shoudn't be necessary >> to change your server's configuration. Neither is it necessary >> to change the TSIG keys. >> >> Just dump the keys into your domain's key-directory and bind will >> eventually import and use them. If you're in a hurry, you can >> force the import by running rndc loadkeys >> >> Of course you will also need to retire your old key and remove >> them from the zone by running dnssec-keygen -D now -I now >> >> And you should (should, not must!) generate new ZSKs, using the >> same algorithm, so change your ZSK-rollover-script to generate >> RSASHA1 from now on. >> >> But looking at your algorithm you will have a slight problem, >> which you need to take care of, BEFORE you publish your new key: >> RSASHA1 is not NSEC3-aware. So if you decide to run with that >> key, you have to remove the NSEC3-parameters from your zone (if >> you have any). >> > > The TSIG stuff is related to a separate issue I'm trying to resolve > caused by upgrading to 9.9.7-P2. > > While for KSK, I have no intention of change my algorithm, in > violation of previous rulings by Chief Info Security Officer > just because the business office staff person had changed the > algorithm we use when putting up the new DS I had forwarded up to > get set with our registrar. No error was made when DS was added > for our other domain done at the same time. > > I sure wish there was an automated way to do our KSK > rolloversespecially if they want to do DNSSEC for the 100's of > other domains we serve. > There are a few registrars available that support api access for changing KSKs. > But, on second try today, it got fixed. (though I suspect the > first was valid, but differed from how k-state.edu got done. > > Also not sure what the implications are. That I sent two DS > records (per domain) up. And, only the SHA-1 has been entered. > Today in fixing the RSASHA1 + SHA1 entry, it was first replaced as > being RSASHA256 + SHA256, but then replaced with SHA-1 digest > version (though the SHA256 attempt might have been a real error? > Nope...the last 4 digits match the SHA256 DS) > > What's odd is that in all cases, the confirmation email says > "DNSKEY was Verfied" I'd expect that with the two tries today, > but how was that possible when they had selected the wrong > algorithm? Hmmm, wonder if all they're 'verifying' is the key id? > You are not done completely.The DS for your new key has been published in .edu tld. But there is still a DS record for your old KSK there that must be removed. You can check the status here: http://dnsviz.net/d/k-state.edu/dnssec/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVxcipAAoJECKEz6pWghImqBwP/A+ExDiOZKrMOP9zIPYNwokn YH8vuIodl3I69tVFBT2S7LdzflhH22kl7+lY4QI7W5aV2RtbANI73MdhDC1ppq1r UxmWyV3eHpHvp4Eh3Z7AC4rHrpmVAEkEj7XAHQQ6jvQt2dogRoSWlPFyh1CsNNUX Vo6xIbBjI1e5sCqObl8JA4in7INrKaMfgTLai7FIyHChpYdbc8/UvJxfMGTPwDyi 5tRzoNj4Zg8WUMrmWfJdmS6cZ3VghZFve9xn8cEI1eVXmUWcgCbIvAS09yr167gA 5ZH0E2I4o91Gs+IXTs46BsQ48xTqt4PXT5ReFcwPkmFZ2Lts+17skV5QVqgfNqHs 8ZfzmXnhGXXdjK9Pba/i0E+fCP3yJERGvqyNMY0MbLjN17JQjCcQ8WsubOpgKcP6 Ga9AyTl9+1NAuQ2qGxfucfPLwGKCD4H9ReYRaBqSJ+zd/gZGgXvwTx+43GpcoWMR Fxvd4Mb1Oy8RJizRX83s0ePhZthHDBUoWhL7tg5MpX1ukSS2DeWmt8eTE5ruH33b /67l
Re: do not stupidly delete ZSK files
Lawrence K. Chen, P.Eng. wrote: > On 2015-07-31 06:33, Tony Finch wrote: > > > > The DNSSEC records come from the zone data like any other records. You > > don't need any special DNSSEC configuration to act as a secondary for a > > signed zone - it just works. > > Is that the case now? I recall when I was initial deploying DNSSEC, DLV > required that all my nameservers respond the same. > > We use NSEC3 on our zones, but at the time our network operator's nameservers > didn't support NSEC3, so were absent from their responses. Had to delay until > they upgraded their servers (something about needing to upgrade from 5 to 6 > first), before we could go DNSSEC. Yes, your secondaries need code to implement DNSSEC but they don't need any special DNSSEC configuration. Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire, South Utsire: Southwesterly 4 or 5, backing southerly 5 or 6, occasionally 7 for a time in Viking and North Utsire. Slight or moderate, occasionally rough later in Viking. Rain later. Good, occasionally poor later. ___ 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
how to compile bind 9.10 with --with-libjson option
Hi guys , any one can give me a tip about it?
I downloaded bind-9.10.2-P3 package.
OS is a Centos 2.6.32-504.23.4.el6.x86_64.
while trying
./configure --with-openssl --enable-threads --with-libxml2 --with-libjson
It complains about xml and json libraries.
xml is solved installing
yum install libxml2-devel
but after install
yum install json-c
it still complains about :
checking for json library... configure: error: include/json{,-c}/json.h
not found.
Im reading some docs but can not find the proper way.
Any clue about it would be pretiated.
Regards.
Leandro.
___
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
Access external hosts with internal split DNS resolver
Hi All,
This question I imagine comes up regularly – I see online there are
several potential solutions so thought it best to see what the accepted
common practice is.
I have configured an internal BIND 9.6 server to act as a split DNS
resolver for an internal (home) network. It uses forwarding for public
host DNS lookups.
From my named.conf file (excerpt):
acl homenet { 192.168.1.0/24; };
options {
allow-query { homenet; };
directory "/var/named";
forwarders { 121.98.0.1; 121.98.0.2; }; // external DNS servers
forward first;
};
zone "mydomain.co.nz" IN {
type master;
file "zone.mydomain.co.nz";
allow-update { none; };
};
In my zone.mydomain.co.nz file I've defined my internal hosts:
$TTL604800
@ IN SOA mydomain.co.nz. admin.mydomain.co.nz. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
; NS record is the hostname of the BIND server
IN NS bind-server
; A records are for internal resources
dmsIN A 192.168.1.2
cmsIN A 192.168.1.4
xmpp IN A 192.168.1.6
Internal lookups to dms.mydomain.co.nz for example work just fine. My
question is: how best to configure lookups to Internet-facing hosts
defined in my domain registrar's public DNS zone file, while retaining
the use of the internal DNS server for hosts on my internal network?
In practice, with a host on my internal network configured to use the
internal BIND server, this is what I see:
- lookups to dms.mydomain.co.nz are fine
- lookups to www.mydomain.co.nz fail, where www.mydomain.com is my
public webserver defined in my domain registrar's zone file
- lookups to www.mydomain.co.nz work only if the host is configured to
use the public DNS server
Any advice please and pointers on how to best approach this would be
appreciated :)
--
Dave Koelmeyer
http://blog.davekoelmeyer.co.nz
GPG Key ID: 0x238BFF87
___
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: Access external hosts with internal split DNS resolver
On 09/08/15 16:44, Dave Koelmeyer wrote: > - lookups to www.mydomain.co.nz fail, where www.mydomain.com is my > public webserver defined in my domain registrar's zone file Correction: this should obviously read "lookups to www.mydomain.co.nz fail, where www.mydomain.co.nz is my public webserver defined in my domain registrar's zone file". -- Dave Koelmeyer http://blog.davekoelmeyer.co.nz GPG Key ID: 0x238BFF87 ___ 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: Access external hosts with internal split DNS resolver
Add www.mydomain.co.nz to your internal zone, that is one common way to deal with it. With BIND you can keep the common records in a separate file and use "include" statement to avoid double entry. > On Aug 9, 2015, at 12:50 AM, Dave Koelmeyer > wrote: > >> On 09/08/15 16:44, Dave Koelmeyer wrote: >> >> - lookups to www.mydomain.co.nz fail, where www.mydomain.com is my >> public webserver defined in my domain registrar's zone file > > Correction: this should obviously read "lookups to www.mydomain.co.nz > fail, where www.mydomain.co.nz is my public webserver defined in my > domain registrar's zone file". > > > -- > Dave Koelmeyer > http://blog.davekoelmeyer.co.nz > GPG Key ID: 0x238BFF87 > ___ > 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: Access external hosts with internal split DNS resolver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 09.08.2015 um 06:58 schrieb Josh Kuo: > Add www.mydomain.co.nz to your internal zone, that is one common > way to deal with it. With BIND you can keep the common records in a > separate file and use "include" statement to avoid double entry. > > > >> On Aug 9, 2015, at 12:50 AM, Dave Koelmeyer >> wrote: >> >>> On 09/08/15 16:44, Dave Koelmeyer wrote: >>> >>> - lookups to www.mydomain.co.nz fail, where www.mydomain.com is >>> my public webserver defined in my domain registrar's zone file >> >> Correction: this should obviously read "lookups to >> www.mydomain.co.nz fail, where www.mydomain.co.nz is my public >> webserver defined in my domain registrar's zone file". >> >> >> -- Dave Koelmeyer http://blog.davekoelmeyer.co.nz GPG Key ID: >> 0x238BFF87 ___ 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 Using the same domain with two seperate contents is just bad practice. And when you decide to use DNSSec sometime in the future it will leave your home network inoperable, because the trust delegations won't work anymore. You should use the zone mydomain.co.nz only for public internet hosts and create a subdomain for your homenetwork, e.g. home.mydomain.co.nz. If the hostnames at home don't need to be resolvable in the internet you don't even have to delegate the subdomain. Just create that zone on your home nameserver and make sure your entire home network uses this server as a resolver. That way your home clients will be able to lookup hosts in both zones while clients on the internet will only see the public zone. And concerning your "forward first" statement, you should change that to "forward only". If your ISPs resolvers can't find a hostname there's no need for your home-resolver to try again. It can just accept that the host is not resolvable and pass on the NXDOMAIN to the client. This will speed up you name resolution considerably. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVxvVWAAoJECKEz6pWghImK7IP/A0/NShUls9cRKvAJIEHFuBY 9MEDHSBCG6+kj2xuEmkr6el5ciDR9gT8YYHchYGSsZOSL84B+fpmiCAaRdogCEzt MN/jGJivR9Xm902VvzAPzz0zRG0VkQA3C+iyW/VNaqzHIDWOi+iemx/sQR2dKbJb deeruvUZYOw95OOgXvOvsI7vmmKfoZ/RmLFyF4fj2zWRLK/1hzuA/GfkpxkXnnnR 2S2wVMKv2ewPQ8gyEpjEGJ2rSKhWVF/ybk1wDpDD4Kg4HgYuJ+uvxwb9vD34TNsV 2zbKNfnXv69jcHhtPacwbJsFdB8kFM2rXbrhBPZ5CeH+gQ2RDUNKJkeJTDM+Ziem DdPTr7SHxdJGXMGJQq+MTet2NQMsDwAtym0gDSl0fFxBRD9x4L+1azpqucwftEjf +Nl563AsoO7eCgE58w2tJMOtC/b8nGK3YvNOobM87jh/RhoDVQYsTET1iTCxff59 rZVLhyGMwwvC+dVD5OiB90506qDww7gzPmCD1EijDNXiYfYu/GMpIGK13ePcAjoU mzqCyYKaWbXW5fp86ndB6aaTa1PcrFw+WjeygNvF/nQg4JR7yqfA+1/xGPdG/IWy 45IEm1t/lRu7NNpHpw53rVOpNLmLbQLUPE/AbwULkFV6ghOrLsb907545euZkIp/ jZy3D+T7qXH65RwkPZuO =NHT5 -END PGP SIGNATURE- ___ 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
