Re: Generic reasons for recursive performance not to peg CPU?

2014-01-13 Thread Leonard Mills

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 should have quoted Sten's context.  If the recursive answer 

contains additional data, that may contributing to the time spent
awaiting bandwidth for the delivery of outbound packets.




On Sunday, January 12, 2014 6:11 PM, Doug Barton do...@dougbarton.us 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.

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: Is this scenario possible?

2014-01-13 Thread Matus UHLAR - fantomas

In article mailman.1996.1389470377.20661.bind-us...@lists.isc.org,
Blason R blaso...@gmail.com wrote:

Pertaining to the same discussion. Can someone validate below zone files
and named.conf files? What I wanted to achieve here is; I wanted to make
mail.example.com as my sub domain and give them A record so that I could
load balance the traffic on LBs since my LBs are offering inbuilt DNS server

[...]

##
#
# master.example.com
##

[...]

$ORIGIN mail.example.com.

@ IN  NS ns3.mail.example.com.

; the next name server points to ns1 in the example.com zone above
  IN  NS ns1.example.com.
; sub-domain address records for name server only - glue record
ns3   IN  A  20.20.20.21 ; 'glue' record

[...]

#
# mail.example.com zone file
#
#

$TTL 2d ; default TTL = 2 days
$ORIGIN mail.example.com.
@  IN SOA   ns3.mail.example.com.
hostmaster.mail.example.com. (
   2003080800 ; serial number
   2h ; refresh =  2 hours
   15M; update retry = 15 minutes
   3W12h  ; expiry = 3 weeks + 12 hours
   2h20M  ; minimum = 2 hours + 20 minutes
   )
; sub-domain name servers
  IN  NS ns3.mail.example.com.


On 11.01.14 15:33, Barry Margolin wrote:

You also need:

   IN  NS ns1.example.com.


to be more precise it's not needed, but recommended, since
- it's recommended to have more NS records 
- the delegation NS appears in parent zone

- NS records from the zone prevail over delegation and if
  ns3.mail.example.com fails and resolving DNS has authoritative NS cached,
  it won't query ns1.example.com. until the authoritative NS expires.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Quantum mechanics: The dreams stuff is made of. 
___

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-13 Thread Matus UHLAR - fantomas

