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 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 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?
In article , Blason R 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
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
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 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 > > >>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?
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
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 > 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 > > > 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: Sites that points their A Record to localhost
In article , Matus UHLAR - fantomas 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. -- 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?
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) ?
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) ?
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) ?
> 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
> 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 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
A Few Additional Words About CVE-2014-0591
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
RHEL, Centos, Fedora rpm 9.9.4-P2
-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
On 01/13/14 03:43, Barry Margolin wrote: > In article , > Matus UHLAR - fantomas 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
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
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
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) ?
On Mon, Jan 13, 2014 at 2:15 PM, Mark Andrews 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
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) ?
In message , pgndev writes: > On Mon, Jan 13, 2014 at 2:15 PM, Mark Andrews 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) ?
> 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
