Re: rndc addzone gets permission denied

2014-01-12 Thread Georgy Goshin
Mark, I've read the phrase a lot ) What't is the working directory for
named in Centos 6 installation? I already tried to chmod 777 /var/named
/etc/named /usr/lib64/bind...


2014/1/13 Mark Andrews 

>
> It is trying to create a .nzf (new zone file) file in the working
> directory.
>
> --
> 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: Generic reasons for recursive performance not to peg CPU?

2014-01-12 Thread Doug Barton

On 01/12/2014 07:30 PM, Barry Margolin wrote:

In article ,
  Doug Barton  wrote:


Thanks for the response, but you're answering a different question than
I asked. :)  The question I'm interested in is, "Why is the recursive
server not pegging the CPU?" I'm aware that there will be a difference
in qps between auth-only and recursive, but the recursive server seems
to be working a lot less hard than the auth server, and I can't figure
out why.


If the answer isn't already in cache,


The answers are all in cache. We're pre-loading the data, and only 
running queries for data that we're pre-loading.


Doug

___
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: Generic reasons for recursive performance not to peg CPU?

2014-01-12 Thread Barry Margolin
In article ,
 Doug Barton  wrote:

> Thanks for the response, but you're answering a different question than 
> I asked. :)  The question I'm interested in is, "Why is the recursive 
> server not pegging the CPU?" I'm aware that there will be a difference 
> in qps between auth-only and recursive, but the recursive server seems 
> to be working a lot less hard than the auth server, and I can't figure 
> out why.

If the answer isn't already in cache, the server has to fire off the 
recursive query, and then doesn't have to do anything until the response 
arrives.

But an auth-only server doesn't spend any time waiting for responses.

-- 
Barry Margolin
Arlington, MA
___
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: Generic reasons for recursive performance not to peg CPU?

2014-01-12 Thread Stuart Browne
Wouldn't it be something along the lines about recursive using cache-in-memory 
where the authoritative is using lookups of zone-in-memory?

The algorithms are probably different.  I've not looked at the code though.

Stuart

> -Original Message-
> From: bind-users-bounces+stuart.browne=ausregistry.com...@lists.isc.org
> [mailto:bind-users-bounces+stuart.browne=ausregistry.com...@lists.isc.org]
> On Behalf Of Doug Barton
> Sent: Monday, 13 January 2014 1:11 PM
> To: Leonard Mills; bind-users@lists.isc.org
> Subject: Re: Generic reasons for recursive performance not to peg CPU?
> 
> Thanks for the response, but you're answering a different question than
> I asked. :)  The question I'm interested in is, "Why is the recursive
> server not pegging the CPU?" I'm aware that there will be a difference
> in qps between auth-only and recursive, but the recursive server seems
> to be working a lot less hard than the auth server, and I can't figure
> out why.
> 
> Doug
> 
> 
> On 01/12/2014 06:07 PM, Leonard Mills wrote:
> > Are you allowing long answers when authoritative?  Performance
> > measurements with and without additional data in responses is measurable
> > (imo around 12% more network traffic from the replies on auth-only
> servers).
> 
> ___
> 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: rndc addzone gets permission denied

2014-01-12 Thread Mark Andrews

It is trying to create a .nzf (new zone file) file in the working
directory.

-- 
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: Generic reasons for recursive performance not to peg CPU?

2014-01-12 Thread Doug Barton
Thanks for the response, but you're answering a different question than 
I asked. :)  The question I'm interested in is, "Why is the recursive 
server not pegging the CPU?" I'm aware that there will be a difference 
in qps between auth-only and recursive, but the recursive server seems 
to be working a lot less hard than the auth server, and I can't figure 
out why.


Doug


On 01/12/2014 06:07 PM, Leonard Mills wrote:

Are you allowing long answers when authoritative?  Performance
measurements with and without additional data in responses is measurable
(imo around 12% more network traffic from the replies on auth-only servers).


___
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: Generic reasons for recursive performance not to peg CPU?

2014-01-12 Thread Leonard Mills
Are you allowing long answers when authoritative?  Performance measurements 
with and without additional data in responses is measurable (imo around 12% 
more network traffic from the replies on auth-only servers).

hth,
Len





On Sunday, January 12, 2014 5:54 PM, Doug Barton  wrote:
 