On Jan 11 2014, Joseph S D Yao wrote:
(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.


On 12.01.14 15:04, Chris Thompson wrote:

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


why? If it's not supposed to work, it should give NXDOMAIN instead of fake
record (including localhost).

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The only substitute for good manners is fast reflexes. 
___

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-13 Thread Leonard Mills
You previously showed your unsuccessful rndc command.  It contained:
 'type slave; file slaves/zone.local;

Unless you override the defaults, that says:
 use the file /var/named/slaves/zone.local.

So it appears that the directory /var/named/slaves was not writable.

Hth,
Len





On Sunday, January 12, 2014 10:12 PM, Georgy Goshin georgy.gos...@gmail.com 
wrote:
 
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 ma...@isc.org


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

___
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-13 Thread Matus UHLAR - fantomas

On 12.01.14 17:16, Doug Barton wrote:
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.


Besides the zone and recursion definitions, the same configuration?
DLZ in use by any way ?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Support bacteria - they're the only culture some people have. 
___

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-13 Thread Georgy Goshin
Seems previously I made some mistake when tried to make writable
/var/named... Currently chmod g+w /var/named resolved the problem.

Thanks to all!


2014/1/13 Leonard Mills l...@yahoo.com

 You previously showed your unsuccessful rndc command.  It contained:
  'type slave; file slaves/zone.local;

 Unless you override the defaults, that says:
  use the file /var/named/slaves/zone.local.

 So it appears that the directory /var/named/slaves was not writable.

 Hth,
 Len



   On Sunday, January 12, 2014 10:12 PM, Georgy Goshin 
 georgy.gos...@gmail.com wrote:

 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 ma...@isc.org


 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



___
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-13 Thread Phil Mayers

On 13/01/14 01: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.


I'm wondering if it's something tediously low-level like scheduler, 
issues relating to concurrency/locking of the cache, and so on. 
Presumably bind has some method to protect the cache from simultaneous 
updates that requires some degree of locking - perhaps you're loading it 
to a degree that you're bumping into lock waiting?


What's the (relative) size of the auth vs. pre-loaded recursive cache?

A generic CPU tracing tool (e.g. perf under Linux) might be able to 
tell you the hotspots in the two cases, and any differences might be 
instructive.

___
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


specifics of downgrading from rpz2 (3rd party patch) - rpz1 (in Bind release) ?

2014-01-13 Thread pgndev
We'd deployed named v9.9.4 with the patches from

BIND9 RRL and RPZ Patches
 http://ss.vix.su/~vjs/rrlrpz.html
...
Multiple Zone Response Policy Zone (RPZ2) Speed Improvement
with Response Rate Limiting (RRL)
BIND9 9.9.4
file rpz2+rl-9.9.4.patch, version 9.9.4-rpz2+rl.13269.14
Version 9.9.4 includes RRL with ./configure --enable-rrl
so this patch only affects RPZ.

so as to have

named -v
BIND 9.9.4-rpz2+rl.13269.14 (Extended Support Version)

noting today's release

Subject: BIND 9.9.4-P2 is now available
Date: Mon, 13 Jan 2014 16:48:35 + (UTC)
...
Introduction

   BIND 9.9.4-P2 is the latest production release of BIND 9.9.

   BIND 9.9.4 is an Extended Support Version of BIND

and no info on the 3rd-party rpz2 patches since the 9.9.4 release,
we're downgrading to rpz1, as included in the supported Bind release
(ack'd that rpz2 will be 'in' 9.10.x).

Can anyone clarify specifically the *diff* between rpz1, as in the
Bind9 release, and rpz2?  Particularly, which specific
features/capabilities I need to unwind to get back to 'just' rpz1?

I'll poke at it until it behaves, but would appreciate some
better-informed guidance.
___
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: specifics of downgrading from rpz2 (3rd party patch) - rpz1 (in Bind release) ?

2014-01-13 Thread Phil Mayers

On 13/01/2014 17:27, pgndev wrote:


Can anyone clarify specifically the *diff* between rpz1, as in the
Bind9 release, and rpz2?  Particularly, which specific
features/capabilities I need to unwind to get back to 'just' rpz1?


IIRC there's no syntax/feature difference. Rather, RPZ2 is a set of 
(significant) performance enhancements for the case of 1 RPZ zone, 
which is common as most people have a local whitelist/blacklist in front 
of their upstream RPZ feed.


Personally the lack of RPZ2 is keeping us on older bind 9.9 releases for 
the moment, until I have time to investigate how hard (or not) it is to 
bring the patches forward.

___
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: specifics of downgrading from rpz2 (3rd party patch) - rpz1 (in Bind release) ?

2014-01-13 Thread pgndev
 IIRC there's no syntax/feature difference.

Quickly attempting to use the existing, same named config that I've
been using with 9.9.4-rpz2+rl.13269.14 with a new build of 9.9.4-P2
release, 9.9.4-P2 refuses to boot.  I've not (yet) gotten any farther
than that ...

... shouldn't be tough to figure out.  but, SOMETHING is different/incompatible

 ... performance enhancements ...

right, which is why we 'all' switched in the 1st place

 the lack of RPZ2 is keeping us on older bind 9.9 releases for the moment

we'd done the same thru the entire 9.9.4-P1 cycle.

with the P2 cycle, supported/up-to-date bind9 is more important to us.
 especially given the radio silence re: 3rd party patch dev.  if/when
rpz2 appears in bind9-releases, we'll (re)emjoy its benefits.  ymmv.
___
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-13 Thread Eduardo Bonsi
 On 1/10/14, 8:36 PM, Joseph S D Yao wrote:
 There seems to be a pile of misconceptions here.

Joseph,

1. No one from this list that answered to my original question actually showed 
any degree of confusion, (including myself). There were only observations on 
the subject, nothing more...

2. All your (6) observations on the subject are very basic 101 stuff and have 
very little to do with what I originally asked. I have not contested or said 
what a person can and cannot do with their own Bind configuration. 

3. What I originally asked and what I also suspected to be the answer, (has 
already been answered here), so I am not going to repeat myself in those things 
you actually missed.

Thanks for your views!

Eduardo
 

 
--
Eduardo Bonsi
System Admin
BEARTCOMMUNICATIONS
beart...@pacbell.net



 From: Joseph S D Yao j...@tux.org
To: bind-users@lists.isc.org 
Sent: Friday, January 10, 2014 8:36 PM
Subject: Re: Sites that points their A Record to localhost
 

On 2014-01-10 15:01, Eduardo Bonsi wrote:
...
 It seems like they have their domain configuration A Record pointed
 to the localhost. We all know that the localhost is not routable
 outside of the internet. Therefore I am sure their website cannot
 resolve out of the 127.0.0.1.
 In addition to that, it is possible that this is happening only here
 because of the way our Server configuration is setup in the OS X to
 bring the resolver to the localhost first before it can go out to the
 distributed domains/websites through the Apache conf.
...


There seems to be a pile of misconceptions here.

(1) There is no requirement at all that a domain name have an A record. It does 
not have to resolve to an IP address at all.  It only has to have an SOA record 
and an NS record (preferably more than one); and not even that, if it is a 
subdomain that is not a separate zone.

(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.  
Incidentally, there is no requirement that the domain name refer to a mail 
server, either (which used to be common before the Web existed), or to an FTP 
server, or to a Telnet server, or to a nuclear reactor control device.  Or to 
anything.

(3) However, any name MAY resolve to any IP address, routable or not.  That 
doesn't mean there's anything useful, or even related to that domain, at that 
IP address.

(4) 127.0.0.1 is the IP equivalent of the English language word me. If I 
say, me, I am referring to myself.  If you say, me, you are referring to 
yourself.  It cannot be used to direct anyone to somewhere else.  In fact, some 
use it to deflect probers AWAY from themselves, and back on the prober's own 
server.  (E.g., if I wanted to probe p3net.net, my server would be probing 
itself!)

(5) 127.0.0.1 is not among the IP addresses mislabeled as unroutable. It is 
always routable.  To right here.  Well, for you, right there.

(6) Just because OS X has 127.0.0.1 as the resolver has no effect on what that 
resolver returns.  Don't confuse the concepts.

I think there were some others, but it's getting late.

Joe Yao
___
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

RHEL, Centos, Fedora rpm 9.9.4-P2

2014-01-13 Thread Carl Byington
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

http://www.five-ten-sg.com/mapper/bind contains links to the source
rpms, and build instructions.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlLUTDoACgkQL6j7milTFsH5sgCfXRrP/D54ZM88CQnOQcNDTOPA
yZ0AoIdbMDJ96Ax05qH+HqqYaw5lmoVU
=lJOC
-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


Re: Sites that points their A Record to localhost

2014-01-13 Thread Lawrence K. Chen, P.Eng.


On 01/13/14 03:43, Barry Margolin wrote:
 In article mailman.2022.1389603219.20661.bind-us...@lists.isc.org,
  Matus UHLAR - fantomas uh...@fantomas.sk wrote:
 
 On Jan 11 2014, Joseph S D Yao wrote:
 (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.

 On 12.01.14 15:04, Chris Thompson wrote:
 That would be more plausible if www.p3net.net actually resolved to
 something, rather than giving NXDOMAIN ...

 why? If it's not supposed to work, it should give NXDOMAIN instead of fake
 record (including localhost).
 
 That's his point: they're not forcing people to go to the trouble of 
 typing in www.p3net.net, because there is no such record.
 

OTOH, some of us think the notion that all websites have to begin with
www. is dated.  I want the site to work without the 'www.'  I find it
annoying that keep running into sites where only www.domain.name
works.worse are the ones where domain name alone doesn't something
else...

Though there used to be an enforced policy here, when you requested a
website name to be added to DNS, you got both with and without www forms
auto-magically.  As well as be in both our domains.

Can cause problems with sites that do SSLthey've always been known
only by one name, but since the other forms exist and somebody out of
the blue tries one ... and they typed https:// firstwell, now its
somebody's problem that it resulted in an SSL error.  Including the
person that was just following policy

Seemed to me that there are mailservers that reject mail from domains
that claim to be localhost, (or perhaps its sites like these that result
in some sites rejecting such domains?)

What's p3net.net?

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
For: Enterprise Server Technologies (EST) --  SafeZone Ally
___
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: A Few Additional Words About CVE-2014-0591

2014-01-13 Thread Lawrence K. Chen, P.Eng.
Hmmm, from what I vaguely recall from my software engineering days, was
that memcpy() didn't ever handle overlapped memory buffers and that you
should consider memmove() in such cases.

Doesn't really make sense that it should, though I think I first learned
about this during a code review.  Don't recall if I had lazily used it
once or if it was something an intern had done, but it was a co-worker
that had caught it.

On 01/13/14 13:13, Michael McNally wrote:
 Hello, Bind-Users Readers --
 
 Since you are all subscribers to bind-announce as well [You are,
 aren't you?  It's where we make announcements about security
 vulnerabilities and about new versions of BIND] you are probably
 already aware that ISC has announced CVE-2014-0591, a vulnerability
 which can cause BIND to crash while servicing certain queries against
 an NSEC3-signed zone.
 
 The official announcements can be found in bind-announce or at:
 https://kb.isc.org/article/AA-01078 and new versions of BIND which
 patch the vulnerability can be found at http://www.isc.org/downloads
 
 But we'd like to point out a few additional facts about this advisory
 which you might find relevant.
 
 1)  Security Patches Are Ending for the BIND 9.6-ESV Branch
 
 Back in 2012 we announced our intention to retire the
 9.6-ESV branch in 2013.  We previously extended the
 EOL (End of Life) date for 9.6-ESV by six months but
 those six months are almost over and the rescheduled
 EOL date for 9.6-ESV is upon us.  Unless there are
 extraordinary circumstances justifying it, 9.6-ESV will
 not receive future security patches and 9.6-ESV-R11 is
 the last version planned in the 9.6-ESV sequence.
 
 BIND 9.9 was designated an ESV version of BIND in May 2013.
 Users who require long-term support for their version of
 BIND should migrate to BIND 9.9.
 
 2)  Vulnerability to CVE-2014-0591 is OS and libc Dependent
 
 We have issued a general warning for the bug that causes
 CVE-2014-0591, because with security it is better to be
 safe than sorry, but per our developer's analysis, the
 bug (which causes an INSIST crash in name.c) can only be
 triggered on servers using a memcpy call that behave in a
 certain fashion.  This bug went undiscovered until recently
 because under most memcpy implementations the software
 behaves safely.  However, recent optimizations to glibc's
 memcpy have exposed the underlying bug on systems using
 newer versions of glibc.
 
 To date our reports of CVE-2014-0591 crashes have all
 been from Linux users using glibc version 2.18, but because
 of the multiplicity of Unix-like operating systems and
 C library variants we cannot represent all others as safe.
 The safest course of action is to patch the underlying bug
 and ensure that your server is not vulnerable regardless of
 memcpy optimizations, but we do believe that users are unlikely
 to encounter this crash on older glibc versions or on
 non-Linux operating systems that do not use glibc.
 
 Slightly more information about this is available in our
 CVE-2014-0591 FAQ and Supplemental Information article in
 the ISC Knowledge Base:  https://kb.isc.org/article/AA-01085
 ___
 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
 

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
For: Enterprise Server Technologies (EST) --  SafeZone Ally
___
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: A Few Additional Words About CVE-2014-0591

2014-01-13 Thread Evan Hunt
On Mon, Jan 13, 2014 at 04:44:22PM -0600, Lawrence K. Chen, P.Eng. wrote:
 Hmmm, from what I vaguely recall from my software engineering days, was
 that memcpy() didn't ever handle overlapped memory buffers and that you
 should consider memmove() in such cases.

Yes, that's correct, and in fact we're replacing all uses of memcpy()
with memmove() in upcoming releases.

Oddly enough, I benchmarked both routines in the newest version of
glibc on amd64, and found that memmove() consistently runs about 35%
faster than memcpy().  So it's both safer *and* faster.

On most platforms, memcpy() does work safely with overlapping buffers,
but the POSIX standard doesn't require it to do so, and you're not
supposed to rely on it.  We had a coding error that caused such a
copy, but there were no bad effects, so we missed it --  until glibc
changed their memcpy() and revealed our mistake.

(And we would've gotten away with it, too, if it wasn't for those
meddling kids.)

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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


dumping master file: tmp-xxx: open: permission denied

2014-01-13 Thread LuKreme
OK, I am getting this error dumping master file: tmp-xxx: open: permission 
denied, occasionally, on both my slave DNS servers and I can't seem to fix it.

The dns slave files are being written into /var/named/etc/namedb/slave which is 
owned by bind

8 drwxr-xr-x  2 bind  wheel  1024 Jan 13 19:46 /var/named/etc/namedb/slave

DNS changes are getting propagated to both servers from the master, so I don't 
know where the permission denied is coming from. Where is this tmp file being 
(attempted to be) written?

And why are the slave servers dumping master file in the first place?

-- 
Carlin's Third Commandment: Thou shall keep thy religion to thyself.

___
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: specifics of downgrading from rpz2 (3rd party patch) - rpz1 (in Bind release) ?

2014-01-13 Thread pgndev
On Mon, Jan 13, 2014 at 2:15 PM, Mark Andrews ma...@isc.org wrote:
 Why does the *need* to be info as the existing patches works other
 than for the version file which for the fix by hand is pretty
 obvious or you can just leave it as it is in 9.9.4-P2.

The patch devs have been silent on their site, and on this list.  NBD
-- their choice, of course.

Who, other than you, has said anything about *need*?

You're of course welcome to use/apply any undocumented/unsupported
patches you choose to.  Otoh, I choose to use as close to a release
product as I can functionally get away with.

I, personally, have zero interest in playing the lab-rat to determine
what secondary/hidden effects there _might_ be by using even an
'obvious' patch that's been, in effect, abandoned.

Tho, now that you mention it, one DOES wonder that if it's so
'obvious', why ISC is waiting until 9.10.x to include it in the code
...

In any case, my question was what the diffs are, and any hints on downgrading.

That's all taken care of, so - 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


Re: dumping master file: tmp-xxx: open: permission denied

2014-01-13 Thread Mark Andrews

In message 8919443e-8f62-48cd-8da4-9c9632fc5...@kreme.com, LuKreme writes:
 OK, I am getting this error dumping master file: tmp-xxx: open:
 permission denied, occasionally, on both my slave DNS servers and I
 can't seem to fix it.

 The dns slave files are being written into /var/named/etc/namedb/slave
 which is owned by bind

 8 drwxr-xr-x  2 bind  wheel  1024 Jan 13 19:46 /var/named/etc/namedb/slave

 DNS changes are getting propagated to both servers from the master, so I
 don't know where the permission denied is coming from. Where is this
 tmp file being (attempted to be) written?

It's trying to write the the working directory which I doubt is
/var/named/etc/namedb/slave.  I suspect you have a bad file
directive.

 And why are the slave servers dumping master file in the first place?

So the slave can start up and serve the zone content when the master
server is down.

 --
 Carlin's Third Commandment: Thou shall keep thy religion to thyself.

 ___
 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

-- 
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: specifics of downgrading from rpz2 (3rd party patch) - rpz1 (in Bind release) ?

2014-01-13 Thread Mark Andrews

In message CAHv26DioGqAy5G3_Ni_q5=0a6t3hnotvk00eo6oqh6nxoan...@mail.gmail.com
, pgndev writes:
 On Mon, Jan 13, 2014 at 2:15 PM, Mark Andrews ma...@isc.org wrote:
  Why does the *need* to be info as the existing patches works other
  than for the version file which for the fix by hand is pretty
  obvious or you can just leave it as it is in 9.9.4-P2.
 
 The patch devs have been silent on their site, and on this list.  NBD
 -- their choice, of course.
 
 Who, other than you, has said anything about *need*?

You appear to want people to supply you with a new patch because
there is a minor change in the code.  You were the one complaining
about the lack of info.  That certainly looks like you need info
to keep using the code.

and no info on the 3rd-party rpz2 patches since the 9.9.4 release,
we're downgrading to rpz1, as included in the supported Bind release
(ack'd that rpz2 will be 'in' 9.10.x).

 You're of course welcome to use/apply any undocumented/unsupported
 patches you choose to.  Otoh, I choose to use as close to a release
 product as I can functionally get away with.

Me, I'm usually running unreleased code with features that havn't even
make a alpha release.  Yes, I eat my own dog food.
 
 I, personally, have zero interest in playing the lab-rat to determine
 what secondary/hidden effects there _might_ be by using even an
 'obvious' patch that's been, in effect, abandoned.

-P's have the minimum in changes required to address the particular
security problem.  The existing patches work fine and unless you
are paying Vernon to support you he is under no obligation to respond
to you.  When the previous -P came out the advice given to the list
was just apply the patch.

 Tho, now that you mention it, one DOES wonder that if it's so
 'obvious', why ISC is waiting until 9.10.x to include it in the code
 ...

Because we broke the rule about including a chunks of new code in
a non .0 release for this and additional changes are of a level
where we would normally only add them at a .0 release.

 In any case, my question was what the diffs are, and any hints on downgrading
 .
 
 That's all taken care of, so - 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
-- 
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: specifics of downgrading from rpz2 (3rd party patch) - rpz1 (in Bind release) ?

2014-01-13 Thread pgndev
 You appear to want people to supply you with a new patch

Oh, THAT's what I wanted?  Thanks SO much for clearing that up!

 ... and unless you are paying Vernon to support you he is under no obligation 
 to respond
to you. ...

You can keep bloviating, but it still doesn't mean you have the
slightest connection to any sort of reality.

Who said anything about obligations?  Exactly which part of asking
about downgrading are you not picking up on?

( pssst! hint, hint! re-read the NBD -- their choice of course part)

Please go waste someone else's time.
___
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