Re: ERROR : - writeable file 'data/udalgurijudiciarygov.hosts': already in use: /etc/nicnet2007.govdomain:15424 - loading configuration: failure
On Mon, Aug 03, 2015 at 10:36:25PM -0500, Lawrence K. Chen, P.Eng. wrote: > This unfortunately looks like the thread for me to jump on to > > I missed installing the last two 9.9...-p# patches, first time I > built everything and was pretty much ready to do it, and then > forgot all about it due to health issues. More recent one...I had I hope you're well now. > got it built for Solaris x64 and was about to work on building it > for Solaris SPARC when the most recent one appeared. This one > carried a much strong get things patched (to me at first, then > higher ups started jumping around...) It's good that you have deployed the fix for CVE-2015-5477. Those who are ignorant or foolish would say this shows the problems with free software. But that's opposed to the truth: these security reports are the strength of free software. Anyone can hack at it looking for bugs. And then those bugs get fixed. Who knows what bugs lurk inside black-box proprietary solutions? Worse, who knows if they'd be fixed? Security is in openness, standing up to the light of scrutiny. > But, it turned out to be a huge mess to upgrade. > > The first time I ran into this error, were some really old mistakes > where the admin had copy and pasted a bunch of similar zones...and > missed adjusting some of the files. Since on the master side they > all come from the same fileit probably didn't cause any > noticeable problems for the slaves or clients. > > However, install upgrade on our master server...knocked it out, so > I'm here looking to see what the proper fix for my situation is. This seems to be a bug fix (not allowing named to share writeable files) which has brought a lot of broken configurations out. Oops. Basically, no two slave zones (even nominally the same zone, in a different view) should EVER share the same file. Master zones can get away with file sharing, but ONLY if named does not write to the file (no allow-update, update-policy, nor auto-dnssec.) > Looking for a valid easy fix here ;) Partly because coming soon > they're going to demolish the DNS infrastructure that I got saddled > with and feel like I done a pretty good job at re-engineering it to > meet all the demands of it. But, I'm the last legacy unix systems > administrator here Sad. There's nothing "legacy" about Unix, though. Sounds like the salesmen are winning out over the technicians, in terms of getting management to set policy. > Anyways...the problem is because we had turned out existing master > server into doing split/stealth (started out stealth...) DNS, while > having it continue to serve as slave to delegated subdomains. So > that those subdomains are propagated to our external facing slave > servers. > > So that's where the problem comes inthe internal authoritative+ > nameservers having the master collect secondary zone data from > them...on the Internal view. But, then having to send that > information to nameservers that hit the external view of the > master. The way to select a different view on the master is to use TSIG keys. https://kb.isc.org/article/AA-00295/ > So, until a few hours agoit was include a file containing all > the delegated (sub)domains into both viewscausing both sides to > be working off of the same file. It would require some reworking of things, but you might be interested in the new BIND 9.10 feature of "in-view" zone option. This lets you literally include a zone from another view. See BIND 9 ARM chapter 6, "zone Statement Definition and Usage", for details. > WHich seemed to work fine. As only one side is getting updates, > the other side is just to feed our outside facing slaves. Well, > this update wouldn't go for that. > > So, cloning the file and doing a global search and destroythe > external view is looking zone files in a directory that is emtpy, > while the internal side continus as is. > > To have something for the external nameservers to transfer > (hopefully), I'm doing a regular sync of the file 'sec' to 'ext'. > > Not totally sure that's workingbut nothing filing up logs > about it. > > So, is what I did something that'll hold...or is there an easy > proper solution to this? Slave zones should be transferred using DNS. In a stealth master case, you need to populate also-notify lists, but perhaps in your case you can share some of that configuration with global or view level settings. (Better than having to set everything per zone.) > To hold us/me over until they decide if its going to be > BlueCat or Infoblox that replaces everything. IIUC both of those are BIND under the hood. :) > Sadly, I missed both presentations due to other issuesmore sad > because I found my "named.iner" shirt, which I was going to wear to > the second presentation ;) Haha, I have one of those also. Really cool. :) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in th
correction
On Tue, Aug 04, 2015 at 07:14:38AM -0500, /dev/rob0 wrote: > It would require some reworking of things, but you might be > interested in the new BIND 9.10 feature of "in-view" zone option. > This lets you literally include a zone from another view. See > BIND 9 ARM chapter 6, "zone Statement Definition and Usage", for > details. I meant to specify to look in a BIND 9.10 version of the ARM for this. You won't find it in 9.9 and earlier. An online version of the ARM for 9.10 can be found here: http://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.html -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ 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.8 named_stats parser
Hello , guys , im thinking about getting my bind statistics on cacti. Im looking for some parser script but so far I can not get anyone for my version, witch is 9.8. Is something around there ? If not I will need to deploy by my self ... then of course will share it. 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
Re: bind 9.8 named_stats parser
On Tue, Aug 04, 2015 at 04:01:56PM -0300, Leandro wrote: > Hello , guys , im thinking about getting my bind statistics > on cacti. Im looking for some parser script but so far I can > not get anyone for my version, witch is 9.8. I guess by "named_stats", you mean the file which is written for "rndc stats". (By default that's called "named.stats" and found inside the directory specified in your named.conf(5) options.) I'd recommend against that. It's a relic of the past. Consider instead the statistics-channels statement: http://ftp.isc.org/isc/bind9/cur/9.8/doc/arm/Bv9ARM.ch06.html#statschannels Consider also moving to a supported BIND version. In particular, BIND 9.10 might be of interest, with upgraded statistics-channels functionality: https://kb.isc.org/article/AA-01123/ > Is something around there ? > If not I will need to deploy by my self ... then of > course will share it. There too, if you're doing things the old way on abandoned old software versions, I wouldn't expect to find much interest. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ 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
Negation in view match-clients ACL doesn't work?
Folks,
This has been a real mystery and haven't been able to find a good
explanation for the behavior. For a simple example I have two views setup and I
want to differentiate access based on queries originating from 127.0.0.1.
In my FIRST ATTEMPT I just negated the IP address, but that didn't
work. The first view never matched. In the SECOND ATTEMPT I simply added
"any" AFTER the negation and that worked?
I read the ARM, can someone explain? Many Thanks!
FIRST ATTEMPT: Fails - no clients can see external_zones.
view "default-test" {
match-clients { ! 127.0.0.1; }; // thought this would match anyone but
127.0.0.1
zone "." {
type hint;
file "db.cache";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "db.127.0.0.0";
};
include "external_zones.txt";
};
view "default" {
match-clients { any; };
zone "." {
type hint;
file "db.cache";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "db.127.0.0.0";
};
include "internal_zones.txt";
};
SECOND ATTEMPT: Succeeds, only external clients can see external_zones.
view "default-test" {
match-clients { ! 127.0.0.1; any; }; // Why must I add any?
..
John Murtari - jm5...@att.com
Ciberspring
office: 315-944-0998
cell: 315-430-2702
___
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: Negation in view match-clients ACL doesn't work?
The short answer is that that is how address-match-lists work: a non-negated
match allows access, a negated match denies access, and if there is *no* match,
access is denied. The only real reason to use a negated match, therefore, is
when what you're negating is a subset of something later in the
address-match-list.
You do realize, I hope, that you could just change the order of the views and
then you wouldn't need any form of negation (earlier one matches 127.0.0.1,
later one matches "any").
- Kevin
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of MURTARI, JOHN
Sent: Tuesday, August 04, 2015 4:19 PM
To: bind-users@lists.isc.org
Subject: Negation in view match-clients ACL doesn't work?
Folks,
This has been a real mystery and haven't been able to find a good
explanation for the behavior. For a simple example I have two views setup and I
want to differentiate access based on queries originating from 127.0.0.1.
In my FIRST ATTEMPT I just negated the IP address, but that didn't
work. The first view never matched. In the SECOND ATTEMPT I simply added
"any" AFTER the negation and that worked?
I read the ARM, can someone explain? Many Thanks!
FIRST ATTEMPT: Fails - no clients can see external_zones.
view "default-test" {
match-clients { ! 127.0.0.1; }; // thought this would match anyone but
127.0.0.1
zone "." {
type hint;
file "db.cache";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "db.127.0.0.0";
};
include "external_zones.txt";
};
view "default" {
match-clients { any; };
zone "." {
type hint;
file "db.cache";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "db.127.0.0.0";
};
include "internal_zones.txt";
};
SECOND ATTEMPT: Succeeds, only external clients can see external_zones.
view "default-test" {
match-clients { ! 127.0.0.1; any; }; // Why must I add any?
..
John Murtari - jm5...@att.com
Ciberspring
office: 315-944-0998
cell: 315-430-2702
___
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: DNSSec KSK problem
In message , Heiko Richter writes:
> Hi!
>
> I'm hoping someone here can help me with a problem in my DNSSec
> configuration.
>
> I'm running Bind 9 in Debian Jessie and just finished configuring it
> with DNSSec for my zones. Everything including automatic key rollover
> for the ZSKs is working, except for a slight anomaly with my KSKs:
>
> For some reason the KSK isn't only used to sign the ZSKs, but also to
> sign the zone. My server obviously signs the "normal" records with the
> ZSK and the KSK as you can see on this diagnostic site:
> http://dnsviz.net/d/heikorichter.org/dnssec/
>
> Strangely for the TLD and the root zone the same flags are set on their
> keys (257 for KSK and 256 for ZSK) and their servers seem to do it
> right. Their KSKs are only signing the ZSK and their ZSKs are used to
> sign the zone.
>
> How can I force Bind to that same behaviour?
>
> Here is my Options-Clause:
> options {
> allow-query {
> any;
> };
> allow-recursion {
> loopback;
> v1;
> v2;
> };
> auth-nxdomain no;
> directory "/var/cache/bind";
> disable-empty-zone yes;
> dnssec-enable yes;
> dnssec-validation yes;
> edns-udp-size 1460;
> empty-zones-enable no;
> forwarders { };
> hostname "v1.heikorichter.org";
> ixfr-from-differences no;
> listen-on {
> any;
> };
> listen-on-v6 {
> any;
> };
> max-refresh-time 7200;
> max-retry-time 1800;
> max-udp-size 1460;
> min-refresh-time 900;
> min-retry-time 600;
> minimal-responses no;
> notify yes;
> preferred-glue ;
> provide-ixfr no;
> random-device "/dev/urandom";
> recursion yes;
> request-ixfr no;
> rrset-order {
> order random;
> };
> server-id "v1.heikorichter.org";
> sig-validity-interval 2400;
> statistics-file "/etc/bind/stats";
> transfer-format one-answer;
> version "Get Lost Pal";
> zone-statistics yes;
> };
>
> Command used to generate the KSK:
> dnssec-keygen -r /dev/urandom -f KSK -a ECDSAP384SHA384 \
> -P now -A +100 -R none -I none -D none \
> -K /etc/bind/dyn/heikorichter.org heikorichter.org
>
> Command used to generate the ZSK:
> dnssec-keygen -r /dev/urandom -3 -a ECDSAP256SHA256 \
> -P +2592000 -A +2678400 -R none -I +5443200 -D +5529600 \
> -K /etc/bind/dyn/heikorichter.org heikorichter.org
Well you are using 2 algorithms (ECDSAP256SHA256 and ECDSAP384SHA384)
and you only have a single key per algorithm so named signs all the
RRsets in the zone with both keys.
> ___
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: ERROR : - writeable file 'data/udalgurijudiciarygov.hosts': already in use: /etc/nicnet2007.govdomain:15424 - loading configuration: failure
On 2015-08-04 07:14, /dev/rob0 wrote: On Mon, Aug 03, 2015 at 10:36:25PM -0500, Lawrence K. Chen, P.Eng. wrote: This unfortunately looks like the thread for me to jump on to I missed installing the last two 9.9...-p# patches, first time I built everything and was pretty much ready to do it, and then forgot all about it due to health issues. More recent one...I had I hope you're well now. While, I have finally got a partial diagnosis of a rare disease for which there is no treatment or cure (SCA), has at least lifted that burden (now if only I can make all the bills of getting there to go away...) Perhaps at some point I'll see if specific identification is possible, to look for possible clinical trials...though most I seem targeted to the more common types, which I'm negative for (not surprising as a cluster of family members...while I'm alone among my relatives...) got it built for Solaris x64 and was about to work on building it for Solaris SPARC when the most recent one appeared. This one carried a much strong get things patched (to me at first, then higher ups started jumping around...) It's good that you have deployed the fix for CVE-2015-5477. Those who are ignorant or foolish would say this shows the problems with free software. But that's opposed to the truth: these security reports are the strength of free software. Anyone can hack at it looking for bugs. And then those bugs get fixed. Who knows what bugs lurk inside black-box proprietary solutions? Worse, who knows if they'd be fixed? Security is in openness, standing up to the light of scrutiny. Kind of like a while back, there was the TLS POODLE CVE that only affected F5's. Which was problematic as support was allowed to expire on our older but still only production F5 (which will reach EoSD at the end of this year...) And, I was having trouble getting the hotfix to install via the web interface. I eventually found how to do updates from the command line on devcentral and got the HF installed a month before we got the units back on support (though just in time for the primary unit to fail...requiring two RMAs to resolve...) I recall back when a CVE had pushed me to upgrade from EOL 9.7.7 to 9.9.2-P1...the day before I was to leave for LISA. I had thought it odd that somebody was asking about whether a patch would be released for 9.6, didn't realize at the time that it was ESV. Though as I recall there was something about required me to upgrade from 9.6 to 9.7 before going live with DNSSEC? Further recall suggests it was something to do with DLV? Which now I wan to figure out how to remove. I have an insecure delegation that is using a wildcard in the subdomain...its a contracted mass mailing service, which seems to require cause it to try the DLV so it can generate NSEC3 records for the wildcard? Forget if I ever finished reporting it... thought I saw them while doing the upgrades, but can't locate them now. Solution was turn off dlv (dnssec-lookaside no;) Couple months ago, I finally nuked our DLV records (after the compromise incident...in April) Wonder now if I should've published new KSK that way. As I KSK with our registrar still hasn't been updated...and the old KSK is now showing as revoked as it nears the end of its life during our normal KSK rollover window (July-ish) A contractor that was working on getting GTM setup to replace parts of thingshe wants to copy the private key from master server to GTM (both are in our datacenter), so I send him details on how to track them down our our master serveror multiple emails of increasing detail on how to find them. Where upon he copies them into an email and replies all to a large number of outside contacts. Including the outside consultant has been trying to direct him through the CUI, but he's opened up the CUI to let the outside consultant in...don't know if he also gave him the administrator password or not. Right now I've only change one letter, though probably should put on my creativity cap and come up with a new complex but mnemonic password. Though in recovering my password to our f5configbackupVM, it has triggered a C2 response that prevents the GUI side from updating the daemon side's database...which is where the F5 admin passwords are stored. At least it does backups, though would be nice if it would report failures at least...and certificate reports (usually about old certs I've forgotten to remove, though thought I saw that newer F5 does sync deletions now.) The important thing was to have configuration backups of our F5's, since there had been a number of times former onsite contractor had needed, or almost, them. Just noticed the variation is timestamps between the generations of rrl.log. Seems I got slammed July 28-29 But, it turned out to be a huge mess to upgrade. The first time I ran into this error, were some really old mistakes where the admin had co
Re: DNSSec KSK problem
Am 05.08.2015 um 06:15 schrieb Mark Andrews:
> In message , Heiko Richter writes:
>> Hi!
>>
>> I'm hoping someone here can help me with a problem in my DNSSec
>> configuration.
>>
>> I'm running Bind 9 in Debian Jessie and just finished configuring it
>> with DNSSec for my zones. Everything including automatic key rollover
>> for the ZSKs is working, except for a slight anomaly with my KSKs:
>>
>> For some reason the KSK isn't only used to sign the ZSKs, but also to
>> sign the zone. My server obviously signs the "normal" records with the
>> ZSK and the KSK as you can see on this diagnostic site:
>> http://dnsviz.net/d/heikorichter.org/dnssec/
>>
>> Strangely for the TLD and the root zone the same flags are set on their
>> keys (257 for KSK and 256 for ZSK) and their servers seem to do it
>> right. Their KSKs are only signing the ZSK and their ZSKs are used to
>> sign the zone.
>>
>> How can I force Bind to that same behaviour?
>>
>> Here is my Options-Clause:
>> options {
>> allow-query {
>> any;
>> };
>> allow-recursion {
>> loopback;
>> v1;
>> v2;
>> };
>> auth-nxdomain no;
>> directory "/var/cache/bind";
>> disable-empty-zone yes;
>> dnssec-enable yes;
>> dnssec-validation yes;
>> edns-udp-size 1460;
>> empty-zones-enable no;
>> forwarders { };
>> hostname "v1.heikorichter.org";
>> ixfr-from-differences no;
>> listen-on {
>> any;
>> };
>> listen-on-v6 {
>> any;
>> };
>> max-refresh-time 7200;
>> max-retry-time 1800;
>> max-udp-size 1460;
>> min-refresh-time 900;
>> min-retry-time 600;
>> minimal-responses no;
>> notify yes;
>> preferred-glue ;
>> provide-ixfr no;
>> random-device "/dev/urandom";
>> recursion yes;
>> request-ixfr no;
>> rrset-order {
>> order random;
>> };
>> server-id "v1.heikorichter.org";
>> sig-validity-interval 2400;
>> statistics-file "/etc/bind/stats";
>> transfer-format one-answer;
>> version "Get Lost Pal";
>> zone-statistics yes;
>> };
>>
>> Command used to generate the KSK:
>> dnssec-keygen -r /dev/urandom -f KSK -a ECDSAP384SHA384 \
>> -P now -A +100 -R none -I none -D none \
>> -K /etc/bind/dyn/heikorichter.org heikorichter.org
>>
>> Command used to generate the ZSK:
>> dnssec-keygen -r /dev/urandom -3 -a ECDSAP256SHA256 \
>> -P +2592000 -A +2678400 -R none -I +5443200 -D +5529600 \
>> -K /etc/bind/dyn/heikorichter.org heikorichter.org
>
> Well you are using 2 algorithms (ECDSAP256SHA256 and ECDSAP384SHA384)
> and you only have a single key per algorithm so named signs all the
> RRsets in the zone with both keys.
>
>> ___
>> 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
Thanks for the advice, didn't know KSK and ZSK ahd to be the same algorithm.
My original thought was use a stronger algorithm for the KSK as it
doesn't get rolled over that often.
Anyhow, I changed it now and everything works find. Thanks!
___
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
