Re: RPZ and negative answers
On 04/04/2013 12:50 AM, Chris Buxton wrote: Thanks for the explanation. It seems to me this is a gap in coverage of RPZ -- the algorithm should be updated, in my opinion, to cover the case of a negative answer. AIUI it's a deliberately limited mechanism aimed at preventing resolution of harmful domains; NODATA/NXDOMAIN rewriting has caused enough controversy in the recent past that I can understand there being reluctance to extend RPZ to do it. Can you comment on the use-case? ___ 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: rate limit dns query response ...
On 04.04.13 12:25, prakash wrote: We are using bind 9.x on linux and would like to create rate limit for DNS query from any users ie 10 query per second. Can anyone guide us Note that there are no users in DNS, only clients identified by an IP. These kind of rate limiting can be done at firewall level. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Silvester Stallone: Father of the RISC concept. ___ 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: rate limit dns query response ...
From: prakash prak...@nic.in
We are using bind 9.x on linux and would like to create rate limit for DNS
query from any users ie 10 query per second. Can anyone guide us
I would:
1. read http://www.redbarn.org/dns/ratelimits
2. read the new ARM text about RRL by following the link labeled
Draft text for BIND9 Administrators Reference Manual (ARM)
on http://www.redbarn.org/dns/ratelimits
3. fetch one of the BIND releases and matching patches on the
page in the link labeled Patch files for BIND9 and then
build and install them. I would probably use BIND9 9.9.3b2.
4. add something like this to named.conf
rate-limit { responses-per-second 5; };
Vernon Schryverv...@rhyolite.com
___
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: Auto-dnssec maintain and 'continous' resigning
Thank you very much for all the bits, certainly very helpful. My problem is that this cycle of zone signing triggers zone number increases and generates dozens of NOTIFY messages and the corresponding zone transfers to all slaves within a short period of time, something which I believe is not very friendly to my gracious slave service providers. Since my signer instance does not provide public service, I would rather prefer the signing to be done in a single op and then send a single NOTIFY to slaves. Maybe my problem is 'auto-dnssec maintain', maybe I would be better off with the other options. Looking forward to your thoughts. ~Carlos On 4/3/13 7:48 PM, Mark Andrews wrote: In message 515a92a5.3020...@imperial.ac.uk, Phil Mayers writes: On 04/01/2013 07:36 PM, Carlos M. Martinez wrote: Reframing the question in more general terms... Which events trigger a zone re-sign and reload when using auto-dnssec maintain ? As someone else has already said, zone updates, signature expiration and key events. In particular, it's normal for the SOA serial to constantly increase in a zone with auto-dnssec maintain, even if nothing else happens, because the signatures will be regenerated every N days. N depends on your config, but is 0.75 * default_sig_life (30 days) by default i.e. signatures are generated every 22.5 days. Named attempts to spread out re-signing load for a zone over time even is the zone content is essentially static. It takes time to regenerate signatures so you don't want non-threaded builds to stall too long res-signing. ___ 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: Auto-dnssec maintain and 'continous' resigning
On 04/04/13 16:55, Carlos M. Martinez wrote: Thank you very much for all the bits, certainly very helpful. My problem is that this cycle of zone signing triggers zone number increases and generates dozens of NOTIFY messages and the corresponding zone transfers to all slaves within a short period of time, something which I believe is not very friendly to my gracious slave service providers. You might ask your secondary if they care. We secondary for some people, and my view is that I don't care if they send me one NOTIFY a minute and I'm constantly doing tiny IXFR - I just don't care, or see why it's a problem. But I know some people don't like it. We don't send NOTIFY to one of our secondaries for this reason, and that copy of the zone lags by 0-refresh. It's not a huge problem for me, so if you can tolerate it, notify explicit might help. Since my signer instance does not provide public service, I would rather prefer the signing to be done in a single op and then send a single NOTIFY to slaves. Maybe my problem is 'auto-dnssec maintain', maybe I would be better off with the other options. Well... you might be able to tweak the various sig-* options to bundle up the signing, but that might adversely affect other stuff. How big is the zone? You could just cron a dnssec-signzone if it's reasonably sized. ___ 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
End-user documentation for full DNSSEC automation using Bind9?
Hi, I run bind 9.9.2. I'm interested in fully automating the DNSSEC key generation/signing/rollover process. A while back, I'd used OpenDNSSEC to attempt it, but was ulitmately foiled by lack of a registrar with an API it could talk to. Since that time, IIUC, bind9's got all the tols integrated, AND I finally stubled across a registrar that actually provides a functional documented DNSSEC API: @ gkg.net. DNSSEC Delegation Signer Webservice API https://www.gkg.net/ws/ds.html I've been digging around for a step-by-step documentation of using Bind9 for DNSSEC automation, *ideally* with examples of usage with gkg.net. So far, I've been looking in all the wrong places ... lots of them. Can anyone recommend good/thorough end-user documentation for DNSSEC automation? And/or point to any examples integrating with GKG.net's API? Cheers. ___ 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
Confused about CVE-2013-2266
Hi, I am sorry for being so dense but I am confused about what to do about protecting my BIND DNS servers running 9.9.1-P4 from the regex issue. The link https://kb.isc.org/article/AA-00871 says this ... Impact: ... Intentional exploitation of this condition can cause denial of service in all authoritative and recursive nameservers running affected versions of BIND 9 [all versions of BIND 9.7, BIND 9.8.0 through 9.8.5b1 (inclusive) and BIND9.9.0 through BIND 9.9.3b1 (inclusive)]. OK ... I run 9.9.1-P4 so my DNS server could be affected by this issue. But later on in the link it says ... Solution: Compile BIND 9 without regular expression support as described in the Workarounds section of this advisory or upgrade to the patched release most closely related to your current version of BIND. These can be downloaded from http://www.isc.org/downloads/all. * BIND 9 version 9.9.2-P2 But its 9.9.2-P2 with in BIND9.9.0 through BIND 9.9.3b1? So is 9.9.2-P2 also affected? If I build from the 9.9.2-P2 tarball do I need to patch the config.h as discussed in the Workarounds section? Thanks Red ___ 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: Confused about CVE-2013-2266
It says or upgrade to the patched release most closely related to your current version of BIND then it lists the two versions to choose from. 9.9.2-P2 is fixed as is 9.9.3b2. Mark In message cahu+3owixzjjofxz90yq8zs4e0kb8sx8h6n21pg_erdyur-...@mail.gmail.com, Red Cricket writes: Hi, I am sorry for being so dense but I am confused about what to do about protecting my BIND DNS servers running 9.9.1-P4 from the regex issue. The link https://kb.isc.org/article/AA-00871 says this ... Impact: ... Intentional exploitation of this condition can cause denial of service in all authoritative and recursive nameservers running affected versions of BIND 9 [all versions of BIND 9.7, BIND 9.8.0 through 9.8.5b1 (inclusive) and BIND9.9.0 through BIND 9.9.3b1 (inclusive)]. OK ... I run 9.9.1-P4 so my DNS server could be affected by this issue. But later on in the link it says ... Solution: Compile BIND 9 without regular expression support as described in the Workarounds section of this advisory or upgrade to the patched release most closely related to your current version of BIND. These can be downloaded from http://www.isc.org/downloads/all. * BIND 9 version 9.9.2-P2 But its 9.9.2-P2 with in BIND9.9.0 through BIND 9.9.3b1? So is 9.9.2-P2 also affected? If I build from the 9.9.2-P2 tarball do I need to patch the config.h as discussed in the Workarounds section? Thanks Red -- 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: RPZ and negative answers
On Apr 4, 2013, at 1:42 AM, Phil Mayers wrote: On 04/04/2013 12:50 AM, Chris Buxton wrote: Thanks for the explanation. It seems to me this is a gap in coverage of RPZ -- the algorithm should be updated, in my opinion, to cover the case of a negative answer. AIUI it's a deliberately limited mechanism aimed at preventing resolution of harmful domains; NODATA/NXDOMAIN rewriting has caused enough controversy in the recent past that I can understand there being reluctance to extend RPZ to do it. Can you comment on the use-case? Sure. Here's an example. A company wants to halt the spread of a piece of malware that uses DNS lookups to find its CC. The malware is known to try computed domain names successively until one resolves, and then connect to the resolved address. The company has set up a honeypot server to control the malware and keep it quiescent. The company has determined the first N domains of the sequence, but does not know how to calculate the complete set of domains. Therefore, the company wants to put the known domains into an RPZ. Normal, individual zones would also work, but this would require mixing them with other data in their management system. The customer wants to keep these domains separate from other managed data. Unfortunately, because RPZ doesn't return a policy-based answer when there is no positive answer to be found out on the Internet, RPZ is not a suitable solution. Therefore, the customer is forced to create the individual zones normally, mixing them with other data in their management solution, rather than using RPZ to trap the malware into contacting the honeypot server. Chris Buxton BlueCat Networks ___ 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: RPZ and negative answers
From: Chris Buxton cli...@buxtonfamily.us A company wants to halt the spread of a piece of malware that uses DNS lookups to find its CC. ... The company has determined the first N domains of the sequence, but does not know how to calculate the complete set of domains. ... Unfortunately, because RPZ doesn't return a policy-based answer when there is no positive answer to be found out on the Internet, RPZ is not a suitable solution. Therefore, the customer is forced to create the individual zones normally, mixing them with other data in their management solution, rather than using RPZ to trap the malware into contacting the honeypot server. Why isn't it both sufficient and better to list the NS servers or NS servers for the NS servers of the evil domains? Won't NS servers for the N domains be known, espcially after the first of the N domains goes active? Vernon Schryverv...@rhyolite.com ___ 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: End-user documentation for full DNSSEC automation using Bind9?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 2013-04-04 at 12:08 -0700, pgbi...@ml1.net wrote: And/or point to any examples integrating with GKG.net's API? I have a small python script that parses /etc/named.conf looking for comments indicating zones that are registered with gkg.net, and it uploads the current set of keys using the gkg.net api. I can sanitize it this weekend and publish a link to it. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlFeYUoACgkQL6j7milTFsHhUgCfYS10W1gR5Jw5gU01Gg8w5hAw knsAniNMa6FrLECb8oEaMrMLTsog61Eg =jHZu -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
