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
Paradigm shift for error handling
All, On Wed, 2011-11-16 at 13:18 +, Evan Hunt wrote: > > can we have a paradigm shift from ISC please? instead of falling over > > dead with insist/assert, please bleat a warning and drop the problematic > > issue on the floor instead and press on with business. many BIND DoS > > attacks (and zone typos) are very effective for just this reason. > > This is in fact one of the goals of BIND 10. It's a bit old now, but I blogged about this a couple of years ago: http://www.isc.org/community/blog/200910/software-robustness-and-bind-10 In BIND 10 we're using the approach outlined there. Unfortunately neither of the techniques described make sense in BIND 9. 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, 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 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: Linux issue with make test failures, 9.9.2-P1
Jeff, On Wednesday, 2012-12-05 09:27:10 -0500, Jeff Earickson 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 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: lame-servers: error (FORMERR) resolving [something]
Daniele,
On Tuesday, 2013-01-08 09:49:57 +0100,
Daniele 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: 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 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: what do you use for logging?
All, On Friday, 2013-01-18 10:01:49 +, "Niall O'Reilly" 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: Performance impact of a large ACL list.
Augie, On Monday, 2013-02-04 19:01:38 -0600, "Jeremy C. Reed" 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: Difference between multiple NS and NS having multiple A
Mark & Alexander, On Monday, 2013-02-18 08:43:32 +1100, Mark Andrews wrote: > > In message > , > 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: Configure error - BIND10, 1.0.0 on Mac OS X 10.8.2
James, On Monday, 2013-02-25 13:56:58 +1100, James Brown wrote: > > On 23/02/2013, at 9:44 AM, JINMEI Tatuya / 神明達哉 > wrote: > > > At Sat, 23 Feb 2013 09:30:55 +1100, > > James Brown wrote: > > > >> Received an error running configure on Mountain Lion: > >> > >> ./configure > >> checking for a BSD-compatible install... /usr/bin/install -c > >> checking whether build environment is sane... yes > >> checking for a thread-safe mkdir -p... ./install-sh -c -d > > [...] > >> checking for C++ compiler default output file name... > >> configure: error: in `/Users/jlbrown/Downloads/bind10-1.0.0': > >> configure: error: C++ compiler cannot create executables > >> See `config.log' for more details. > >> > >> Have installed the latest version of Xcode. > > > > Looks like you don't even have C/C++ compilers. Have you installed > > "Command Line Tools" via Xcode? > > > > You may also want to check this: > > http://bind10.isc.org/wiki/SystemNotesMacOSXMountainLion > > > > --- > > JINMEI, Tatuya > > Internet Systems Consortium, Inc. > > Followed the instructions on the page of the wiki. Successfully did > the ./configure command (as per the page) but 'make' fails with: > > encode/base_n.cc:266: instantiated from ‘static std::string > isc::util::encodeBaseNTransformer BaseZeroCode, Encoder, Decoder>::encode(const std::vector char, std::allocator >&) [with int BitsPerChunk = 4, > char BaseZeroCode = '0', Encoder = > boost::archive::iterators::base16_from_binary::EncodeNormalizer, > 4, 8, unsigned char>, unsigned char>, Decoder = > boost::archive::iterators::transform_width::DecodeNormalizer, > char>, 8, 4, char>]’ encode/base_n.cc:412: instantiated from > char>here /usr/local/include/boost/archive/iterators/transform_width.hpp:144: > char>error: no ‘operator++(int)’ declared for postfix ‘++’, trying > char>prefix operator instead make[5]: *** [base_n.lo] Error 1 > char>make[4]: *** [all-recursive] Error 1 make[3]: *** > char>[all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 > char>make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 It looks like this might be an issue added to the Mountain Lion install notes over the weekend: The latest version of HomeBrew as of this writing (February 23, 2013) installs Boost 1.53.0. Unfortunately, it doesn't work with the release candidate version of BIND 10 as reported in: http://bind10.isc.org/ticket/2764 Until this ticket is resolved, you'll need to apply the proposed patch by hand before building BIND 10: % cd bind10-1.0.0 % curl -o - http://bind10.isc.org/raw-attachment/ticket/2764/base_n.diff | patch -p1 Alternatively, you could use an older version of Boost by downloading from http://www.boost.org/ and extracting it somewhere. You'll need to specify the path to your local Boost header files using the --with-boost-include ./configure option. Please go ahead and try that patch and let us know if it works. 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: BIND roadmap
William, On Thursday, 2013-02-28 11:19:01 +1100, Mark Andrews wrote: > > In message > , > 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: spf ent txt records.
Hugo, On Wednesday, 2013-03-13 11:33:35 +, hugo hugoo 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: BIND9 statistics-server: JSON?
On Fri, 15 Feb 2013 06:57:10 +0100
Jan-Piet Mens 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:
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
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 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
