Re: Help DNS
The reasons why not to use nslookup are summarized here: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/nslookup-flaws.html I have seen ISC developers discourage from using it in tihis mailing list too. As for the SERIAL in SOA, it's just a good practice, it gives you the information about when the zone was published, and creates less problems when you transfer hosting of the domain to another nameserver. Basically yes, it's just a number, but there is no real good reason not to use the recommended format. Also note that I wrote try to, and not you absolutely must have to. -- S pozdravem, Daniel Ryšlink System Administrator Dial Telecom a. s. Křižíkova 36a/237 186 00 Praha 3, Česká Republika Tel.:+420.226204627 daniel.rysl...@dialtelecom.cz --- www.dialtelecom.cz Dial Telecom, a.s. Jednoduše se připojte --- On 08/24/2015 06:50 AM, Tim Daneliuk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/23/2015 10:05 PM, Alan Clegg wrote: Never, EVER use nslookup. Could you explain why? - -- - Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV2qJ6AAoJEMLZ2alfelsnWrQP/2ECFXKjuUkK/ZMJUv0DNwAd /K+TmGd1vpn4rLOFH063j8/fTnqzltFEXmUpx37MtUODa/BQl1rhppgdlfOrAIK5 FG1WTwVHy01g8ZXSUciPayACGW1MR+FX7d9bkmWh80GIX83RShH5YsEEkIIKsROB oOdL3/o6oJCy/MIxlr27tfWC4phe11UMBGIWs0QFa2uvWozfDov5wn6+0iiLfnOu Hn9fd7lT82GFMYJYSwgoTbxApzHAku32gm54Q3KQKhtBCGF0kg87G3sXXkRK7lpJ EA/Ch0WrRmHsWw2C6PYGcZ0UnDrXs1+5cpLai7jrMs4TLahMS6495cvp9vylC3wS N1ZqG8/GasPISvpLLlqLy5er6qEPXvaYL0K4KmQuT+v9M1ExeJcyfFMxPBbDI73k zxaNJ633ER4H6HglQ3VtWB5oUw5aERCoBHm77VNbVEjei+6GzjHujoc6BTejHv5j yKAg3wYw3SkKow2/nAmp4Of5FwtRqhYYwllvJQfVlk0BN10SffkcKVNP0gYbIzyj LsAsPy1kyy8o1u1I9SYBbtxkjoZ0hTh5N4jYlZDF0fD5ejUtZyevNQcNuBvoW1aF 5yfPi2IOLDqoHcsVQcIJVAyWugLLDopNDhkAXWXjffwXUhr4tFZ28IwURcQop/dF nXE5/iyVFMKBR5TENLxr =pubu -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 ___ 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: compile and install from source
Prefered procedure: 1) Install the ports collection via portsnap fetch and then portsnap extract (or portsnap update if already installed) 2) Go to /usr/ports/dns/bind99 and type make install Please note that after installing, you will have two versions of BIND on your system: - the default version of BIND that is installed with the system and resides in /usr/sbin/, config is in /etc/namedb. Don't try to overwrite this, it's not the right way to do it - the version installed from ports or packages that resides in /usr/local/sbin/, config is in /usr/local/etc/. That's the version you want to use. In 8.4., the default chroot for BIND is /var/named, you might want to use that. Please not that in FreeBSD 10, BIND is removed from system and replaced with Unbound as the default resolver, and the chroot in /var/named is gone, you have to make it manually. If you run Bind in chroot, you should have this in rc.conf: named_enable=YES named_flags=-t /var/named syslogd_flags=-s -l /var/named/dev/log Use the rc script /usr/local/etc/rc.d/named to start and stop the BIND process. -- S pozdravem, Daniel Ryšlink System Administrator Dial Telecom a. s. Křižíkova 36a/237 186 00 Praha 3, Česká Republika Tel.:+420.226204627 daniel.rysl...@dialtelecom.cz --- www.dialtelecom.cz Dial Telecom, a.s. Jednoduše se připojte --- On 03/30/2015 01:35 AM, @lbutlr wrote: Downloaded and compiled bind-9.9.7 (FreeBSD 8.4-RELEASE) and it built fine (./configure make make install). If I try to start named (service named start), it starts this version instead of the version in /usr/local/sbin I found this in /etc/defaults/rc,conf: named_enable=NO # Run named, the DNS server (or NO). named_program=/usr/sbin/named # Path to named, if you want a different one. named_conf=/etc/namedb/named.conf # Path to the configuration file #named_flags= # Use this for flags OTHER than -u and -c named_uid=bind# User to run named as named_chrootdir=/var/named# Chroot directory (or not to auto-chroot it) named_chroot_autoupdate=YES # Automatically install/update chrooted # components of named. See /etc/rc.d/named. named_symlink_enable=YES # Symlink the chrooted pid file named_wait=NO # Wait for working name service before exiting named_wait_host=localhost # Hostname to check if named_wait is enabled named_auto_forward=NO # Set up forwarders from /etc/resolv.conf named_auto_forward_only=NO# Do forward only instead of forward first” So I changed the path (in /etc/rc.conf) to /usr/local/sbin/named But now I get: $ /etc/rc.d/named start Starting named. /etc/rc.d/named: WARNING: failed to start named But nothing is logged in /var/log/messages For now, I am pointing back to the old 9.8.4 version. ___ 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: compile and install from source
That's not true, it's just not enabled by default, because it is a
mess to
get *right* when migrating from {8,9} to 10.
On the contrary, see the FreeBSD 10 release notes:
https://www.freebsd.org/releases/10.0R/announce.html
Quote:
- Unbound has been imported to the base system as the local caching DNS
resolver.
- BIND has been removed from the base system.
As for my rc.conf directives, they may be obsolete, but they still work.
--
S pozdravem,
Daniel Ryšlink
System Administrator
Dial Telecom a. s.
Křižíkova 36a/237
186 00 Praha 3, Česká Republika
Tel.:+420.226204627
daniel.rysl...@dialtelecom.cz
---
www.dialtelecom.cz
Dial Telecom, a.s.
Jednoduše se připojte
---
On 03/30/2015 05:13 PM, Mathieu Arnold wrote:
+--On 30 mars 2015 16:46:36 +0200 Daniel Ryslink
daniel.rysl...@dialtelecom.cz wrote:
| In 8.4., the default chroot for BIND is /var/named, you might want to use
| that. Please not that in FreeBSD 10, BIND is removed from system and
| replaced with Unbound as the default resolver, and the chroot in
| /var/named is gone, you have to make it manually.
That's not true, it's just not enabled by default, because it is a mess to
get *right* when migrating from {8,9} to 10.
| If you run Bind in chroot, you should have this in rc.conf:
|
| named_enable=YES
| named_flags=-t /var/named
Nope, you should use:
named_chrootdir=/var/named
| syslogd_flags=-s -l /var/named/dev/log
And I think that should be written as:
altlog_proglist=named
| Use the rc script /usr/local/etc/rc.d/named to start and stop the BIND
| process.
___
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: Getting Error || unable to convert errno to isc_result
Hello What uncle Google found for me: http://www.bind9.net/BIND-FAQ Quote: Q: Why do I get the following errors: general: errno2result.c:109: unexpected error: general: unable to convert errno to isc_result: 14: Bad address client: UDP client handler shutting down due to fatal receive error: unexpected error A: This is the result of a Linux kernel bug. See: http://marc.theaimsgroup.com/?l=linux-netdevm=113081708031466w=2; Kernel 2.6.32 end of support date was 6/1/2014, and if I am not mistaken, Bind 9.8 is not supported anymore either (only branches 9.9 and 9.10) I don't want to bother you with obvious answers, but IMO you should consider upgrading to supported versions of both your OS and BIND, since there were some serious security issues reported and patched lately and your vulnerable system may be at a risk. Maybe ISC people will have some solution for you, but generally, people are encouraged to keep up with the supported versions. -- Best Regards, Daniel Ryšlink System Administrator Dial Telecom a. s. Křižíkova 36a/237 186 00 Praha 3, Česká Republika Tel.:+420.226204627 daniel.rysl...@dialtelecom.cz --- www.dialtelecom.cz Dial Telecom, a.s. Jednoduše se připojte --- On 02/11/2015 01:04 PM, Md. Mahbubul Alam Reyad wrote: Hi Mukund Its bind-9.8.2-0.23 and the OS is Red Hat Enterprise Linux Server release 6.0 (kernel- 2.6.32-431.17.1.el6.x86_64) Sincerely Yours --- Md. Mahbubul Alam Reyad Assistant Manager CORE-IP Network || Technology Cell: +880 1976672281 || Skype: new_reyad www.qubee.com.bd T +88 02 8812113 || F +88 02 8812115 -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mukund Sivaraman Sent: Wednesday, February 11, 2015 5:43 PM To: Md. Mahbubul Alam Reyad Cc: bind-users@lists.isc.org Subject: Re: Getting Error || unable to convert errno to isc_result Hi Mahbubul On Wed, Feb 11, 2015 at 11:39:19AM +, Md. Mahbubul Alam Reyad wrote: Hi all Recently I am getting the following error in my DNS. Can anyone know the reason, impact solution of this error? general: error: unable to convert errno to isc_result: 92: Protocol not available general: error: socket.c:1700: unexpected error: Which version of BIND is this? What OS (and its version) are you using it on? Mukund ___ 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: Getting Error || unable to convert errno to isc_result
Okay, sorry, did not know about the backporting. Still, isn't it possible that this old bug is still present in this version of RHEL6? -- S pozdravem, Daniel Ryšlink System Administrator Dial Telecom a. s. Křižíkova 36a/237 186 00 Praha 3, Česká Republika Tel.:+420.226204627 daniel.rysl...@dialtelecom.cz --- www.dialtelecom.cz Dial Telecom, a.s. Jednoduše se připojte --- On 02/11/2015 10:32 PM, Lightner, Jeff wrote: On RHEL the kernel doesn't change within the main release (RHEL6) in this case will always be 2.6.32-xx and RHEL does the support including back porting bug and security fixes into their extended release (which isn't the same as the base kernel). They do the same thing for the BIND release they support within the main RHEL release. To go to a 3.x kernel one would have to go to RHEL7 but that isn't necessary given the way RedHat does support. Jeffrey C. Lightner Sr. UNIX Administrator DS Services of America, Inc. 2300 Windy Ridge Suite 600 N Atlanta, GA 30339 P: 678-486-3516 C: 678-772-0018 F: 678-460-3603 E: jlight...@dsservices.com -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Daniel Ryslink Sent: Wednesday, February 11, 2015 3:33 PM To: bind-users@lists.isc.org Subject: Re: Getting Error || unable to convert errno to isc_result Hello What uncle Google found for me: http://www.bind9.net/BIND-FAQ Quote: Q: Why do I get the following errors: general: errno2result.c:109: unexpected error: general: unable to convert errno to isc_result: 14: Bad address client: UDP client handler shutting down due to fatal receive error: unexpected error A: This is the result of a Linux kernel bug. See: http://marc.theaimsgroup.com/?l=linux-netdevm=113081708031466w=2; Kernel 2.6.32 end of support date was 6/1/2014, and if I am not mistaken, Bind 9.8 is not supported anymore either (only branches 9.9 and 9.10) I don't want to bother you with obvious answers, but IMO you should consider upgrading to supported versions of both your OS and BIND, since there were some serious security issues reported and patched lately and your vulnerable system may be at a risk. Maybe ISC people will have some solution for you, but generally, people are encouraged to keep up with the supported versions. -- Best Regards, Daniel Ryšlink System Administrator Dial Telecom a. s. Křižíkova 36a/237 186 00 Praha 3, Česká Republika Tel.:+420.226204627 daniel.rysl...@dialtelecom.cz --- www.dialtelecom.cz Dial Telecom, a.s. Jednoduše se připojte --- On 02/11/2015 01:04 PM, Md. Mahbubul Alam Reyad wrote: Hi Mukund Its bind-9.8.2-0.23 and the OS is Red Hat Enterprise Linux Server release 6.0 (kernel- 2.6.32-431.17.1.el6.x86_64) Sincerely Yours --- Md. Mahbubul Alam Reyad Assistant Manager CORE-IP Network || Technology Cell: +880 1976672281 || Skype: new_reyad www.qubee.com.bd T +88 02 8812113 || F +88 02 8812115 -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mukund Sivaraman Sent: Wednesday, February 11, 2015 5:43 PM To: Md. Mahbubul Alam Reyad Cc: bind-users@lists.isc.org Subject: Re: Getting Error || unable to convert errno to isc_result Hi Mahbubul On Wed, Feb 11, 2015 at 11:39:19AM +, Md. Mahbubul Alam Reyad wrote: Hi all Recently I am getting the following error in my DNS. Can anyone know the reason, impact solution of this error? general: error: unable to convert errno to isc_result: 92: Protocol not available general: error: socket.c:1700: unexpected error: Which version of BIND is this? What OS (and its version) are you using it on? Mukund ___ 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 ___ 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: Sometimes DNS does not resolv domains
Hello Investigate if it's not related to the problems with EDNS0 support and the fallback mechanism in Bind, as described in this article: https://kb.isc.org/article/AA-01219/ It's described as one of the outstanding issues of both the latest versions of bind 9.9 and 9.10: Refinements to EDNS fallback behavior in BIND 9.9.6 and 9.10.1 may prevent named (running as a recursive server) from attempting a final query using UDP without EDNS0 in some rare situations where prior queries using EDNS0 with both and TCP did not obtain usable answers. For more details see https://kb.isc.org/article/AA-01219/. I am finding a lot of these errors lately, and I cannot find out if it's related or not: 09-Feb-2015 12:36:11.904 query-errors: debug 1: client 109.80.225.36#34954 (ihned.cz): query failed (SERVFAIL) for ihned.cz/IN/ at query.c:7025 09-Feb-2015 12:36:11.904 query-errors: debug 2: fetch completed at resolver.c:3080 for ihned.cz/ in 0.000504: failure/success [domain:ihned.cz,referral:0,restart:2,qrysent:2,timeout:0,lame:0,neterr:2,badresp:0,adberr:0,findfail:0,valfail:0] I can confirm that the server sometimes fails to resolve the requesed name, returning the SERVFAIL opcode. -- S pozdravem, Daniel Ryšlink System Administrator Dial Telecom a. s. Křižíkova 36a/237 186 00 Praha 3, Česká Republika Tel.:+420.226204627 daniel.rysl...@dialtelecom.cz --- www.dialtelecom.cz Dial Telecom, a.s. Jednoduše se připojte --- On 02/08/2015 10:06 PM, Eliezer Croitoru wrote: Hey David, Do you have any logs enabled in your settings? The logs can help a lot to minimize the issues. There is a nice example of settings at: http://stackoverflow.com/a/12114139 Which can be a starter to give you more then you have now. Notice that the issue might come from something that is not in your hands at all. You can decide which channel to enable or disable. Also you can verify something in your config about dnssec. If your server is now dnssec enabled try disabling it and see what happens. Eliezer On 08/02/2015 20:35, David Woodfall wrote: Any ideas what might be causing this? Version: bind-9.9.6_P1-x86_64-1_slack14.1 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 ___ 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: Setup our OWN DNS Server
Hello, First, you have to tell us if you wish to run and maintain an authoritative DNS server (meaning a server propagating authoritative information about your domain names), or a recursive caching nameserver (a DNS server performing recursive queries on behalf of other client devices [phones, laptops, web servers, mail servers, workstations]) that cannot or should not resolve these queries by themselves. These two functions are radically different, have different requirements on hardware and bandwidth, and are really best kept separate because mixing them up causes all kinds of problems. If you want do do both, you should dedicate separate machines for the purpose. Please also note that if you want to run authoritative DNS servers, you need at least two, preferably in geografically diverse locations and different ip ranges (so that one disaster does not wipe your domain names out of existence). Some ISPs or hosting companies provide a service called slave DNS, though, allowing you to run a primary authoritative server (master), and use their server as a secondary authoritative server (slave). -- S pozdravem, Daniel Ryšlink System Administrator Dial Telecom a. s. Křižíkova 36a/237 186 00 Praha 3, Česká Republika Tel.:+420.226204627 daniel.rysl...@dialtelecom.cz --- www.dialtelecom.cz Dial Telecom, a.s. Jednoduše se připojte --- On 01/30/2015 08:35 AM, Chandran Manikandan wrote: Dear All, I have email,web and FTP server hosting on our in house with public ip on Centos 6 on our own server. But email,web,ftp dns hosting with other third party service provider. I have enough public ip to host dns server for our own. So what are the requirements to host dns server and how to setup. Could anyone guide me. ___ 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: Possible memory leak on BIND 9.10.1-P1 running on FreeBSD 10.1-RELEASE-p4 - part 2
One more comment - ad process size, I did measure the process sizes via 'top', and the excessive memory was really and without a doubt allocated by named. While the machine has only 2GB of RAM, top reported named has allocated much more than that, swap was in use and free swap was steadily diminishing. The recommend I killed the named process, all the swap was suddenly free, and top reported large amount of Free memory that was not there the moment ago. Look at this graph: http://www.mujweb.cz/nakamura/dns/leak.png The cliffs after the peaks correspond with manual restart of bind. This is how the same machine memory allocation looks after downgrading to 9.9.6 during the Sunday evening: http://www.mujweb.cz/nakamura/dns/noleak.png Note the orange parts of the graph representing the Free memory in FreeBSD memory management system - before, the Free memory was quickly consumed after each named restart, but the situation is radically different now. The server still has a steady pool of Free memory, that means memory that was never used since the restart of the named, since FreeBSD marks most of the deallocated memory as Inactive and cleans it just moments before it's needed again. That clearly means that the overall memory requirements are dramatically lower with 9.9.6, and also that these requirements do not grow with time, but remain stable on a resolver with the same volume and structure of queries, which is what one would expect. I am sorry I cannot provide the xml statistics you asked for, but the data I provided in the leakinfo.tgz archive should be sufficient to prove there is indeed a memory leak. -- Best Regards, Daniel Ryšlink System Administrator Dial Telecom a. s. Křižíkova 36a/237 186 00 Praha 3, Česká Republika Tel.:+420.226204627 daniel.rysl...@dialtelecom.cz --- www.dialtelecom.cz Dial Telecom, a.s. Jednoduše se připojte --- On 01/27/2015 06:46 AM, Mukund Sivaraman wrote: Hi Daniel On Mon, Jan 26, 2015 at 02:56:44PM +0100, Daniel Ryšlink wrote: Downgraded to BIND 9.9.6, the leak is gone, using the same named.conf, same HW, same environment. It is highly likely there is really a memory leak problem in Bind 9.10. Because many of these reports are on FreeBSD 10 in a resolver configuration, we are checking to see if we are able to reproduce it there. Meanwhile, please can you enable statistics-channels in named.conf and send us a dump of the XML statistics along with process sizes reported by ps when named grows very large? Mukund ___ 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: Possible memory leak on BIND 9.10.1-P1 running on FreeBSD 10.1-RELEASE-p4 - part 2
Hello,
I am sorry, but since I got under pressure to stabilize our main
resolver operation, I had to downgrade to BIND 9.9.6 which effectively
solved the problem (i.e. even with max-cache-size set to 0 [unlimited],
the amount of memory allocated by named reaches certain maximum and
remains stable indefinitely).
The only info I can provide is the archive containing rndc stats from
the 9.10 period:
http://www.mujweb.cz/nakamura/dns/leakinfo.tgz
Sorry about that.
--
S pozdravem,
Daniel Ryšlink
System Administrator
Dial Telecom a. s.
Křižíkova 36a/237
186 00 Praha 3, Česká Republika
Tel.:+420.226204627
daniel.rysl...@dialtelecom.cz
---
www.dialtelecom.cz
Dial Telecom, a.s.
Jednoduše se připojte
---
On 01/27/2015 11:36 AM, J. Thomsen wrote:
On Tue, 27 Jan 2015 11:16:04 +0530,Mukund Sivaraman m...@isc.org wrote:
Meanwhile, please can you enable statistics-channels in named.conf and
send us a dump of the XML statistics along with process sizes reported
by ps when named grows very large?
I run the small script below every 5 minutes in a cron job
The result can be seen at http://ns4.jth.net/bind
There is no extreme memory leak running since Jan. 7th, but memory usage is
slowly increasing from
70 MB till now 161 MB.
In any case using 161 MB RAM serving 623 small authoritative zones and rarely
any recursive lookups
seems to me wildly out of proportion.
Disk space of zone files is 5,4 MB.
The developers of BIND ought to revisit the memory usage of BIND.
#!/bin/sh
# extracts the memory usage of named into a file
touch /var/www/html/jth.net/bind/bind_rss_history.txt
RSS=`ps -aux | awk '/^named.*named/{print $6 $5}'`
NOW=`date +%Y-%m-%d %H:%M:%S`
echo $NOW $RSS | awk '{printf %10s%10s RSS %11sKb VSZ %11sKb\n,$1,$2,$3,$4}'
/var/www/html/jth.net/bind/bind_rss_history.txt
GET http://127.0.0.1:8053; /var/www/html/jth.net/bind/s`date +%F-%H-%M.xml`
exit 0
In named.conf the configuration is
statistics-channels {
inet * port 8053 allow { verytrusted; };
inet :: port 8053 allow { verytrusted; };
};
options {
zone-statistics yes;
};
- Jørgen Thomsen
___
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: recursive-clients : recommended value for a high traffic recursive nameserver
Hello, It may or may not be relevant, but it sounds similar to a problem we had to solve a few months ago. Try the following query analysis - monitor the number of recursive queries in a given moment, and when it exceeds a certain threshold, send rndc recursing to Bind and have a look on the queries. Basically, we have find out there is and ongoing attack originating from China that has the following structure - a number of bogus domains is registrered, like 345qp.com.cn, etc, then target nameservers are listed as authoritative for it, and vast botnets of infected home routers/modems are told to send bogus queries for the domain. Your resolvers will start having problems you describe when the admin of the attacked authoritative servers realizes what's going on and stops responding to queries to these domains. That means your resolvers have to wait for timeout of each and everyone of these bogus queries which in the meantime blocks an amount of memory and processing time, and it adds up rather quickly, potentially overwhelming your hardware (basically, it's a huge abnormal peak contrasting with normal operation) The solution we chose is that we identify these bogus queries (they vastly outnumber legitimate queries), and we decide to sort of blacklist the given bogus domain for an amount of time in the sense that we no longer do a recursive query for the client, but we immediately and authoritatively answer NXDOMAIN for the query. While it is a deviation from the correct behavior, it conservers the resources of the resolver, because an immediate authoritative answer takes fraction of time, memory and cpu to resolve. False positives are of course possible, but with some degree of monitoring and whitelisting problematic domains (like google.com, yahoo.com, etc.), they can be rather rare. Hope this helps, don't hesitate to ask me for details. I think it maybe relevant to your situation. -- Best Regards, Daniel Ryšlink System Administrator Dial Telecom a. s. Křižíkova 36a/237 186 00 Praha 3, Česká Republika Tel.:+420.226204627 daniel.rysl...@dialtelecom.cz --- www.dialtelecom.cz Dial Telecom, a.s. Jednoduše se připojte --- On 11/24/2014 12:37 PM, Niall O'Reilly wrote: At Sun, 23 Nov 2014 21:00:15 -0800 (PST), blrmaani wrote: Our nameservers take upto 10KQPS (mostly NOERROR type most of the time). Twice or thrice a week, I have seen upto 10% of the queries are SERVFAIL and we have started exceeding the default value of 2000 for recursive-clients settings in BIND 9.9.x. Is there a recommended value for recursive-clients option assuming huge number of SERVFAIL queries once in a 2/3 days? I'm not convinced to increase it to some arbitrary huge number 20,000 or 200,000. I am looking for answer like - if your peak SERVFAIL queries are 2000/second, then your recursive-clients value should be N. I wouldn't expect that such an answer could make sense. Exhaustion of the active recursive-clients list and the generation of responses marked SERVFAIL are most likely different symptoms of the same problem. I think you'll need to identify this problem and then determine what action to take. Your resolver seems to be dealing with queries which are unanswerable and which are arriving in a quantity sufficient to fill the recursive-clients list. This may be due to rogue clients, misconfigured authoritative servers, network problems, or some combination of these. Your logs will help identify which. I hope this helps. Niall O'Reilly ___ 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
Problems with auto-dnssec maintain on BIND 9.9.5 (latest patch, FreeBSD)
Hello,
I have the following zone definition included into named.conf:
zone example.com in {
type master;
file master/example.com;
update-policy local;
auto-dnssec maintain;
key-directory /etc/namedb/keys/;
masterfile-format text;
inline-signing yes;
};
Keys are ready in /etc/namedb/keys/, readable for the named process.
At first, when the zone was not signed at all, all that sufficed was to
do rndc loadkeys example.com, and when I later used rndc signing
-list example.com, the keys set via
dnssec-settime as active in the keys directory were displayed.
Now, the system reverted into a state where rndc signing -list
example.com states that no signing records were found. rndc loadkeys
says nothing, but the return code is 0 (success?). However, when I
export the new zone file into master/example.com, it is no longer signed
automatically as before. Manual rndc sign still work without problems,
and results in a zone correctly signed with the active keys. It's only
the auto mode that was broken.
Also. named.log for bind displays curiously frequent key events:
27-Mar-2014 08:36:01.899 general: info: zone example.com/IN (signed):
next key event: 27-Mar-2014 09:36:01.895
27-Mar-2014 08:39:01.633 general: info: zone example.com/IN (signed):
reconfiguring zone keys
27-Mar-2014 08:39:01.637 general: info: zone example.com/IN (signed):
next key event: 27-Mar-2014 09:39:01.633
27-Mar-2014 08:41:01.825 general: info: zone example.com/IN (signed):
reconfiguring zone keys
27-Mar-2014 08:41:01.829 general: info: zone example.com/IN (signed):
next key event: 27-Mar-2014 09:41:01.825
27-Mar-2014 08:48:01.447 general: info: zone example.com/IN (signed):
reconfiguring zone keys
27-Mar-2014 08:48:01.450 general: info: zone example.com/IN (signed):
next key event: 27-Mar-2014 09:48:01.447
27-Mar-2014 08:52:02.094 general: info: zone example.com/IN (signed):
reconfiguring zone keys
27-Mar-2014 08:52:02.097 general: info: zone example.com/IN (signed):
next key event: 27-Mar-2014 09:52:02.094
27-Mar-2014 09:52:02.100 general: info: zone example.com/IN (signed):
reconfiguring zone keys
Why a key event every five minutes, when TTL of the records is 6 hours?
Many thanks in advance to anyone who could possibly bring some insight
into the problem.
PS.: The name of the actual domain was obviously changed to protect our
customers.
--
Best regards,
Daniel Ryšlink
System Administrator
Dial Telecom a. s.
Křižíkova 36a/237
186 00 Praha 3, Česká Republika
Tel.:+420.226204627
daniel.rysl...@dialtelecom.cz
---
www.dialtelecom.cz
Dial Telecom, a.s.
Jednoduše se připojte
---
___
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
Problem with 9.6.2-p1
By the way, similar problem occurs in 9.6.2-p1. According to changelog,
support for RSA/SHA-256 (algorithm number 8 in dnssec-related
records) was backported into 9.6.2 from 9.7 (and indeed, 9.6.2 has no
problems with the TLDs recently signed with keys using RSA/SHA-256)
However, after upgrading to 9.6.2-p1, these very records are rejected by
the nameserver:
29-Mar-2010 09:33:59.371 config: error: itar.key:3: configuring trusted
key for 'ARPA.': algorithm is unsupported
Evidently, the RSA/SHA-256 support was removed from p1, but why? (...
accident?).
Daniel Ryslink
On Tue, 30 Mar 2010, Kevin Darcy wrote:
On 3/30/2010 3:53 PM, Markus Feldmann wrote:
Hi All,
i tried to reload my config and zones with rndc. My Bind version is BIND
9.5.1-P3. My rndc.key looks like this.
key feld-server.feldland.lan. {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret TNCrihQV8NjY6bzA5GMJIg==;
};
This is what i also got from creating the sig-key. I still included this
key into my named.conf and into dhcpd.conf.
But i get this message.
rndc: unsupported algorithm: HMAC-MD5.SIG-ALG.REG.INT
What is the Problem?
AFAIK, the only algorithm supported by rndc is hmac-md5.
-
Kevin
P.S. Why would you copy an rndc key into dhcpd.conf?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