Thanks for the response, but that's not it. The auth-only responses are 
>generating a lot more traffic than the recursive.
>
>Doug
>
>
>
>On 01/12/2014 05:21 PM, Sten Carlsen wrote:
>> Wild guess: network bandwidth runs out before CPU? Why the difference, I
>> have no clue.
>>
>> On 13/01/14 02.16, Doug Barton wrote:
>>> Howdy,
>>>
>>> Without going into too much detail, doing some performance testing and
>>> am seeing a weird result. On the same systems authoritative queries
>>> will happily peg the CPU. However when running recursive queries (with
>>> a small zone, all data cached before testing) the CPU never gets above
>>> 80%. The disk is nearly inactive on both systems, and there is no
>>> swapping. Using BIND 9.9.4.
>>>
>>> Is there perhaps something obvious I'm overlooking here? Any
>>> suggestions are welcome.
>
>___
>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: Generic reasons for recursive performance not to peg CPU?

2014-01-12 Thread Doug Barton
Thanks for the response, but that's not it. The auth-only responses are 
generating a lot more traffic than the recursive.


Doug


On 01/12/2014 05:21 PM, Sten Carlsen wrote:

Wild guess: network bandwidth runs out before CPU? Why the difference, I
have no clue.

On 13/01/14 02.16, Doug Barton wrote:

Howdy,

Without going into too much detail, doing some performance testing and
am seeing a weird result. On the same systems authoritative queries
will happily peg the CPU. However when running recursive queries (with
a small zone, all data cached before testing) the CPU never gets above
80%. The disk is nearly inactive on both systems, and there is no
swapping. Using BIND 9.9.4.

Is there perhaps something obvious I'm overlooking here? Any
suggestions are welcome.


___
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: Generic reasons for recursive performance not to peg CPU?

2014-01-12 Thread Sten Carlsen
Wild guess: network bandwidth runs out before CPU? Why the difference, I
have no clue.

On 13/01/14 02.16, Doug Barton wrote:
> Howdy,
>
> Without going into too much detail, doing some performance testing and
> am seeing a weird result. On the same systems authoritative queries
> will happily peg the CPU. However when running recursive queries (with
> a small zone, all data cached before testing) the CPU never gets above
> 80%. The disk is nearly inactive on both systems, and there is no
> swapping. Using BIND 9.9.4.
>
> Is there perhaps something obvious I'm overlooking here? Any
> suggestions are welcome.
>
> Doug
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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

Generic reasons for recursive performance not to peg CPU?

2014-01-12 Thread Doug Barton

Howdy,

Without going into too much detail, doing some performance testing and 
am seeing a weird result. On the same systems authoritative queries will 
happily peg the CPU. However when running recursive queries (with a 
small zone, all data cached before testing) the CPU never gets above 
80%. The disk is nearly inactive on both systems, and there is no 
swapping. Using BIND 9.9.4.


Is there perhaps something obvious I'm overlooking here? Any suggestions 
are welcome.


Doug
___
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: rndc addzone gets permission denied

2014-01-12 Thread David Forrest

On Sun, 12 Jan 2014, Georgy Goshin wrote:


named -g too shows only received command and do not shows which permission
is denied

12-Jan-2014 19:42:48.133 received control channel command 'addzone
zone.local { type slave; file "slaves/zone.local"; masters {
172.31.199.154; }; };'
12-Jan-2014 19:43:05.826 received control channel command 'addzone
zone.local { type slave;  masters { 172.31.199.154; }; };'

Don't know what also to try (



Can you add it directly to the named.conf file and have it load?  If so it 
would indicate the trouble is in the rndc routines and not named itself. 
Dave

--
David Forrest 
St. Louis, Missouri


___
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: rndc addzone gets permission denied

2014-01-12 Thread Georgy Goshin
named -g too shows only received command and do not shows which permission
is denied

12-Jan-2014 19:42:48.133 received control channel command 'addzone
zone.local { type slave; file "slaves/zone.local"; masters {
172.31.199.154; }; };'
12-Jan-2014 19:43:05.826 received control channel command 'addzone
zone.local { type slave;  masters { 172.31.199.154; }; };'

Don't know what also to try (


2014/1/12 David Forrest 

> I slaved the root zone without a file statement in my named.conf for the
> slaved file and it worked.  I added the file statement later to my
> named.con as I wanted a local copy for quicker startup.  I think I may have
> touched the file to get it started though.  When I finally looked at it, I
> found it was binary.
>
> You might just try it without the file statement in the rndc invocation
> like this:
> rndc addzone "zone.local" '{ type slave; masters { 172.31.199.154; }; };'
>
> Dave
>
>
>
>
___
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: Sites that points their A Record to localhost

2014-01-12 Thread Chris Thompson

On Jan 11 2014, Joseph S D Yao wrote:

