Re: bind 9.6.0-P1's nsupdate dumps core on NetBSD/i386 4.x
In message , Ray Phillips writes: > I've built bind 9.6.0-P1 on NetBSD/i386 machines (versions 3.1, 4.0, > 4.0.1 and 5.0_RC2) and discovered that nsupdate dumps core on the 4.x > ones. > > The build process was just: > > % sh -c './configure --disable-threads > configure.log 2>&1' > % sh -c 'make > make.log 2>&1' > % su > Password: > # sh -c 'make install > make-install.log 2>&1' > # > > I've also tried without --disable-threads but it made no difference. > > > % ls -l /usr/local/bin/nsupdate > -rwxr-xr-x 1 root wheel 3517495 Mar 5 17:19 /usr/local/bin/nsupdate > % file /usr/local/bin/nsupdate > /usr/local/bin/nsupdate: ELF 32-bit LSB executable, Intel 80386, > version 1 (SYSV), for NetBSD 4.0, dynamically linked (uses shared > libs), not stripped > % ldd /usr/local/bin/nsupdate > /usr/local/bin/nsupdate: > -lcrypt.0 => /lib/libcrypt.so.0 > -lcrypto.3 => /usr/lib/libcrypto.so.3 > -lc.12 => /usr/lib/libc.so.12 > % pwd > /tmp > % ls -l > % /usr/local/bin/nsupdate > Segmentation fault (core dumped) > % ls -l > total 3648 > -rw--- 1 ray wheel 1846100 Mar 5 17:21 nsupdate.core > % file nsupdate.core > nsupdate.core: ELF 32-bit LSB core file Intel 80386, version 1 > (SYSV), NetBSD-style, from 'nsupdate' (signal 11) > % gdb nsupdate.core You need to call gdb correctly. gdb /usr/local/bin/nsupdate nsupdate.core > GNU gdb 6.5 > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386--netbsdelf"..."/tmp/nsupdate.core": > not in executable format: File format not recognized > > (gdb) quit > % > > It would be nice if it worked on the 4.x versions. Could you suggest > what I could do to troubleshoot it please? bind9 9.5.0-P2's nsupdate > worked fine on them. > > > Ray > ___ > 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: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: $generate lhs problem. Manual needs to be updated.
Takahiro Masuda wrote:
> Yes I guess I didn't understand it totally because in the example syntax
> is shown as lhs defined at the beginning
> *$GENERATE* /|range|/ /|lhs|/ [/|ttl|/] [/|class|/] /|type|/ /|rhs|/ [
> /|comment|/ ]
> and when you read the explanation for lhs it shows the example ${-20,3,d}.
> So I thought that ${-20,3,d} should be defined on the left side. The
> example only shows one part. I think it'll be helpful if you add the
> whole line in the example so users can see where to place it in the syntax
>
> $GENERATE 1-127 $ CNAME ${3,0,d}.0
But what if they actually wanted:
$GENERATE 1-127 q${3,0,d}.m0.foo.com. A 12.1.1.$
The sample expansion is not just possible on the LHS. It's
ambidextrous. :)
I'm still not clear what the issue is.
AlanC
signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
BIND logging
Morning, I'm busy learning a bit more about DNS/BIND, but I seem to have run into a problem. My server does not seem to propogate, so my questions are: Where does BIND log it's errors to? I see some named entries in my syslog, is it the only place it logs to? If so, can I change the logfile where BIND logs it's errors? Get it to be a bit more verbose? Thank you. -- simian ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND logging
On 05.03.09 08:55, simian wrote:
> I'm busy learning a bit more about DNS/BIND, but I seem to have run into
> a problem. My server does not seem to propogate, so my questions are:
>
> Where does BIND log it's errors to? I see some named entries in my syslog,
> is it the only place it logs to?
>
> If so, can I change the logfile where BIND logs it's errors? Get it to be a
> bit
> more verbose?
Docs are available on https://www.isc.org/software/bind/documentation
See the ARM (Administrator Reference Manual) for your version, section 6,
the "logging statement definition and usage".
There are some defaults, with configuring proper channels and categories you
can define
which log meesages go where. I e.g. have:
channel nextra_syslog {
syslog daemon;
// syslog local0;
severity info;
print-category yes;
print-severity yes;
};
category default {
nextra_syslog;
default_debug;
};
--
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 box said 'Requires Windows 95 or better', so I bought a Macintosh".
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
stub zone
hi At the moment our internal DNS servers are authorative for the main domain via slave zones, which will be generating unnecessary replication traffic. Howto create a stub zone instead of slave zone on BIND 9.3.4-P1.1? What are differences between slave and stub zone? Piotr ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND logging
On Thu, 5 Mar 2009 13:49:12 +0100 Matus UHLAR - fantomas wrote: -snip- Thank you very much, I'm having a look at it now. Regards, -- simian ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.6.0-P1's nsupdate dumps core on NetBSD/i386 4.x
> I've built bind 9.6.0-P1 on NetBSD/i386 machines (versions 3.1, 4.0, > 4.0.1 and 5.0_RC2) and discovered that nsupdate dumps core on the 4.x > ones. I just built and installed bind-9.6.0-P1 on NetBSD/i386 4.0 and nsupdate doesn't crash for me. (Built with default pthread and also linked with libxml.) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
will blocking getting hammered by cache request do anything?
Hi All: my 9.6.0 server is getting hammered by cache requests from a specific IP (62.109.4.89) which traces back to what looks like a DSL netblock in Russia: 05-Mar-2009 12:18:01.883 queries: info: client 62.109.4.89#53157: query: . IN NS + 05-Mar-2009 12:18:01.883 security: info: client 62.109.4.89#53157: query (cache) './NS/IN' denied I assume that this is some unpatched server (because currently I only see this single IP trying to connect), but is there any way to tell the difference between that and a deliberate DDOS attack? My subnet is on a Verizon 3Mbps static "business" DSL connection with a router/firewall NAT'ing the incoming traffic. My question is, will blocking this from the firewall in front of the box help in any way to mitigate it's effect on the server? Or do I need to get my upstream provider to block this IP for it to have any impact? The server isn't "choking" on the volume of requests (yet), and I'm wondering if blocking the requests at the border of the network would do anything meaningful? Of course, it's prolly not realistic to expect Verizon to do anything above my router. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: will blocking getting hammered by cache request do anything?
In article , "online-reg" wrote: > Hi All: my 9.6.0 server is getting hammered by cache requests from a > specific IP (62.109.4.89) which traces back to what looks like a DSL > netblock in Russia: > > 05-Mar-2009 12:18:01.883 queries: info: client 62.109.4.89#53157: query: . > IN NS + > 05-Mar-2009 12:18:01.883 security: info: client 62.109.4.89#53157: query > (cache) './NS/IN' denied > > I assume that this is some unpatched server (because currently I only see > this single IP trying to connect), but is there any way to tell the > difference between that and a deliberate DDOS attack? Actually, this is almost certainly someone trying to use your server as part of a DNS amplification attack ON that server. The source IP is spoofed, with the goal of getting lots of servers to send large replies to it. But since you have recursion and query-cache disabled for external IPs, you're not amplifying anything. > My subnet is on a Verizon 3Mbps static "business" DSL connection with a > router/firewall NAT'ing the incoming traffic. > > My question is, will blocking this from the firewall in front of the box > help in any way to mitigate it's effect on the server? Or do I need to get > my upstream provider to block this IP for it to have any impact? The server > isn't "choking" on the volume of requests (yet), and I'm wondering if > blocking the requests at the border of the network would do anything > meaningful? If you block it on the firewall, then the requests will never hit the server, so of course it will mitigate its effect on the server. It won't help with the downstream bandwidth on your DSL, but it will stop the "REFUSED" replies from being sent back, so your upstream bandwidth will improve. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.6.0-P1's nsupdate dumps core on NetBSD/i386 4.x
You need to call gdb correctly. gdb /usr/local/bin/nsupdate nsupdate.core Thanks Mark. Sorry, I (obviously) don't have much of a clue about using gdb. % uname -v NetBSD 4.0.1 (GENERIC) #0: Tue Oct 7 22:58:48 PDT 2008 bui...@wb30:/home/builds/ab/netbsd-4-0-1-RELEASE/i386/200810080053Z-obj/home/builds/ab/netbsd-4-0-1-RELEASE/src/sys/arch/i386/compile/GENERIC % gdb /usr/local/bin/nsupdate nsupdate.core GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386--netbsdelf"... Reading symbols from /usr/lib/libcrypto.so.3...done. Loaded symbols for /usr/lib/libcrypto.so.3 Reading symbols from /usr/lib/libc.so.12...done. Loaded symbols for /usr/lib/libc.so.12 Reading symbols from /lib/libcrypt.so.0...done. Loaded symbols for /lib/libcrypt.so.0 Reading symbols from /usr/libexec/ld.elf_so...done. Loaded symbols for /usr/libexec/ld.elf_so Core was generated by `nsupdate'. Program terminated with signal 11, Segmentation fault. #0 0xbba8a7a1 in memcpy () from /usr/lib/libc.so.12 (gdb) backtrace #0 0xbba8a7a1 in memcpy () from /usr/lib/libc.so.12 #1 0x080bca73 in mem_realloc (ptr=0x81c21e0, size=136061320) at openssl_link.c:158 #2 0xbbba9f77 in lh_new () from /usr/lib/libcrypto.so.3 #3 0xbbbaa53f in CRYPTO_realloc () from /usr/lib/libcrypto.so.3 #4 0xbbb4e304 in sk_insert () from /usr/lib/libcrypto.so.3 #5 0xbbb4e369 in sk_push () from /usr/lib/libcrypto.so.3 #6 0xbbb88b73 in engine_table_register () from /usr/lib/libcrypto.so.3 #7 0xbbb5350b in ENGINE_register_RAND () from /usr/lib/libcrypto.so.3 #8 0xbbb0dab1 in ENGINE_register_complete () from /usr/lib/libcrypto.so.3 #9 0xbbb0dae5 in ENGINE_register_all_complete () from /usr/lib/libcrypto.so.3 #10 0x080bc98d in dst__openssl_init () at openssl_link.c:251 #11 0x080b9e10 in dst_lib_init (mctx=0x817, ectx=0x8184000, eflags=0) at dst_api.c:183 #12 0x0804c43a in main (argc=Cannot access memory at address 0x2 ) at nsupdate.c:772 (gdb) quit % I just built and installed bind-9.6.0-P1 on NetBSD/i386 4.0 and nsupdate doesn't crash for me. (Built with default pthread and also linked with libxml.) Thanks Jeremy. Hm, I did a fresh install of NetBSD/i386 4.0.1 to test this (hoping to avoid the possibility of having made a stupid mistake). I first encountered the problem on a 4.0 installation which had a few security patches applied but I hadn't tried on a fresh install of 4.0. Here's the gdb output from that 4.0 machine: % pwd /tmp % ls -l /usr/local/bin/nsupdate -rwxr-xr-x 1 root wheel 3517495 Jan 22 10:11 /usr/local/bin/nsupdate % /usr/local/bin/nsupdate Segmentation fault (core dumped) % ls -l total 3680 -rw--- 1 ray wheel 1855328 Mar 6 09:35 nsupdate.core % file nsupdate.core nsupdate.core: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), NetBSD-style, from 'nsupdate' (signal 11) % gdb /usr/local/bin/nsupdate nsupdate.core GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386--netbsdelf"... Reading symbols from /usr/lib/libcrypto.so.3...done. Loaded symbols for /usr/lib/libcrypto.so.3 Reading symbols from /usr/lib/libc.so.12...done. Loaded symbols for /usr/lib/libc.so.12 Reading symbols from /lib/libcrypt.so.0...done. Loaded symbols for /lib/libcrypt.so.0 Reading symbols from /usr/libexec/ld.elf_so...done. Loaded symbols for /usr/libexec/ld.elf_so Core was generated by `nsupdate'. Program terminated with signal 11, Segmentation fault. #0 0xbba8d089 in memcpy () from /usr/lib/libc.so.12 (gdb) backtrace #0 0xbba8d089 in memcpy () from /usr/lib/libc.so.12 #1 0x080bca73 in mem_realloc (ptr=0x81c21e0, size=136061320) at openssl_link.c:158 #2 0xbbbabf77 in lh_new () from /usr/lib/libcrypto.so.3 #3 0xbbbac53f in CRYPTO_realloc () from /usr/lib/libcrypto.so.3 #4 0xbbb50304 in sk_insert () from /usr/lib/libcrypto.so.3 #5 0xbbb50369 in sk_push () from /usr/lib/libcrypto.so.3 #6 0xbbb8ab73 in engine_table_register () from /usr/lib/libcrypto.so.3 #7 0xbbb5550b in ENGINE_register_RAND () from /usr/lib/libcrypto.so.3 #8 0xbbb0fab1 in ENGINE_register_complete () from /usr/lib/libcrypto.so.3 #9 0xbbb0fae5 in ENGINE_register_all_complete () from /usr/lib/libcrypto.so.3 #10 0x080bc98d in dst__openssl_init () at openssl_link.c:251 #11 0x080b9e10 in dst_lib_init (mctx=0x817, ectx=0x8184000, eflags=0) at dst_api.c:183 #12 0x0804c43a in main (argc=Cannot access memory at address 0x2
Re: bind 9.6.0-P1's nsupdate dumps core on NetBSD/i386 4.x
In message , Ray Phillips writes:
> > You need to call gdb correctly.
> >
> > gdb /usr/local/bin/nsupdate nsupdate.core
>
> Thanks Mark.
>
> Sorry, I (obviously) don't have much of a clue about using gdb.
Looks like you have hit this bug.
2547. [bug] openssl_link.c:mem_realloc() could reference an
out-of-range area of the source buffer. New public
function isc_mem_reallocate() was introduced to address
this bug. [RT #19313]
Mark
Index: bind9/CHANGES
diff -u bind9/CHANGES:1.2991 bind9/CHANGES:1.2992
--- bind9/CHANGES:1.2991Fri Feb 6 12:33:17 2009
+++ bind9/CHANGES Wed Feb 11 03:04:18 2009
@@ -1,3 +1,8 @@
+2547. [bug] openssl_link.c:mem_realloc() could reference an
+ out-of-range area of the source buffer. New public
+ function isc_mem_reallocate() was introduced to address
+ this bug. [RT #19313]
+
2546. [func] Add --enable-openssl-hash configure flag to use
OpenSSL (in place of internal routine) for hash
functions (MD5, SHA[12] and HMAC). [RT #18815]
Index: bind9/lib/dns/openssl_link.c
diff -u bind9/lib/dns/openssl_link.c:1.24 bind9/lib/dns/openssl_link.c:1.25
--- bind9/lib/dns/openssl_link.c:1.24 Sat Jan 17 23:47:42 2009
+++ bind9/lib/dns/openssl_link.cWed Feb 11 03:04:18 2009
@@ -148,18 +148,8 @@
static void *
mem_realloc(void *ptr, size_t size) {
- void *p;
-
INSIST(dst__memory_pool != NULL);
- p = NULL;
- if (size > 0U) {
- p = mem_alloc(size);
- if (p != NULL && ptr != NULL)
- memcpy(p, ptr, size);
- }
- if (ptr != NULL)
- mem_free(ptr);
- return (p);
+ return (isc_mem_reallocate(dst__memory_pool, ptr, size));
}
isc_result_t
Index: bind9/lib/isc/mem.c
diff -u bind9/lib/isc/mem.c:1.147 bind9/lib/isc/mem.c:1.148
--- bind9/lib/isc/mem.c:1.147 Thu Jan 22 23:47:54 2009
+++ bind9/lib/isc/mem.c Wed Feb 11 03:04:18 2009
@@ -1365,6 +1365,40 @@
return (si);
}
+void *
+isc__mem_reallocate(isc_mem_t *ctx, void *ptr, size_t size FLARG) {
+ void *new_ptr = NULL;
+ size_t oldsize, copysize;
+
+ REQUIRE(VALID_CONTEXT(ctx));
+
+ /*
+* This function emulates the realloc(3) standard library function:
+* - if size > 0, allocate new memory; and if ptr is non NULL, copy
+* as much of the old contents to the new buffer and free the old one.
+* Note that when allocation fails the original pointer is intact;
+* the caller must free it.
+* - if size is 0 and ptr is non NULL, simply free the given ptr.
+* - this function returns:
+* pointer to the newly allocated memory, or
+* NULL if allocation fails or doesn't happen.
+*/
+ if (size > 0U) {
+ new_ptr = isc__mem_allocate(ctx, size FLARG_PASS);
+ if (new_ptr != NULL && ptr != NULL) {
+ oldsize = (((size_info *)ptr)[-1]).u.size;
+ INSIST(oldsize >= ALIGNMENT_SIZE);
+ oldsize -= ALIGNMENT_SIZE;
+ copysize = oldsize > size ? size : oldsize;
+ memcpy(new_ptr, ptr, copysize);
+ isc__mem_free(ctx, ptr FLARG_PASS);
+ }
+ } else if (ptr != NULL)
+ isc__mem_free(ctx, ptr FLARG_PASS);
+
+ return (new_ptr);
+}
+
void
isc__mem_free(isc_mem_t *ctx, void *ptr FLARG) {
size_info *si;
Index: bind9/lib/isc/include/isc/mem.h
diff -u bind9/lib/isc/include/isc/mem.h:1.80
bind9/lib/isc/include/isc/mem.h:1.81
--- bind9/lib/isc/include/isc/mem.h:1.80Sat Jan 17 23:47:43 2009
+++ bind9/lib/isc/include/isc/mem.h Wed Feb 11 03:04:18 2009
@@ -154,6 +154,7 @@
#define isc_mem_get(c, s) isc__mem_get((c), (s) _ISC_MEM_FILELINE)
#define isc_mem_allocate(c, s) isc__mem_allocate((c), (s) _ISC_MEM_FILELINE)
+#define isc_mem_reallocate(c, p, s) isc__mem_reallocate((c), (p), (s)
_ISC_MEM_FILELINE)
#define isc_mem_strdup(c, p) isc__mem_strdup((c), (p) _ISC_MEM_FILELINE)
#define isc_mempool_get(c) isc__mempool_get((c) _ISC_MEM_FILELINE)
@@ -612,6 +613,8 @@
isc__mem_put(isc_mem_t *, void *, size_t _ISC_MEM_FLARG);
void *
isc__mem_allocate(isc_mem_t *, size_t _ISC_MEM_FLARG);
+void *
+isc__mem_reallocate(isc_mem_t *, void *, size_t _ISC_MEM_FLARG);
void
isc__mem_free(isc_mem_t *, void * _ISC_MEM_FLARG);
char *
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RHEL and named with DLZ
Hello, I am trying to get named with DLZ on RHEL.
My build line is below, I can start named, and I have base configured
it so that it will return a lookup for `dig example.com @localhost
+norec` which returns a custom IP I put in to make sure it is really
working.
So far, I know named is working.
I added in dlz "Mysql zone" { ... }
rndc and restarting named all work fine, no errors that I can see.
But in a successful build on OS X, I was getting a line in the log for
named that said"
'Mysql zone' using driver mysql
I do not get that on RHEL, and I am not getting answers back for my
test zones I have in the database. MySql is running, I know that much.
Any suggestions?
built with '--build=x86_64-redhat-linux-gnu'
'--host=x86_64-redhat-linux-gnu'
'--target=x86_64-redhat-linux-gnu'
'--program-prefix='
'--prefix=/usr'
'--exec-prefix=/usr'
'--bindir=/usr/bin'
'--sbindir=/usr/sbin'
'--sysconfdir=/etc'
'--datadir=/usr/share'
'--includedir=/usr/include'
'--libdir=/usr/lib64'
'--libexecdir=/usr/libexec'
'--sharedstatedir=/usr/com'
'--mandir=/usr/share/man'
'--infodir=/usr/share/info'
'--with-libtool'
'--localstatedir=/var'
'--enable-threads'
'--enable-ipv6'
'--with-pic'
'--disable-static'
'--disable-openssl-version-check'
'--with-dlz-ldap=yes'
'--with-dlz-postgres=yes'
'--with-dlz-mysql=yes'
'--with-dlz-filesystem=yes'
'--with-gssapi=yes'
'--disable-isc-spnego'
'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -
fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'
'CPPFLAGS= -DDIG_SIGCHASE' 'CXXFLAGS=-O2 -g -pipe -Wall -Wp,-
D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-
size=4 -m64 -mtune=generic' 'FF
--
Scott * If you contact me off list replace talklists@ with scott@ *
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
