RRL probably not useful for DNS IP blacklists, was Re: New Versions of BIND are available (9.9.4, 9.8.6, and 9.6-ESV-R10)
Noel, On 2013-09-20 12:48:31 (Friday) Noel Butler noel.but...@ausics.net wrote: On Fri, 2013-09-20 at 01:59 +, Vernon Schryver wrote: plenty of delayed mail - hostname lookup failures (mostly because of URI/DNS BL's), so it certainly works as intended :) That sounds unrelated to RRL. Again, RRL affects standards compliant DNS clients no more than a 50% packet loss rate on the path from the DNS client and to the server. If your mail system suffered hostname lookup failures, then I think something else was broken. With a 50% packet loss and 3 retries you'll have about 1 in 16 lookups fail, right? If you've got enough legitimate lookups going on to trigger RRL then you're going to get lots of failures. One workaround for this is to set SLIP to 1. I know Vernon recommends against that, but personally I don't think there is any downside. Nope, either way, daemon.log was filling up with messages indicating RRL, last time I tried, Aug 29, lots of limit NXDOMAIN responses to /24 for zen.spamhaus.org , limit NXDOMAIN responses to xx/24 for xxx.net pretty much one for every DNSBL, URIBL etc used This doesn't indicate that anything actually failing for the querying hosts, just that they are issuing a lot of queries. The problem occurred within a minute of enabling RRL, and ended right after disabling RRL. on that date, log files show the version was actually BIND 9.9.4rc1 Now I've read your link, I can perhaps understand more the options and fine tune it, but bout to head out for lunch so, might pla around later this afternoon. I think the actual issue is that for DNS IP blacklists (or whitelists) RRL is probably harmful. Many or even most queries to those servers will result in the same NXDOMAIN response. This is expected and desired behavior, but RRL interprets this as potential abuse. While the fallback to TCP (combined with my recommendation of SLIP 1 above) will mean that service will continue without problem, one reason that DNS was chosen for such services is that it is very lightweight, and forcing traffic to TCP is an anti-goal. :) Probably you should disable RRL for servers that are primarily used for IP-based blacklists (or whitelists). Cheers, -- Shane signature.asc Description: 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
Re: BIND9 statistics-server: JSON?
On Fri, 15 Feb 2013 06:57:10 +0100
Jan-Piet Mens jpmens@gmail.com wrote:
As a fan of BIND's statistics-server I was tempted to see if I could
reduce the size of the data (XML) named produces by adding an option
to produce JSON. The patch [1] (which is terribly quick and dirty)
does that.
[1] https://gist.github.com/jpmens/4958763
I used to say:
snip/
But in this case I'll say:
{ text: snipped }
If I cleaned this up appropriately and attempted to add some (all?) of
the counters (I'm mostly interested in the list of zones which is why
I started with that) would there be a chance of ISC adding this to
stock BIND9? Even better: would ISC take on the work of doing it? ;-)
Evan has merged this into master, and it will go out in 9.10, sometime
later this year. (We're also putting it into our new subscription
branch, which should be available for subscription customers in a few
weeks.)
Thanks Jan-Piet!!!
--
Shane
___
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: spf ent txt records.
Hugo, On Wednesday, 2013-03-13 11:33:35 +, hugo hugoo hugo...@hotmail.com wrote: Dear all, I received the following question and I am not able to aswer as spf records are still mysterious to me. We are using BIND 9.7. Thanks in advance for your answers, Hugo, Does our DNS-server support SPF-type records? Or do we put SPF-info in a TXT-record? Ref. : Early implementations used TXT records for implementation before the new record type was commonly available in DNS software. Use of TXT records for SPF was intended as a transitional mechanism. However, according to the current RFC, RFC 4408, section 3.1.1, An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at least one type, and as such, TXT record use is not deprecated.[2] BIND does support the SPF type. Note however that the latest draft version of SPF actually deprecates SPF, and recommends using TXT records: 3.1. DNS Resource Records SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternate DNS RR types was supported in SPF's experimental phase, but has been discontinued. See Appendix A of [RFC6686] for further information. http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/?include_text=1 -- Shane ___ 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 roadmap
William, On Thursday, 2013-02-28 11:19:01 +1100, Mark Andrews ma...@isc.org wrote: In message ofbf91a47c.2e7c9f7c-on85257b1f.0049de28-85257b1f.004aa...@e1b.org, wbr...@e1b.org writes: Congrats to ISC and everyone that has worked on BIND 10! I am building new name servers and redesigning our infrastructure with an eye towards streamlining, improving security and implementing DNSSEC. I had been testing a few things with BIND 9.9.x. Now that BIND 10 is released, I am wondering which way to go. Will ISC continue to develop the BIND 9 code stream? I saw a mention of RRL being added to 9.10, but how long will development continue before hitting ESV? ISC has no specific plans to end BIND 9 development. As Mark correctly says: BIND 10 is still a way off being a replacement for BIND 9. We are missing a lot of features in BIND 10 that are present in BIND 9. However, it is not as correct to say: Development for both is still proceeding in parallel. BIND 9 is still the server to install for production. BIND 10 is more for test environments at this stage though we would like people to play with it give feedback (good or bad). If BIND 10 has the functionality that you need - authoritative-only without BIND-managed DNSSEC signing - then BIND 10 *is* production ready today. The main issue is that it is a 1.0.0 version, so does not have the history of installed bases to increase confidence. As of BIND 9.9.3, BIND 9.9 will be a extended support version. BIND 9.9.0 was released March 2012 so it will be supported until March 2016 and perhaps further as per the software support policy. https://www.isc.org/wordpress/software/software-support-policy/ Note though that as far as I can tell, few people actually use the ESV software. Please let us know if the ESV policy works for you! Finally, we are currently discussing the BIND 9 and BIND 10 roadmaps and should have something we can publish shortly. Sorry to be so mysterious about it - it's nothing weird. :) Thanks, -- Shane ___ 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: Difference between multiple NS and NS having multiple A
Mark Alexander, On Monday, 2013-02-18 08:43:32 +1100, Mark Andrews ma...@isc.org wrote: In message CABUciRkAPvEyFr1s5ygu8=kfxdflbjadauy4asb4w_kws5-...@mail.gmail.com , Alexander Gurvitz writes: Is there any practical difference between the following two: 1. example.com. NS ns1.example.com. example.com. NS ns2.example.com. ns1.example.com. A 1.1.1.1 ns2.example.com. A 1.1.1.2 2. example.com. NS ns.example.com. ns.example.com. A 1.1.1.1 ns.example.com. A 1.1.1.2 Yes. It makes fault isolation harder. I don't see much difference in the examples that Alexander submitted, except resolvers tracking the TTL of each name server separately. So, in the second case we may have the TTL of ns.example.com time out and both 1.1.1.1 and 1.1.1.2 are no longer usable for example.com at the same time. I think this is better demonstrated by a setup something like this: ns1.example.com. A 1.1.1.1 ns2.example.net. A 1.1.1.2 Versus: ns1.example.com. A 1.1.1.1 A 1.1.1.2 In the first case, since you're using different domains, you could get some fault isolation. Is there any possible difference in the resolvers behavior ? How bind9(10?) threats that ? If someone knows about not-bind DNS resolvers I'd be happy to know that too. Reason: We run a public DNS hosting. I think it would be more user-friendly if once we add more nameservers, we would just add them as A records under the same ns1/ns2, instead of advising each user to add ns3..nsX to their parent zones. This actually makes sense. Having to work with the parent can indeed be a pain. (I recently renumbered at home and had to change NS RRSET and glue with 3 different registrars... it must be horrible in any real production environment.) My own take on it would be that any extra redundancy beyond the normal 2 domain names is unlikely to outweigh the administrative hassle. So, I think Alexander's approach makes sense. :) Add some address as well. Speaking of addresses, in the interests of fault isolation, it would seem to make sense to use different names for IPv6 servers: ns1.example.com. A 1.1.1.1 ns2.example.net. A 1.1.1.2 ns3.example.org. 1:2:3:4::1 ns4.example.nl. 1:2:3:5::1 Cheers, -- Shane ___ 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: Performance impact of a large ACL list.
Augie, On Monday, 2013-02-04 19:01:38 -0600, Jeremy C. Reed jr...@isc.org wrote: On Mon, 4 Feb 2013, Augie Schwer wrote: Does anyone have any experience using a large ( 1k ) entry ACL list? Was there any performance degradation? I haven't implemented my ACL yet, but it has quickly ballooned up, and I am hoping to get some advice from others in a similar situation. It has been a few years since I researched this. (I should re-add this to my existing performance and resource usage tests.) BIND 9.5 had various ACL improvements including support for O(1) ACL processing, based on radix tree code. As one example, with 20,000 to 100,000 ACLs some of my tests for 9.4 only has around 80 to 400 qps, while the new version has around 21,000 qps. This specific change should mean that adding IP-based ACL will not slow down ACL performance. However, if you are using TSIG-based ACL then we can't store them in a radix tree, and these still scale linearly with the number of entries, IIRC. I suppose we can change this to a tree-based structure at some point if there is a real need for large TSIG-based ACL. It still won't be as fast as IP-based ACL, but it should be much faster than the simple list-based implementation we have now. Cheers, -- Shane ___ 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: what do you use for logging?
All, On Friday, 2013-01-18 10:01:49 +, Niall O'Reilly niall.orei...@ucd.ie wrote: On 18 Jan 2013, at 06:27, Jan-Piet Mens wrote: Could CLI utility be man(1) and info(1)? :-) It could, yes, but `b10-msg NNN` isn't going to break BIND 10's development budget (I hope), +1 and I feel it to be more practical than scrolling through a man page with 900+ error-messages in it. ;) I'm not sure I see the big practical advantage over 'C-S' in info or '/' in the pager invoked by man. I would see the man page as indispensible, and a bespoke utility as merely cool. Okay, I think both of these suggestions are straightforward and make sense. (Meaning a utility and a man page.) I've created tickets for them so we can make these. https://bind10.isc.org/ticket/2639 https://bind10.isc.org/ticket/2640 -- Shane ___ 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: lame-servers: error (FORMERR) resolving [something]
Daniele, It may be a simple case of your firewall not allowing any DNS queries that do not request recursion. Difficult to know. You may want to try: dig +trace www.isc.org This will follow the referrals from the root, and you can verify that this works. The next step may be to try: dig +trace +dnssec www.isc.org This will ask for DNSSEC, which will mean enabling EDNS0 and getting bigger response packets, both of which can cause problems with broken middleboxes (although BIND 9 should work even in those cases). Cheers, -- Shane On Monday, 2013-01-14 10:44:44 +0100, Daniele d.imbrog...@gmail.com wrote: What tests should I do? If I query directly an external name-server (one of the root ones or 8.8.8.8 for example) I receive the correct response. For this reason I'm inclined to think that the router doesn't block packets to/from port 53. Why should it block packets generated by BIND9? ___ 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: lame-servers: error (FORMERR) resolving [something]
Daniele,
On Tuesday, 2013-01-08 09:49:57 +0100,
Daniele d.imbrog...@gmail.com wrote:
Hi all.
Sometimes I can't resolve some addresses and, in the logs, I can find
the message in the title:
lame-servers: error (FORMERR) resolving [something]
(where `something` is the address I'm trying to resolve).
What does it means?
When acting as a recursive resolver, BIND 9 follows the chain of
delegation from the root, contacting name servers identified for each
domain on the way.
In this case, one of those name servers returned a packet that BIND 9
did not like for some reason - a FORMat ERRor. The offending server is
marked as lame since it cannot answer queries for the domain in
question.
The message should also include the IP address of the server that it is
going to at the end of the line.
And how can I resolve this problem?
In theory, you could try contacting the administrator of the server at
that IP address, and letting her know that there is some technical
problem so she can resolve it.
In practice, this is a worthless message and you should disable it in
named.conf:
logging {
category lame-servers { null; };
};
A couple of questions to everyone on the list...
1. Should ISC change the default logging for lame servers to disabled?
2. Are there other usually worthless default log messages we should
disable?
Cheers,
--
Shane
___
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: Linux issue with make test failures, 9.9.2-P1
Jeff, On Wednesday, 2012-12-05 09:27:10 -0500, Jeff Earickson jaear...@colby.edu wrote: The make test stuff is failing miserably for me on Linux (Redhat 6.3, x64) with 9.9.2-P1: Someone suggested to me: There should be *.run (maybe tests/system/*/*/*.run) files that will have the run-time log output. Cheers, -- Shane ___ 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: Improved SSL Error Logging [RT #29932]
Noel, On Thursday, 2012-12-06 11:03:24 +1000, Noel Butler noel.but...@ausics.net wrote: Hi Shane, Mark, Evan On Tue, 2012-10-16 at 08:22 +0200, Shane Kerr wrote: These changes are in our review queue now, so will go in future releases. I guess this was not pushed in? After update to 9.9.2-p1 the old logging returned, eg: Our security releases only include the specific fix, to insure that they provide the least impact on administrators. We'll be coming out with a beta for 9.9.3 next week or so which will include the changes, along with a number of other non-security fixes and (minor) features. Cheers, -- Shane signature.asc Description: 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
Re: Improved SSL Error Logging [RT #29932]
Noel, These changes are in our review queue now, so will go in future releases. Cheers, -- Shane Kerr ISC On Saturday, 2012-10-13 11:07:01 +1000, Noel Butler noel.but...@ausics.net wrote: Thanks Mark, These changes have been committed for future patch releases? Cheers On Fri, 2012-10-12 at 12:16 +1100, Mark Andrews wrote: Just drop the log level to ISC_LOG_DEBUG(1) and recompile. Search for sucessfully validated after lower casing in lib/dns/dnssec.c signature.asc Description: 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
Re: subdomain issue
Tarak, You probably meant for this to go to the bind-users list, not the bind10-users list. I have Cc'd that list here - hopefully someone can help you out. Cheers, -- Shane On Tue, 2011-11-08 at 19:22 +0530, trm asn wrote: Dear List, Please help me out to investigate the below scenario . I have one domain example.com $TTL 300 @ IN SOA ns4.example.com. postmaster.example.com. ( 200806 ; Serial Number 10800 ; Refresh after 3 hours 3600; Retry after 1 hour 604800 ; Expire after 1 week 300 ) ; Minimum TTL of 1 day ; Name servers IN NS ns4.example.com. IN NS ns2.example.com. IN NS ns1.example.com. INA203.39.45.19 INMXmail.goole.com. wwwINCNAMEexample.com. aINA203.39.45.20 bINA203.39.45.21 testINNSns1973.hostgator.com. testINNSns1974.hostgator.com. The moment I have done the rndc reload example.com, the domain and all subdomain were became not resolvable. After commenting out below entries rndc reload , all back to normal. ;testINNSns1973.hostgator.com. ;testINNSns1974.hostgator.com. Please help me out on this issue. /\ Tarak ___ bind10-users mailing list bind10-us...@lists.isc.org https://lists.isc.org/mailman/listinfo/bind10-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