[...snip...]
(2) There is no requirement that a domain name refer to the Web site 
for that domain.  I personally don't like that (for no special reason), 
and neither apparently does the owner of this domain, who forces people 
to go to the trouble of typing in www.p3net.net to get to his or her Web 
site.


That would be more plausible if www.p3net.net actually resolved to
something, rather than giving NXDOMAIN ...

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: rndc addzone gets permission denied

2014-01-12 Thread David Forrest
I slaved the root zone without a file statement in my named.conf for the 
slaved file and it worked.  I added the file statement later to my 
named.con as I wanted a local copy for quicker startup.  I think I may 
have touched the file to get it started though.  When I finally looked at 
it, I found it was binary.


You might just try it without the file statement in the rndc invocation 
like this:

rndc addzone "zone.local" '{ type slave; masters { 172.31.199.154; }; };'

Dave



___
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: rndc addzone gets permission denied

2014-01-12 Thread Phil Mayers

On 12/01/14 12:17, Georgy Goshin wrote:

Selinux disabled, /var/named/slave is 770 and owned by named. Is there a


It should go without saying that wholesale disabling of SELinux, if your 
distro enables it by default, is unwise. If you must, set the specific 
daemon to disabled.


We run with SELinux enabled and have no real difficulty.


way to get any debug output to see which permission is denied?


"named -g"

However, this might not replicate the precise environment in which the 
real named is running, so be cautious about interpreting the results. 
And don't forget any other command line arguments you need.

___
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: rndc addzone gets permission denied

2014-01-12 Thread Georgy Goshin
Selinux disabled, /var/named/slave is 770 and owned by named. Is there a
way to get any debug output to see which permission is denied?
12.01.2014 11:40 пользователь "Elia Pinto"  написал:

> It is Selinux related
>
> Try ausearch -m avc for finding. Put named in permissive mode
>
> Best
> Il 12/gen/2014 00:13 "Georgy Goshin"  ha scritto:
>
>> Hi,
>>
>> CentOS, 6.5, default bind package bind-9.8.2-0.17.rc1.el6_4.6.x86_64.
>>
>> trying to add slave zone with command rndc addzone "zone.local" '{ type
>> slave; file "slaves/zone.local"; masters { 172.31.199.154; }; };'
>>
>> but getting rndc: 'addzone' failed: permission denied, nothing on the
>> logs, only received control channel command 'addzone zone.local { type
>> slave; file "slaves/zone.local"; masters { 172.31.199.154; }; };' even
>> after rndc trace 99.
>>
>> allow-new-zones yes;
>>
>> tried with chmod 777 for /var/named, /etc/named, /usr/lib64/bind but
>> nothing helps.
>>
>> please advice me a way to find why permission is denied.
>>
>>
>> thanks in advance.
>>
>> ___
>> 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: rndc addzone gets permission denied

2014-01-12 Thread Elia Pinto
It is Selinux related

Try ausearch -m avc for finding. Put named in permissive mode

Best
Il 12/gen/2014 00:13 "Georgy Goshin"  ha scritto:

> Hi,
>
> CentOS, 6.5, default bind package bind-9.8.2-0.17.rc1.el6_4.6.x86_64.
>
> trying to add slave zone with command rndc addzone "zone.local" '{ type
> slave; file "slaves/zone.local"; masters { 172.31.199.154; }; };'
>
> but getting rndc: 'addzone' failed: permission denied, nothing on the
> logs, only received control channel command 'addzone zone.local { type
> slave; file "slaves/zone.local"; masters { 172.31.199.154; }; };' even
> after rndc trace 99.
>
> allow-new-zones yes;
>
> tried with chmod 777 for /var/named, /etc/named, /usr/lib64/bind but
> nothing helps.
>
> please advice me a way to find why permission is denied.
>
>
> thanks in advance.
>
> ___
> 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: rndc addzone gets permission denied

2014-01-12 Thread Jan-Piet Mens
> but getting rndc: 'addzone' failed: permission denied, nothing on the logs,
> only received control channel command 'addzone zone.local { type slave;
> file "slaves/zone.local"; masters { 172.31.199.154; }; };' even after rndc
> trace 99.
>
> allow-new-zones yes;
>
> tried with chmod 777 for /var/named, /etc/named, /usr/lib64/bind but
> nothing helps.

named must be able to write into the directory it will create the file
in. Assuming your `directory` option is set to `/var/named`, and seeing
your `file` statement above contains `slaves/zone.local`, the path to
which named will write is

/var/named/slaves

which must be writeable by the user named is running as.

-JP
___
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