Re: dnsperf and BIND memory consumption
OK. I just make bind from src with ./configure --enable-threads gcc
option -static.
file /usr/local/sbin/named-test
/usr/local/sbin/named-test: ELF 64-bit LSB executable, x86-64, version 1
(FreeBSD), for FreeBSD 7.1 (701100), statically linked, FreeBSD-style,
not stripped
fresh system (yesterday cvsup to RELENG_7)
$ uname -a
FreeBSD XXX.XXX.XX 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Wed Dec 10
17:07:03 MSK 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/XXX amd64
2.
max-cache-size 128M;
start:
/usr/bin/limits -c 1000M -v 500M /usr/local/sbin/named-test -c
/etc/namedb/named.conf
$ gdb -c named-test.core -se /usr/local/sbin/named-test
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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 amd64-marcel-freebsd...
Core was generated by `named-test'.
Program terminated with signal 6, Aborted.
#0 0x0058c3fc in thr_kill ()
[New Thread 0x80902f00 (LWP 100404)]
[New Thread 0x80902d80 (LWP 100400)]
[New Thread 0x80902c00 (LWP 100356)]
[New Thread 0x80902a80 (LWP 100318)]
[New Thread 0x80902900 (LWP 100239)]
[New Thread 0x80902780 (LWP 100237)]
[New Thread 0x80902600 (LWP 100222)]
[New Thread 0x80902480 (LWP 100209)]
[New Thread 0x80902300 (LWP 100175)]
[New Thread 0x80902180 (LWP 100092)]
[New Thread 0x80803180 (LWP 100177)]
(gdb) bt
#0 0x0058c3fc in thr_kill ()
#1 0x005c5a68 in abort ()
#2 0x00597af7 in malloc ()
#3 0x00564247 in mem_getunlocked (ctx=0x8080d140, size=94) at
mem.c:385
#4 0x00564b68 in isc__mem_get (ctx=0x8080d140, size=94,
file=0x61bd78 rbt.c, line=1425) at mem.c:1096
#5 0x00480121 in create_node (mctx=0x8080d140,
name=0x7fbfcff0, nodep=0x7fbfd2e0) at rbt.c:1424
#6 0x0048080f in dns_rbt_addnode (rbt=0x80a925e8,
name=0x88cf2020, nodep=0x7fbfd3a8) at rbt.c:624
#7 0x0048be53 in loading_addrdataset (arg=0x94b07ff0,
name=0x88cf2020, rdataset=0x7fbfd810) at rbtdb.c:5657
#8 0x00463761 in commit (callbacks=0x7fbfe5c0,
lctx=0x80834000, head=0x7fbfe480, owner=0x88cf2020,
source=0x94c2afd8 co/brand.bak, line=611215) at master.c:2729
#9 0x004668df in load_text (lctx=0x80834000) at master.c:1427
#10 0x0046b61b in dns_master_loadfile2 (master_file=0x878a7098
co/broad.bak, top=Variable top is not available.
)
at master.c:2350
#11 0x00506126 in zone_load (zone=0x878ec000, flags=Variable
flags is not available.
) at zone.c:1504
#12 0x005082b9 in load (zone=Variable zone is not available.
) at zt.c:246
#13 0x00507ec2 in dns_zt_apply2 (zt=Variable zt is not available.
) at zt.c:379
#14 0x00508144 in dns_zt_load (zt=0x86adb750,
stop=isc_boolean_false) at zt.c:237
#15 0x004223c7 in load_zones (server=0x8082f000,
stop=isc_boolean_false) at server.c:3659
#16 0x004232fc in run_server (task=Variable task is not available.
) at server.c:3751
#17 0x0057052c in run (uap=Variable uap is not available.
) at task.c:862
#18 0x005868a7 in thread_start ()
#19 0x in ?? ()
Cannot access memory at address 0x7fbff000
At normal situation after startup memory usage over 700 MB.
-
JINMEI Tatuya / 神明達哉 wrote:
At Wed, 10 Dec 2008 15:50:22 +0300,
Dmitry Rybin [EMAIL PROTECTED] wrote:
JINMEI Tatuya / 神明達哉 wrote:
At Tue, 09 Dec 2008 18:05:27 +0300,
Dmitry Rybin [EMAIL PROTECTED] wrote:
I test patch, add to bind95/Makefile
.if (${ARCH} == amd64)
ARCH= x86_64
.endif
Future versions of BIND9 will support amd64 in its configure script to
workaround the FreeBSD port for amd64.
Regarding the memory leak, I believe it's already solved in 9.5.1rc1
(even with threads and without atomic).
I just make port bind 9.5.1rc1. It has same problem with memory leak.
It grows from 670M on startup, to 1,4Gb after 20 minutes of work.
Can you first fall back to the vanilla 9.5.1rc1 (i.e., not FreeBSD
port) so that we can separate FreeBSD-port specific issue and BIND9
specific leak?
Second, what if you stop named by 'rndc stop'? If there's memory leak
in BIND9, it normally detects it during a cleanup process and
indicates the bug by aborting (core dumping) itself.
If it doesn't cause an abort, please then try the diagnosing I
suggested before:
http://marc.info/?l=bind-usersm=121811979629090w=2
To summarize it:
1. create a symbolic link from /etc/malloc.conf to X:
# ln -s X /etc/malloc.conf
2. - start named with a moderate limitation of virtual memory size, e.g.
# /usr/bin/limits -v 384m $path_to_named/named command line options
(note that 384m should be reasonably large compared with
max-cache-size. I'd suggest setting max-cache-size to 128M and
setup default DNS server with only one record
I am trying to setup a default DNS server for one of my restricted network segment so that no matter what people type in their browser, they will be redirected to a single IP address or the hostname. The zone file that I have setup is partially working - it resolves anything.mydomain.com to a single IP address but doesn't resolve anything.some-other-domain.com (eg. www.cnn.com) - it just gives up. Here is my zone file. Any help would be highly appreciated. Thanks. $TTL 1W @ IN SOA nms.mydomain.com. hostmaster.mydomain.com. ( 42 ; serial 2D ; refresh 4H ; retry 6W ; expiry 1W ); minimum @ ns nms.mydomain.com. * A 192.168.25.25 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsperf and BIND memory consumption
max-cache-size 64M;
# /usr/bin/limits -v 1200M /usr/local/sbin/named-test -c
/etc/namedb/named.conf
Over 10 minutes of work and core dumped:
(gdb) bt
#0 0x0058c3fc in thr_kill ()
#1 0x005c5a68 in abort ()
#2 0x00597af7 in malloc ()
#3 0x0056645a in isc_mem_createx2 (init_max_size=0, target_size=0,
memalloc=0x564400 default_memalloc, memfree=0x563320
default_memfree, arg=0x0,
ctxp=0xcb29b978, flags=Variable flags is not available.
) at mem.c:790
#4 0x00566730 in isc_mem_create (init_max_size=Variable
init_max_size is not available.
) at mem.c:859
#5 0x004d83ae in dns_resolver_create (view=0xca46e800,
taskmgr=0x80828000,
ntasks=31, socketmgr=Variable socketmgr is not available.
) at resolver.c:6514
#6 0x004ee860 in dns_view_createresolver (view=0xca46e800,
taskmgr=0x80828000,
ntasks=31, socketmgr=0x8082b000, timermgr=0x80829000, options=0,
dispatchmgr=0x8083c000,
dispatchv4=0x864c9000, dispatchv6=0x864c9800) at view.c:580
#7 0x0041bba2 in configure_view (view=0xca46e800,
config=0x80abb4c0,
vconfig=0x8085ada8, mctx=0x8080d140, actx=0x7eff8860,
need_hints=isc_boolean_true)
at server.c:1290
#8 0x00420f42 in load_configuration (filename=Variable
filename is not available.
) at server.c:3285
#9 0x00422095 in loadconfig (server=0x8082f000) at server.c:4121
#10 0x00422426 in reload (server=0x8082f000) at server.c:4141
#11 0x004225c2 in ns_server_reloadcommand (server=0x8082f000,
args=Variable args is not available.
) at server.c:4334
#12 0x00407682 in ns_control_docommand (message=Variable
message is not available.
) at control.c:102
#13 0x0040a8b7 in control_recvmessage (task=0x80839000,
event=Variable event is not available.
) at controlconf.c:456
#14 0x0057052c in run (uap=Variable uap is not available.
) at task.c:862
#15 0x005868a7 in thread_start ()
#16 0x in ?? ()
Cannot access memory at address 0x7eff9000
JINMEI Tatuya / 神明達哉 wrote:
At Wed, 10 Dec 2008 15:50:22 +0300,
Dmitry Rybin [EMAIL PROTECTED] wrote:
JINMEI Tatuya / 神明達哉 wrote:
At Tue, 09 Dec 2008 18:05:27 +0300,
Dmitry Rybin [EMAIL PROTECTED] wrote:
I test patch, add to bind95/Makefile
.if (${ARCH} == amd64)
ARCH= x86_64
.endif
Future versions of BIND9 will support amd64 in its configure script to
workaround the FreeBSD port for amd64.
Regarding the memory leak, I believe it's already solved in 9.5.1rc1
(even with threads and without atomic).
I just make port bind 9.5.1rc1. It has same problem with memory leak.
It grows from 670M on startup, to 1,4Gb after 20 minutes of work.
Can you first fall back to the vanilla 9.5.1rc1 (i.e., not FreeBSD
port) so that we can separate FreeBSD-port specific issue and BIND9
specific leak?
Second, what if you stop named by 'rndc stop'? If there's memory leak
in BIND9, it normally detects it during a cleanup process and
indicates the bug by aborting (core dumping) itself.
If it doesn't cause an abort, please then try the diagnosing I
suggested before:
http://marc.info/?l=bind-usersm=121811979629090w=2
To summarize it:
1. create a symbolic link from /etc/malloc.conf to X:
# ln -s X /etc/malloc.conf
2. - start named with a moderate limitation of virtual memory size, e.g.
# /usr/bin/limits -v 384m $path_to_named/named command line options
(note that 384m should be reasonably large compared with
max-cache-size. I'd suggest setting max-cache-size to 128M and
setting 'limits -v' to 512m).
3. Then the named process will eventually abort itself with a core dump
due to malloc failure. Please show us the stack trace at that point.
Hopefully it will reveal the malloc call that keeps consuming memory.
In fact, I myself successfully identified one leak in 9.5.0-P2 with
FreeBSD port this way.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Master server migration.
On Thu, Dec 11, 2008 at 9:00 AM, Chris Henderson [EMAIL PROTECTED] wrote: I'm migrating away from my 12 year old Solaris master DNS server to a new Linux based master server. I'm looking for suggestions on how to make the transition smooth without any downtime. The IP address of the new server will be different and so will be the hostname that will show up in the whois record. Is there any way to run two master at the same time and when I know the new master is working, I can turn off the old one? Would that be a good idea? I am open to any suggestions. The most significant part of the process is to make sure that all slave servers for all your zones have changed their settings. If the slaves are beyond your control it can take time and a considerable amount of human interaction. So I can suggest you the following plan: 1. Freeze zone editing. 2. Copy all your master files to the new box and configure master zones there. 3. Change the settings on your old box: convert all master zones into slaves and set up ip-address of the new box as an address of the master. 4. Unfreeze zone editing. 5. Do all you need to do to change the settings on all slave servers: now they've got to pull your zone from the new ip address. 6. On having the slaves changed their settings you can safely turn off DNS service on your old box. 7. Now you have to change NS records in all your zones: replace the old name with a new one. 8. The last step is to send update to your upper level domain registry to change whois record and your parent zone. If you don't change your zones frequently, you can skip step 3. It provides just a possibility of zone changes propagation during the transition period. -- Anton ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS issues with tmomail.net
In article [EMAIL PROTECTED], David Ford [EMAIL PROTECTED] wrote: Sam Wilson wrote: I hadn't noticed it but all the records in the response to a request for the MX for tmomail.net have a TTL of 60 seconds, that's the MX record, the NS authority record and the additional A record. The names in the delegation NS records for for tmomail.net are different from the authoritative ones, though they seem to be the same servers. There's considerable opportunity there for things to go wrong, though it all seems to work fine from here. It will work for hours, sometimes a day before bind is unable to fetch records for it again. But immediately upon restarting bind, bind is able to go fetch records for it. I understand that the records for tmomail.net are problematic but what makes the difference in bind from running a while vs. a fresh restart when it comes to fetching records? Why would it be 100% successful on restart? Dunno, but when you poke around in that area there are a whole lot more duelling TTLs. But as Jinmei-san points out you may be being bitten by a bug. Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about Records not authoritative for
This is exactly what we have done in the past to mitigate malware. Just load somebaddomain.com with no A records or with a wildcard pointing to 127.0.0.1. -- -Ben Croswell On Thu, Dec 11, 2008 at 11:29 AM, Baird, Josh jba...@follett.com wrote: You could just create an authoritative zone for the domain on your internal view to override recursion. You can then create a wildcard 'A' record or such to resolve to 127.0.0.1, etc. Josh *From:* bind-users-boun...@lists.isc.org [mailto: bind-users-boun...@lists.isc.org] *On Behalf Of *Casartello, Thomas *Sent:* Thursday, December 11, 2008 10:25 AM *To:* 'bind-us...@isc.org' *Cc:* Childs, Aaron *Subject:* Question about Records not authoritative for I was wondering if Bind allows you to override certain records for zones we are not authoritative for. Essentially we have a virus that some users have been infected with, and we want to temporarily blockout the domain name of the server that this virus connects to to send its information out. (Basically by having this domain name point to 127.0.0.1) I know it is a protocol violation, but I was just wondering if it is possible to do this and what would be the best way of going about it. We essentially have two servers with two views. One view serves our DNS zones to the outside world (With recursion disabled) and the other performs recursive queries for our on campus users. Obviously we would only be doing this on our internal view. Thomas E. Casartello, Jr. Staff Assistant - Wireless Technician/Linux Administrator Information Technology Wilson 105A Westfield State College (413) 572-8245 Red Hat Certified Technician (RHCT) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DDNS on SOA
Is it possible to update the SOA record of a zone via ddns update? Or do I have to shut bind down complete to change the SOA. Specifically the refresh timer. Thanks -- Peter (K0VX) http://www.planetnet.org 2CFF D38A 3F42 B215 2098 DA89 26C4 A1B6 3C6E 199F signature.asc Description: Digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DDNS on SOA
Yes, it is possible to change the SOA record by dynamic update. Just add a new one. Be careful about the serial number, though - the number may change due to other updates between the time you check it and the time you set it in the new SOA record, so add a sufficiently large increment. Chris Buxton Men Mice On Dec 11, 2008, at 12:29 PM, Peter Kringle wrote: Is it possible to update the SOA record of a zone via ddns update? Or do I have to shut bind down complete to change the SOA. Specifically the refresh timer. Thanks -- Peter (K0VX) http://www.planetnet.org 2CFF D38A 3F42 B215 2098 DA89 26C4 A1B6 3C6E 199F ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion for reverse/in-addr.arpa zones
Are there NS records and/or zone forwarding for the 10.131.10.0? If there is the servers will look to the most specfic domain. -- -Ben Croswell On Thu, Dec 11, 2008 at 4:38 PM, Todd Snyder tsny...@rim.com wrote: Good day, We are working on an odd issue. I can provide more detail as necessary, but don't want to fill this email with snips of useless stuff. All IP's/names provided are made up, as they don't matter in this problem as far as I can tell. This is more a functional question than a specific operating question. We have 2 servers acting as a slave for the zone 10.in-addr.arpa. The master(s) for this server are 2 Windows AD servers. Our servers (all bind9.4 of some variety) are doing zone transfers fine, and we're getting whatever is in the zone. We've run in to a couple IP's that when we dig them on these slaves, they are timing out. They are in a specific location, which we have determined are firewalled differently. For example, we are doing a dig for 10.131.10.1 against these 2 different locations. In one location, we get an answer quickly. In the other, it times out. The problem in our case is that in one location, the slave we're querying can't reach anything but the masters. What we've figured out is that the 10.in-addr.arpa zone doesn't contain EVERY 10. address we thought, but is missing some. In this case, our slaved zone doesn't have 10.131.10.1. But, instead of the slave server (which should be authortative) returning an I don't know error, it appears to be doing a recusive query. Against what, we're not 100% sure of yet. Well, we know which server, because DIG tells us, but we aren't sure why that one. When I look at the 10.in-addr.arpa zone, there are approximately 20 NS records for other AD servers. My speculation is that the slave we're querying is recusively looking to one of the servers returned in the additional section? This behaviour seems odd to us, and therein lies my question. Does doing a reverse lookup (dig -x) cause the queried server to behave differently than a forward lookup? My slave server is technically authoritative for the 10.in-addr.arpa zone, but it is still recusively going to another server to find an answer. Why? Is this because we have defined the zone as 10.in-addr.arpa instead of creating/slaving more specific zones (ie: 10.131.10.in-addr.arpa)? How can we control this behaviour? Thank you for any light you can shed on this - we're confident we know what is going on, but we can't figure out why the server behaves differently for reverse zones than it would for forward zones. Cheers, Todd. -- Todd Snyder Data Networks Tools bb.226.338.2617 Always On, Always Connected. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DDNS on SOA
In message 20081211202922.ga32...@sol.planetnet.org, Peter Kringle writes: Is it possible to update the SOA record of a zone via ddns update? Or do I= have to shut bind down complete to change the SOA. =20 Specifically the refresh timer. Thanks Yes. Just make sure that the serial number increases. -- 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: ISC launches new website and mailing list manager
You probably saw this, but the 9.5 html version is working now. https://www.isc.org/software/bind/documentation/arm95 Sue Matus UHLAR - fantomas wrote: On 17.11.08 05:10, Mark Andrews wrote: https://www.isc.org/software/bind/documentation which is in the bullet list as Documentation and external links (Reference manuals, FAQ, etc) on https://www.isc.org/software/bind - the HTML version of 9.5 ARM is said to be there, but I can't see the link (at least the BIND 9.5 isn't a link while BIND 9.4 is). - Why were HTML versions of previous ARM's removed? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Stats collection script for BIND 9.5 (and greater?)
Hi, I have written a script to collect data from the XML stats channel of a Bind 9.5+ DNS server. It works with Cricket and should work with MRTG and Cacti. You can get it here... http://members.iinet.com.au/~pyard...@ihug.com.au/ in the projects section under 'Bind 9.5 DNS Stats', or this is the direct link... http://members.iinet.com.au/~pyard...@ihug.com.au/#%5B%5BBIND%209.5%20DNS%20Stats%5D%5D Peter. -- UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology, Sydney. Before opening any attachments, please check them for viruses and defects. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
