<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body><div><div style="font-family: Calibri,sans-serif; font-size: 11pt;">Hi, when it happen, what log of bind did you see? </div></div><div dir="ltr"><hr><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">From: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:hungnx15@viettel.com.vn">Xuan Hung</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Sent: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">8/1/2014 9:57 AM</span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">To: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Subject: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">RE: bind-users Digest, Vol 1902, Issue 2</span><br><br></div>Dear Partner !<br>I think this problem of me, need have version new of Bind.<br>I think resolver of Bind.9.9.5 have problem when response for customer.<br>If recusive client of My DNS increase to 4000 then resolver response servfail.<br><br><br>Thanks./.<br>============%%-<br>Nguyễn Xuân Hùng<br>0084-966581518<br>P.ISP– TT CNTT – VTNet.<br><br><br>-----Original Message-----<br>From: bind-users-bounces@lists.isc.org [mailto:bind-users-bounces@lists.isc.org] On Behalf Of bind-users-request@lists.isc.org<br>Sent: Friday, August 01, 2014 2:51 AM<br>To: bind-users@lists.isc.org<br>Subject: bind-users Digest, Vol 1902, Issue 2<br><br>Send bind-users mailing list submissions to<br> bind-users@lists.isc.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> https://lists.isc.org/mailman/listinfo/bind-users<br>or, via email, send a message with subject or body 'help' to<br> bind-users-request@lists.isc.org<br><br>You can reach the person managing the list at<br> bind-users-owner@lists.isc.org<br><br>When replying, please edit your Subject line so it is more specific than "Re: Contents of bind-users digest..."<br><br><br>Today's Topics:<br><br> 1. rndc (was: Re: Reload BIND ...) (/dev/rob0)<br> 2. Re: rndc (Reindl Harald)<br> 3. Re: rndc (Kevin Darcy)<br> 4. Re: rndc (/dev/rob0)<br> 5. Re: rndc (Reindl Harald)<br> 6. Re: rndc (and now nsupdate too) (/dev/rob0)<br> 7. Re: rndc (and now nsupdate too) (Reindl Harald)<br> 8. Re: rndc (and now nsupdate too) (Kevin Darcy)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 31 Jul 2014 10:41:30 -0500<br>From: /dev/rob0 <rob0@gmx.co.uk><br>To: bind-users@lists.isc.org<br>Subject: rndc (was: Re: Reload BIND ...)<br>Message-ID: <20140731154130.GG23739@harrier.slackbuilds.org><br>Content-Type: text/plain; charset=us-ascii<br><br>On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote:<br>> i am doing reloads of named with "killall -HUP named" just because i <br>> disabled rndc completly for security reasons and configurations are <br>> generated with own software only needs named to reload<br><br>Hmm, rndc is securable. You don't have to open it to the Internet; typically you'd just bind it on 127.0.0.1. Then your rndc key will further secure it against system users. Your OS can probably give extra protective layers by firewalling it, such as this Linux<br>example:<br><br>iptables -vA OUTPUT -p tcp --dport 953 -m owner \<br> \! --gid-owner wheel -j REJECT<br><br>(This forces root and other wheel members to "chgrp wheel" before they can use rndc, as an extra inconvenience.)<br><br>Another option is to use a UNIX domain socket, which, of course avoids the network altogether.[1]<br><br>You're losing a lot of new features without rndc. This is a "throwing out the baby with the bathwater" sort of solution. Sure, this is what you are familiar with and what works for you, but to disable rndc isn't good advice for readers of this list. ISC is moving on.<br><br>See Bv9ARM.ch06.html#controls_statement_definition_and_usage and rndc-confgen(8).<br><br><br>[1] Unfortunately it is not clear to me how to access the socket<br> with rndc. The one time I tried it, I gave up and stuck with<br> that with which I am familiar. ISC moved on, but if the<br> documentation did, I don't see it. :)<br>--<br> http://rob0.nodns4.us/<br> Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:<br><br><br>------------------------------<br><br>Message: 2<br>Date: Thu, 31 Jul 2014 17:56:08 +0200<br>From: Reindl Harald <h.reindl@thelounge.net><br>To: bind-users@lists.isc.org<br>Subject: Re: rndc<br>Message-ID: <53DA6718.30907@thelounge.net><br>Content-Type: text/plain; charset="windows-1252"<br><br><br><br>Am 31.07.2014 um 17:41 schrieb /dev/rob0:<br>> On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote:<br>>> i am doing reloads of named with "killall -HUP named" just because <br>>> i disabled rndc completly for security reasons and configurations <br>>> are generated with own software only needs named to reload<br>> <br>> Hmm, rndc is securable. You don't have to open it to the Internet; <br>> typically you'd just bind it on 127.0.0.1. Then your rndc key will <br>> further secure it against system users. Your OS can probably give <br>> extra protective layers by firewalling it, such as this Linux <br>> example:<br>> <br>> iptables -vA OUTPUT -p tcp --dport 953 -m owner \<br>> \! --gid-owner wheel -j REJECT<br>> <br>> (This forces root and other wheel members to "chgrp wheel" before <br>> they can use rndc, as an extra inconvenience.)<br>> <br>> Another option is to use a UNIX domain socket, which, of course <br>> avoids the network altogether.[1]<br>> <br>> You're losing a lot of new features without rndc. This is a <br>> "throwing out the baby with the bathwater" sort of solution. Sure, <br>> this is what you are familiar with and what works for you, but to<br>> disable rndc isn't good advice for readers of this list. ISC is <br>> moving on<br><br>don't get me wrong but if someone creates *any* bind configuration<br>and zone-files with self developed software there are no features<br>rndc could provide and so disable something you don't use is the<br>way to go instead make is secure with other switches<br><br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: signature.asc<br>Type: application/pgp-signature<br>Size: 246 bytes<br>Desc: OpenPGP digital signature<br>URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140731/45b1c349/attachment-0001.bin><br><br>------------------------------<br><br>Message: 3<br>Date: Thu, 31 Jul 2014 12:11:40 -0400<br>From: Kevin Darcy <kcd@chrysler.com><br>To: bind-users@lists.isc.org<br>Subject: Re: rndc<br>Message-ID: <53DA6ABC.4060106@chrysler.com><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br>On 7/31/2014 11:56 AM, Reindl Harald wrote:<br>><br>> Am 31.07.2014 um 17:41 schrieb /dev/rob0:<br>>> On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote:<br>>>> i am doing reloads of named with "killall -HUP named" just because<br>>>> i disabled rndc completly for security reasons and configurations<br>>>> are generated with own software only needs named to reload<br>>> Hmm, rndc is securable. You don't have to open it to the Internet;<br>>> typically you'd just bind it on 127.0.0.1. Then your rndc key will<br>>> further secure it against system users. Your OS can probably give<br>>> extra protective layers by firewalling it, such as this Linux<br>>> example:<br>>><br>>> iptables -vA OUTPUT -p tcp --dport 953 -m owner \<br>>> \! --gid-owner wheel -j REJECT<br>>><br>>> (This forces root and other wheel members to "chgrp wheel" before<br>>> they can use rndc, as an extra inconvenience.)<br>>><br>>> Another option is to use a UNIX domain socket, which, of course<br>>> avoids the network altogether.[1]<br>>><br>>> You're losing a lot of new features without rndc. This is a<br>>> "throwing out the baby with the bathwater" sort of solution. Sure,<br>>> this is what you are familiar with and what works for you, but to<br>>> disable rndc isn't good advice for readers of this list. ISC is<br>>> moving on<br>> don't get me wrong but if someone creates *any* bind configuration<br>> and zone-files with self developed software there are no features<br>> rndc could provide and so disable something you don't use is the<br>> way to go instead make is secure with other switches<br>This thread started with "I need a way to force named to re-scan for <br>interfaces". Since that *is* a "feature[] that rndc could provide" it <br>seems like enabling rndc in a secure way is a good fit for the <br>requirement that was raised.<br><br>kill -HUP is way more disruptive than necessary for a mere interface <br>scan. It's overkill.<br><br> - Kevin<br><br><br>------------------------------<br><br>Message: 4<br>Date: Thu, 31 Jul 2014 13:51:29 -0500<br>From: /dev/rob0 <rob0@gmx.co.uk><br>To: bind-users@lists.isc.org<br>Subject: Re: rndc<br>Message-ID: <20140731185129.GH23739@harrier.slackbuilds.org><br>Content-Type: text/plain; charset=us-ascii<br><br>On Thu, Jul 31, 2014 at 12:11:40PM -0400, Kevin Darcy wrote:<br>> kill -HUP is way more disruptive than necessary for a mere <br>> interface scan. It's overkill.<br><br>Furthermore, on a server with lots of zones, it could cause a DoS <br>while zones are reloading, and named is unable to answer.<br>-- <br> http://rob0.nodns4.us/<br> Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:<br><br><br>------------------------------<br><br>Message: 5<br>Date: Thu, 31 Jul 2014 20:58:50 +0200<br>From: Reindl Harald <h.reindl@thelounge.net><br>To: bind-users@lists.isc.org<br>Subject: Re: rndc<br>Message-ID: <53DA91EA.102@thelounge.net><br>Content-Type: text/plain; charset="windows-1252"<br><br><br>Am 31.07.2014 um 20:51 schrieb /dev/rob0:<br>> On Thu, Jul 31, 2014 at 12:11:40PM -0400, Kevin Darcy wrote:<br>>> kill -HUP is way more disruptive than necessary for a mere <br>>> interface scan. It's overkill.<br>> <br>> Furthermore, on a server with lots of zones, it could cause a DoS <br>> while zones are reloading, and named is unable to answer<br><br>agreed - loading of our currently 522 zones takes 1 second<br>and the maintaining cronjobs have 5 minutes difference on<br>slave and master<br><br>i did not pretend it's a perfect solution in every environment<br>but it is suiteable for many and so a valid opportunity<br><br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: signature.asc<br>Type: application/pgp-signature<br>Size: 246 bytes<br>Desc: OpenPGP digital signature<br>URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140731/60bf99bf/attachment-0001.bin><br><br>------------------------------<br><br>Message: 6<br>Date: Thu, 31 Jul 2014 14:08:48 -0500<br>From: /dev/rob0 <rob0@gmx.co.uk><br>To: bind-users@lists.isc.org<br>Subject: Re: rndc (and now nsupdate too)<br>Message-ID: <20140731190848.GI23739@harrier.slackbuilds.org><br>Content-Type: text/plain; charset=us-ascii<br><br>On Thu, Jul 31, 2014 at 05:56:08PM +0200, Reindl Harald wrote:<br>> Am 31.07.2014 um 17:41 schrieb /dev/rob0:<br>> > On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote:<br>> >> i am doing reloads of named with "killall -HUP named" just <br>> >> because i disabled rndc completly for security reasons and <br>> >> configurations are generated with own software only needs<br>> >> named to reload<br>> > <br>> > Hmm, rndc is securable. You don't have to open it to the<br>snip<br>> > You're losing a lot of new features without rndc. This is a <br>> > "throwing out the baby with the bathwater" sort of solution. <br>> > Sure, this is what you are familiar with and what works for<br>> > you, but to disable rndc isn't good advice for readers of<br>> > this list. ISC is moving on<br>> <br>> don't get me wrong but if someone creates *any* bind<br>> configuration and zone-files with self developed software<br><br>... that someone is almost surely doing it wrong. "Zone files"?<br><br>> there are no features rndc could provide and so disable<br>> something you don't use is the way to go instead make is<br>> secure with other switches<br><br>The proper tool to manage named configuration and operation, and <br>which in the best Unix ethic is well suited for automation, is <br>rndc(8).<br><br>The proper tool to manage zone data is nsupdate(8). Likewise well <br>suited for automation.<br><br>Unfortunately, it seems that no one with an adequate understanding of <br>BIND has written and released a good management frontend. Too many <br>of them are still wallowing around in zone file editing rather than <br>nsupdate and (as it seems from this thread) sending of signals rather <br>than rndc.<br>-- <br> http://rob0.nodns4.us/<br> Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:<br><br><br>------------------------------<br><br>Message: 7<br>Date: Thu, 31 Jul 2014 21:19:48 +0200<br>From: Reindl Harald <h.reindl@thelounge.net><br>To: bind-users@lists.isc.org<br>Subject: Re: rndc (and now nsupdate too)<br>Message-ID: <53DA96D4.7060602@thelounge.net><br>Content-Type: text/plain; charset="windows-1252"<br><br><br><br>Am 31.07.2014 um 21:08 schrieb /dev/rob0:<br>> On Thu, Jul 31, 2014 at 05:56:08PM +0200, Reindl Harald wrote:<br>>> don't get me wrong but if someone creates *any* bind<br>>> configuration and zone-files with self developed software<br>> <br>> ... that someone is almost surely doing it wrong. "Zone files"?<br>> <br>>> there are no features rndc could provide and so disable<br>>> something you don't use is the way to go instead make is<br>>> secure with other switches<br>> <br>> The proper tool to manage named configuration and operation, and <br>> which in the best Unix ethic is well suited for automation, is <br>> rndc(8).<br>> <br>> The proper tool to manage zone data is nsupdate(8). Likewise well <br>> suited for automation.<br>> <br>> Unfortunately, it seems that no one with an adequate understanding of <br>> BIND has written and released a good management frontend. Too many <br>> of them are still wallowing around in zone file editing rather than <br>> nsupdate and (as it seems from this thread) sending of signals rather <br>> than rndc<br><br>zone file *editing*?<br><br>sorry, no, i developed 2008 a interface to create all zone files based<br>on database records, write the complete zone content in a main table<br>with a textfiled and a second textfiled where translation for NAT/WAN<br>zones happens and so there is and never was a reason to *edit* a<br>zone file<br><br>it is created from scratch when changes in a zone happen and cronjobs<br>only pull zones with the "updated-field" set to 1<br><br>that infrastructure provides a stable API for mailserver and other<br>backends and at the end the realted zone is created from scratch<br><br>only the fact having a 1:1 NAT and only edit records once to feed<br>internal and external nameservers with one action and the fact you<br>can change global properties like TTL if not overriden per domain<br>and change A-records in any zone base on our own domain working<br>like a CNAME but still be an A record justifies that<br><br>6 years for some hundret domains as auth nameserver proves me right<br><br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: signature.asc<br>Type: application/pgp-signature<br>Size: 246 bytes<br>Desc: OpenPGP digital signature<br>URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140731/3a22c622/attachment-0001.bin><br><br>------------------------------<br><br>Message: 8<br>Date: Thu, 31 Jul 2014 15:50:49 -0400<br>From: Kevin Darcy <kcd@chrysler.com><br>To: bind-users@lists.isc.org<br>Subject: Re: rndc (and now nsupdate too)<br>Message-ID: <53DA9E19.3070604@chrysler.com><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br>On 7/31/2014 3:08 PM, /dev/rob0 wrote:<br>> On Thu, Jul 31, 2014 at 05:56:08PM +0200, Reindl Harald wrote:<br>>> Am 31.07.2014 um 17:41 schrieb /dev/rob0:<br>>>> On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote:<br>>>>> i am doing reloads of named with "killall -HUP named" just<br>>>>> because i disabled rndc completly for security reasons and<br>>>>> configurations are generated with own software only needs<br>>>>> named to reload<br>>>> Hmm, rndc is securable. You don't have to open it to the<br>> snip<br>>>> You're losing a lot of new features without rndc. This is a<br>>>> "throwing out the baby with the bathwater" sort of solution.<br>>>> Sure, this is what you are familiar with and what works for<br>>>> you, but to disable rndc isn't good advice for readers of<br>>>> this list. ISC is moving on<br>>> don't get me wrong but if someone creates *any* bind<br>>> configuration and zone-files with self developed software<br>> ... that someone is almost surely doing it wrong. "Zone files"?<br><div>[The entire original message is not included.]</div></body></html>