Re: How to properly update chroot-bind
On 27.07.15 18:28, Leandro Roggerone wrote: Hello , guys, I would like to know how to properly update my chroot bind version. I still can not get some nice doc / info about it. Im using: [root@centos-dns1 ~]# named -v BIND 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.3 running on a [root@centos-dns1 ~]# uname -a Linux centos-dns1.virtual.com.ar 2.6.32-504.23.4.el6.x86_64 #1 SMP Tue Jun 9 20:57:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Doing yum update bind-chroot is not the way. This is not a production server yet but it will be soon. yum update bind should do that. -- 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. Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... ___ 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: About CVE-2015-5477 (An error in handling TKEY queries can cause named to exit with a REQUIRE assertion failure)
On Tue, Jul 28, 2015 at 07:06:16PM -0400, Ben Croswell wrote: Is it safe to say the only vulnerable hosts would be those accepting queries from the outside world, or would this also pertain servers getting responses from the outside world with no inbound queries? I would ask where does the outside world begin? Many sites serve users with vulnerabilities. Have you ever had botnet traffic originating from your network? (I have, not fun.) Otherwise your premise is valid; the malicious query comes to your named via port 53 UDP or TCP, not as a reply from another server. But if you're thinking it's okay because you're going to deny the query, no! This happens before named gets to that point. Your nameserver must be closed to ALL potentially hostile queries. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ 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: About CVE-2015-5477 (An error in handling TKEY queries can cause named to exit with a REQUIRE assertion failure)
Is it safe to say the only vulnerable hosts would be those accepting queries from the outside world, or would this also pertain servers getting responses from the outside world with no inbound queries? On Jul 28, 2015 5:42 PM, Michael McNally mcna...@isc.org wrote: As the security incident manager for this particular vulnerability notification, I'd like to say a little extra, beyond our official vulnerability disclosure (https://kb.isc.org/article/AA-01272) about this critical defect in BIND. Many of our bugs are limited in scope or affect only users having a particular set of configuration choices. CVE-2015-5477 does not fall into that category. Almost all unpatched BIND servers are potentially vulnerable. We know of no configuration workarounds. Screening the offending packets with firewalls is likely to be difficult or impossible unless those devices understand DNS at a protocol level and may be problematic even then. And the fix for this defect is very localized to one specific area of the BIND code. The practical effect of this is that this bug is difficult to defend against (except by patching, which is completely effective) and will not be particularly difficult to reverse-engineer. I have already been told by one expert that they have successfully reverse-engineered an attack kit from what has been divulged and from analyzing the code changes, and while I have complete confidence that the individual who told me this is not intending to use his kit in a malicious manner, there are others who will do so who may not be far behind. Please take steps to patch immediately. This bug is designated Critical and it deserves that designation. ___ 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: How to properly update chroot-bind
Am 28.07.2015 um 10:56 schrieb Matus UHLAR - fantomas: but you *never ever* should only update specific packages on a RHEL/CentOS system because that is *not supported and tested* at all No? What are dependencies for, then? Or don't yum/RPM support them in the way debian does? (that is why it's quite easy to have mixed Debian... we have machine with mix of debian 5,6,7 and even 8... not that It's good idea) On 28.07.15 11:22, Reindl Harald wrote: CentOS is a RHEL clone except that there are no updates for older point releases it was multiple times statet by the maintainers on the mailing list that you have to apply *all* errata updates nothing else is supported it's not a matter of dependencies, it's just a matter of what combinations of packages are tested for regressions and the fact that there are no updates for RHEL without a good reason how does dependencies help when there was a critical bug fixed in package A which may hit your updated version of package B because the combination of that versions never was tested feel free to ignore that but you are at your own if things behave unexpected when the developers say just only use 'yum upgrade' which applies also for minor releases, when CentOS 6.7 is out there will be no single update for CentOS 6.6 packages and hence yum upgrade brings you to CentOS 6.7 in a few weeks which is from that moment on the only supported CentOS 6.x yes, this is a good explanation, I believe for the OP too. not supported can of course mean working without problems, however I agree there's no point in only updating BIND itself. Still, the OP can stick with provided BIND 9.8 that is in CentOS6, update to CentOS 7 or compile his own BIND version (and provide support for themselves) -- 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. REALITY.SYS corrupted. Press any key to reboot Universe. ___ 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
Compile Error for Bind 9.9.7P1 on Sparc based Solaris 10
Hi Just downloaded the source code for Bind 9.9.7P1 and was trying to compile on Sparc based Solaris 10but for some reason get the following errors when I run make. Have done this multiple times on Sparc Based Solaris 10 with the previous versions of Bind. Was wondering whether I am missing some setting on my Solaris 10 server or has anything changed? Any help would be appreciated. Thanks Sandeep tbl.pl -o named-symtbl2.c namedtmp2; done ; mv namedtmp2 named; rm -f namedtmp0 namedtmp1 namedtmp2 named-symtbl2.c; fi Undefined first referenced symbol in file RSA_generate_key_ex ../../lib/dns/libdns.a(opensslrsa_link.o) DSA_generate_parameters_ex ../../lib/dns/libdns.a(openssldsa_link.o) DH_generate_parameters_ex ../../lib/dns/libdns.a(openssldh_link.o) ld: fatal: symbol referencing errors. No output written to namedtmp0 collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `named' Current working directory /adminfiles/solaris10/Bind997P1/bind-9.9.7-P1/bin/named *** Error code 1 The following command caused the error: for i in named rndc dig dnssec tools tests nsupdate check confgen python nulldir; do \ if [ $i != nulldir -a -d $i ]; then \ echo making all in `pwd`/$i; \ (cd $i; make DESTDIR= all) || exit 1; \ fi; \ done make: Fatal error: Command failed for target `subdirs' Current working directory /adminfiles/solaris10/Bind997P1/bind-9.9.7-P1/bin *** Error code 1 The following command caused the error: for i in make unit lib bin doc nulldir; do \ if [ $i != nulldir -a -d $i ]; then \ echo making all in `pwd`/$i; \ (cd $i; make DESTDIR= all) || exit 1; \ fi; \ done make: Fatal error: Command failed for target `subdirs' ___ 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: How to properly update chroot-bind
Since the OP says he's not in Production yet I'd strongly advise moving on to CentOS 7 for multiple reasons. I has a new base version of BIND and also has a 3.x kernel. However, there is a learning curve because it also uses systemd rather than Sys V init. The way bind-chroot runs is significantly different than it was on RHEL6 when you got to RHEL7. (As noted CentOS versions are compiled from RHEL sources of the same versions.) As noted previously on this list the version of BIND you get with each major RHEL release (RHEL5, RHEL6, RHEL7) changes but the base version of BIND never gets updated to later BIND versions within each of these releases. Instead RedHat backports security and some enhancements into the base they started with and add their own extended versioning. This is true of CentOS because of its derivation. There is someone on this list that does compile newer versions of BIND for RHEL so if you search the archive you can find newer versions than are shipped by RHEL/CentOS. Also CentOS does have extended repositories beyond those RHEL has so you may find something newer there. CentOS by the way is not supported so if you're using CentOS vs RHEL worrying about supported shouldn't be an issue for you. (RHEL is supported if you pay for the subscriptions.) -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matus UHLAR - fantomas Sent: Tuesday, July 28, 2015 7:58 AM To: bind-users@lists.isc.org Subject: Re: How to properly update chroot-bind Am 28.07.2015 um 10:56 schrieb Matus UHLAR - fantomas: but you *never ever* should only update specific packages on a RHEL/CentOS system because that is *not supported and tested* at all No? What are dependencies for, then? Or don't yum/RPM support them in the way debian does? (that is why it's quite easy to have mixed Debian... we have machine with mix of debian 5,6,7 and even 8... not that It's good idea) On 28.07.15 11:22, Reindl Harald wrote: CentOS is a RHEL clone except that there are no updates for older point releases it was multiple times statet by the maintainers on the mailing list that you have to apply *all* errata updates nothing else is supported it's not a matter of dependencies, it's just a matter of what combinations of packages are tested for regressions and the fact that there are no updates for RHEL without a good reason how does dependencies help when there was a critical bug fixed in package A which may hit your updated version of package B because the combination of that versions never was tested feel free to ignore that but you are at your own if things behave unexpected when the developers say just only use 'yum upgrade' which applies also for minor releases, when CentOS 6.7 is out there will be no single update for CentOS 6.6 packages and hence yum upgrade brings you to CentOS 6.7 in a few weeks which is from that moment on the only supported CentOS 6.x yes, this is a good explanation, I believe for the OP too. not supported can of course mean working without problems, however I agree there's no point in only updating BIND itself. Still, the OP can stick with provided BIND 9.8 that is in CentOS6, update to CentOS 7 or compile his own BIND version (and provide support for themselves) -- 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. REALITY.SYS corrupted. Press any key to reboot Universe. ___ 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: DNS format error
Yang Yu yang.yu.l...@gmail.com wrote: the query error log can be replicated with dig www.vip.icann.org ds This sounds like a DNSSEC validation issue, but why would I get DNS format error in the log This is weird and interesting. The name servers for vip.icann.org are doing some kind of minimal covering NSEC3 records in their responses with varying salt. They are somewhat problematic because they are incompatible with negative answer synthesis, e.g. if you query for a nonexistent RRtype at the zone apex, you get an answer that asserts there are no records at that name. $ dig +dnssec +norec @gtm1.mdr.icann.org. vip.icann.org txt | grep 'IN NSEC3' vcv1gvphnmjemfjiljmfjgolg02det3g.vip.icann.org. 60 IN NSEC3 1 0 1 3EACB33008A7EEA0 VCV1GVPHNMJEMFJILJMFJGOLG02DET3H $ NSEC3 1 0 1 3EACB33008A7EEA0 vip.icann.org VCV1GVPHNMJEMFJILJMFJGOLG02DET3G (salt=3EACB33008A7EEA0, hash=1, iterations=1) The servers seem to have special handling for certain RRtypes. If you ask for QTYPE=NSEC3 you get a completely empty answer, which does not conform to RFC 5155 section 7.2.3. QTYPE=DS responses are also weird. The response is always just an empty NSEC3 record for the zone apex (like the one above) and its RRSIG(NSEC3). The NSEC3 owner does not match the QNAME unless you happen to query for the apex. $ dig -6 +dnssec +norec +noall +authority @gtm1.mdr.icann.org. stoat.vip.icann.org ds vcv1gvphnmjemfjiljmfjgolg02det3g.vip.icann.org. 3600 IN NSEC3 1 0 1 3EACB33008A7EEA0 VCV1GVPHNMJEMFJILJMFJGOLG02DET3H vcv1gvphnmjemfjiljmfjgolg02det3g.vip.icann.org. 3600 IN RRSIG NSEC3 7 4 3600 20150804183901 20150728183901 58127 vip.icann.org. MmXIg6proQwTw6tVt2wDea08lHbjsqf/BoMZZq7pNVyCLzwCyvjZP4HF zNNYv030e4uapd9DGwgjqNwDRaGU3WZg06WOxn7u3yVMqagSV9t4VAB1 nl0SZpYamV2TV/ZcBehmGTrdWh9Ei2pmlqyffvcq+4tQfcVeX7RDljHw u4U= $ NSEC3 1 0 1 3EACB33008A7EEA0 stoat.vip.icann.org JV27TTDI7M980OBC023FH646I4CE2352 (salt=3EACB33008A7EEA0, hash=1, iterations=1) However the weirdness in the NSEC3 record is not what is upsetting BIND, and it might be a bug. A noerror response with just NSEC3 and RRSIG(NSEC3) in the authority section should (I think) be treated as a type 3 nodata response (see RFC 2308). However BIND requires type 3 nodata responses to have completely empty authority sections. BIND will only recognise type 1 or type 2 nodata responses (with SOA records in the authority section) from signed zones. Of course, if BIND accepted this answer as negative, it would fail validation due to the NSEC3 owner mismatch. ps. this is the NSEC3 command I used above because the mapping from NSEC3 RDATA to nsec3hash arguments is utterly confusing. #!/bin/sh # NSEC3 wrapper around nsec3hash algo=$1 flags=$2 iters=$3 salt=$4 domain=$5 nsec3hash $salt $algo $iters $domain Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South Utsire, Forties, Cromarty, Forth, Tyne: Northerly or northwesterly 5 to 7, perhaps gale 8 later in Forties. Slight or moderate, becoming moderate or rough, occasionally very rough in Forties. Rain or showers. Good, occasionally moderate. ___ 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
About CVE-2015-5477 (An error in handling TKEY queries can cause named to exit with a REQUIRE assertion failure)
As the security incident manager for this particular vulnerability notification, I'd like to say a little extra, beyond our official vulnerability disclosure (https://kb.isc.org/article/AA-01272) about this critical defect in BIND. Many of our bugs are limited in scope or affect only users having a particular set of configuration choices. CVE-2015-5477 does not fall into that category. Almost all unpatched BIND servers are potentially vulnerable. We know of no configuration workarounds. Screening the offending packets with firewalls is likely to be difficult or impossible unless those devices understand DNS at a protocol level and may be problematic even then. And the fix for this defect is very localized to one specific area of the BIND code. The practical effect of this is that this bug is difficult to defend against (except by patching, which is completely effective) and will not be particularly difficult to reverse-engineer. I have already been told by one expert that they have successfully reverse-engineered an attack kit from what has been divulged and from analyzing the code changes, and while I have complete confidence that the individual who told me this is not intending to use his kit in a malicious manner, there are others who will do so who may not be far behind. Please take steps to patch immediately. This bug is designated Critical and it deserves that designation. ___ 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
