No subject
Tue Apr 2 00:56:56 UTC 2013
time is being spent in dns_rbt_deletetreeflat, following pointers in a
tight loop.
I can probably live with things the way they are now, but if I find more
time to look at this I will probably attempt to build a profiling image to
confirm where the time is being spent.
Thanks for your help!
Regards,
-Chris
On Sat, 2 Oct 2004, JINMEI Tatuya / [ISO-2022-JP] ?@L at C#:H wrote:
> >>>>> On Sat, 02 Oct 2004 07:20:07 +0900,
> >>>>> JINMEI Tatuya <jinmei at isl.rdc.toshiba.co.jp> said:
>
> >> Yes - that is right. The daemon shuts down in ~6:36 now.
>
> > Hmm, okay. If you have time for an experimental, more-aggressive
> > solution, could you try the attached patch to see how it works (either
> > with or without ISC_MEM_USE_INTERNAL_MALLOC)? It will completely skip
> > freeing actual memory at the shutdown procedure.
>
> Oops, sorry, the previous patch was not really correct (it had missing
> initialization). Please use this one (attached below) instead.
------------------------------
From: phn at icke-reklam.ipsec.nu
Subject: Re: Restriction for large zones?
Date: Thu, 7 Oct 2004 04:41:24 +0000 (UTC)
Tom Schmitt <TomSchmitt at gmx.de> wrote:
> Hi,
> one of my dns-zones is growing large and has now nearly 100 thousands
> records. My question is: Is there a limit how large a zone could be?
> Or is there a limit of any kind at which the performance is no longer
> acceptable?
Small machiones ( 32-bits ) will have trouble when zone size
approaches 2GB. Besides that it's your memory size that is
the practical limit ( you don't want named to page ), so
make shure you have physical memory enought for all zone data.
> Thanks,
> Tom.
> --
> +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
> Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl
--
Peter Hekanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.
------------------------------
Date: Thu, 07 Oct 2004 15:44:24 +0900
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei at isl.rdc.toshiba.co.jp>
Subject: Re: daemon shutdown time with large zones (bind 9.2.4)
>>>>> On Wed, 6 Oct 2004 14:50:18 -0700 (PDT),
>>>>> Chris Timmons <cwt at networks.cwu.edu> said:
> It would appear that FreeBSD's free(3) isn't the main issue here; I built
> an image with the patch, and the performance is about the same as before.
Hmm. Just checking,
- did you try that with or without ISC_MEM_USE_INTERNAL_MALLOC (or
both)? After re-checking the patch, I noticed it was not effective
when ISC_MEM_USE_INTERNAL_MALLOC is enabled. (sorry, this was my
bad again).
- did you see the long period to shutdown the server even just after
starting it? If the bottleneck is not really in the memory
management but in that code traversing the DB structure, the problem
should occur even if the server does no actual work (i.e., only just
loading and destroying the DB).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei at isl.rdc.toshiba.co.jp
------------------------------
End of bind-users Digest V6 #264
********************************
------------------------------
From: mills at cc.umanitoba.ca (Gary Mills)
Subject: How to handle short TTLs?
Date: 7 Oct 2004 01:00:59 GMT
We've been getting complaints that web browsers time out when
they are attempting to access finance.yahoo.com. The problem
seems to be that that name resolves to a CNAME and an A record
that both have short TTLs:
finance.yahoo.com 300 IN CNAME finance.yahoo2.akadns.net
finance.yahoo2.akadns.net 60 IN A 216.109.119.250
Consequently, they are never in our DNS cache when the user browses
to that web site. When I test the lookup by hand, it does take
five or ten seconds for the response to appear. What can be done
about this? We are running the BIND 8.3.3 version that is shipped
with recent Solaris 9 releases.
--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
------------------------------
Subject: Re: DNS update via dhcp and static entries
From: David Botham <DBotham at OptimusSolutions.com>
Date: Thu, 7 Oct 2004 15:01:15 -0400
bind-users-bounce at isc.org wrote on 10/07/2004 09:14:29 AM:
> Hello,
>
> this is a little bit OT but I did not find a dhcp newsgroup.
http://www.isc.org/
On the left click Software->DHCP, and look for Mailing Lists on the right
side...
Dave...
> Our dhcp updates the dns and all works well except for machines where we
> have set fixed IP addresse via MAC.
> Is it dhcp that does not send the updates or can it be a problem in bin
?
>
> Thanks
>
------------------------------
Subject: Re: strange behavior of bind
From: David Botham <DBotham at OptimusSolutions.com>
Date: Thu, 7 Oct 2004 15:02:44 -0400
bind-users-bounce at isc.org wrote on 10/07/2004 08:26:31 AM:
> Hi there,
>
> i have a problem with my bind (9.2.3) I want to run bind in two
> instances of one maschine(ext-DNS and int-DNS). I`ve already
You may want to use 'views' instead.
Check out the BIND ARM.
Dave...
------------------------------
Subject: Re: Many '...query: . IN NS' in query log file
From: David Botham <DBotham at OptimusSolutions.com>
Date: Thu, 7 Oct 2004 15:05:41 -0400
bind-users-bounce at isc.org wrote on 10/07/2004 04:35:32 AM:
> David Botham <DBotham at OptimusSolutions.com> wrote in
> news:ck1i5t$lso$1 at sf1.isc.org:
>
> >> client 81.206.200.71#1026: query: . IN NS
> >
> > I am fairly certain this log entry indicates that the computer at IP
> > address 81.206.200.71 is asking your name server for the NS RR's for
> > the root zone.
>
> It seems clear, but is this normal that those servers asks that every
ten
> second ?
Normal, I do not know. Is it the same server that keeps asking? Are
those servers in your network and authorized to use your name server for
resolution? There are too many variables to answer that question. Perhaps
you can contact the admin of the system(s) in question and ask them what
is going on... If they are not in your network and not authorized to use
your name servers, use ACL's to exclude them...
Dave...
> Aren't they supposed to keep a cache of this kind of information ?
>
> --
> Nicolas Ecarnot
>
------------------------------
Date: Fri, 08 Oct 2004 04:07:11 +0900
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei at isl.rdc.toshiba.co.jp>
Subject: Re: IPv6 prefixes in ACLs in BIND 9.3.0 and 9.2.4 ?
>>>>> On Thu, 07 Oct 2004 12:50:16 -0400,
>>>>> Jason Vas Dias <jvdias at redhat.com> said:
> acl test {
> fec0:ac10:40a5:1/64;
> };
> acl test {
> fec0:ac10:40a5:0001/64;
> };
> acl test {
> fec0:ac10:40a5:0001 / 64;
> };
> acl test {
> fec0:ac10:40a5:1:/64;
> };
> acl test {
> f.e.c.0.a.c.1.0.4.0.a.5.0.0.0.1/64;
> };
None of the above are a valid IPv6 prefix. Please try, e.g.,
acl test {
fec0:ac10:40a5:1:: / 64;
};
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei at isl.rdc.toshiba.co.jp
p.s. the IETF has deprecated the site-local prefix, fec0::/10, (see
RFC3879). Although this does not necessarily mean applications do or
will reject the prefix, I'd basically recommend you to use global
prefixes, even for testing purposes.
------------------------------
Subject: Re: How to handle short TTLs?
From: David Botham <DBotham at OptimusSolutions.com>
Date: Thu, 7 Oct 2004 15:08:01 -0400
bind-users-bounce at isc.org wrote on 10/06/2004 09:00:59 PM:
> We've been getting complaints that web browsers time out when
> they are attempting to access finance.yahoo.com. The problem
> seems to be that that name resolves to a CNAME and an A record
> that both have short TTLs:
Yahoo uses Akimai. What you are seeing is their global load balancing.
Not much you can do about that.
>
> finance.yahoo.com 300 IN CNAME finance.yahoo2.akadns.net
> finance.yahoo2.akadns.net 60 IN A 216.109.119.250
>
> Consequently, they are never in our DNS cache when the user browses
> to that web site. When I test the lookup by hand, it does take
> five or ten seconds for the response to appear. What can be done
> about this? We are running the BIND 8.3.3 version that is shipped
> with recent Solaris 9 releases.
>
>
> --
> -Gary Mills- -Unix Support- -U of M Academic Computing and
Networking-
>
------------------------------
Date: Thu, 07 Oct 2004 15:10:57 -0400
From: Kevin Darcy <kcd at daimlerchrysler.com>
Subject: Re: DNS update via dhcp and static entries
Andreas Moroder wrote:
>Hello,
>
>this is a little bit OT but I did not find a dhcp newsgroup.
>Our dhcp updates the dns and all works well except for machines where we
>have set fixed IP addresse via MAC.
>Is it dhcp that does not send the updates or can it be a problem in bin ?
>
Static means static. Why would it be necessary to send updates to DNS?
Just configure the name in DNS once and you're done...
- Kevin
------------------------------
Date: Thu, 07 Oct 2004 12:19:53 -0700
From: Norman Zhang <norman.zhang at rd.arkonnetworks.com>
Subject: Re: DNS update via dhcp and static entries
>>this is a little bit OT but I did not find a dhcp newsgroup.
>>Our dhcp updates the dns and all works well except for machines where we
>>have set fixed IP addresse via MAC.
>>Is it dhcp that does not send the updates or can it be a problem in bin ?
>
> Static means static. Why would it be necessary to send updates to DNS?
> Just configure the name in DNS once and you're done...
My Windows Server 2003 has a static IP, but AD requires it to DDNS.
Regards,
Norman
------------------------------
Date: Thu, 07 Oct 2004 15:20:12 -0400
From: Kevin Darcy <kcd at daimlerchrysler.com>
Subject: Re: How to handle short TTLs?
Gary Mills wrote:
>We've been getting complaints that web browsers time out when
>they are attempting to access finance.yahoo.com. The problem
>seems to be that that name resolves to a CNAME and an A record
>that both have short TTLs:
>
> finance.yahoo.com 300 IN CNAME finance.yahoo2.akadns.net
> finance.yahoo2.akadns.net 60 IN A 216.109.119.250
>
>Consequently, they are never in our DNS cache when the user browses
>to that web site. When I test the lookup by hand, it does take
>five or ten seconds for the response to appear. What can be done
>about this? We are running the BIND 8.3.3 version that is shipped
>with recent Solaris 9 releases.
>
I can resolve finance.yahoo.com in 150 msec even without the CNAME or
the A record in my cache. So I think there's more to your problem than
just the shortness of the TTLs...
- Kevin
------------------------------
Date: Thu, 07 Oct 2004 15:23:51 -0400
From: Kevin Darcy <kcd at daimlerchrysler.com>
Subject: Re: DNS update via dhcp and static entries
Norman Zhang wrote:
>>>this is a little bit OT but I did not find a dhcp newsgroup.
>>>Our dhcp updates the dns and all works well except for machines where we
>>>have set fixed IP addresse via MAC.
>>>Is it dhcp that does not send the updates or can it be a problem in bin ?
>>>
>>>
>>Static means static. Why would it be necessary to send updates to DNS?
>>Just configure the name in DNS once and you're done...
>>
>>
>
>My Windows Server 2003 has a static IP, but AD requires it to DDNS.
>
Complain to Microsoft.
- Kevin
------------------------------
Date: Thu, 07 Oct 2004 12:32:21 -0700
From: Norman Zhang <norman.zhang at rd.arkonnetworks.com>
Subject: Re: DNS update via dhcp and static entries
>>>Static means static. Why would it be necessary to send updates to DNS?
>>>Just configure the name in DNS once and you're done...
>>
>>My Windows Server 2003 has a static IP, but AD requires it to DDNS.
>
> Complain to Microsoft.
I'm fine with it. I'm just pointing out there is case where static IP
wants to do DDNS. There are lots of entries that AD needs to associate
with in DNS.
Regards,
Norman
------------------------------
Date: Thu, 7 Oct 2004 16:06:40 -0500
From: Pete Ehlke <pde at rfc822.net>
Subject: Re: Many '...query: . IN NS' in query log file
On Thu Oct 07, 2004 at 08:35:32 +0000, Nicolas Ecarnot wrote:
>David Botham <DBotham at OptimusSolutions.com> wrote in
>news:ck1i5t$lso$1 at sf1.isc.org:
>
>>> client 81.206.200.71#1026: query: . IN NS
>>
>> I am fairly certain this log entry indicates that the computer at IP
>> address 81.206.200.71 is asking your name server for the NS RR's for
>> the root zone.
>
>It seems clear, but is this normal that those servers asks that every ten
>second ?
>Aren't they supposed to keep a cache of this kind of information ?
>
It may not be a server at all. There are a lot of poorly done stub
resolvers out there in the world (written in to web browsers, for
example) that do this sort of thing. It might be 'normal' for the
application that is doing the querying, but the liklihood that it is
'correct' is fairly low ;)
-Pete
------------------------------
Date: Thu, 7 Oct 2004 16:52:00 -0400
From: Patrick Chiang <saikang at gmail.com>
Subject: DNS Slave server CANNOT get zone files from Master Server
Hi everybody,
I think my question is probably a FAQ, but I still can't find an answer
from the Internet. Hope someone can give me some hints to fix my
problems.
I have a master DNS Server working properly, which connects to internet
directly. Recently I setup a Slave DNS server "behind" a simple firewall
(actually it's a wireless router D-Link DI-524 with NAT), I've set up a
mapping to my internal Slave DNS Server, 192.168.0.254.
I was wondering should I open some firewall ports to help them do "Zone
Transfer" ? I've opened TCP/UDP 53 everywhere (Maser/Slave DNS Server
with iptables, wireless rounter TCP/UDP 53) and I expected there would
be a zone file appear in /var/named/chroot/var/named/slave - I was told
that this was a good sign that master server had successfully transfered
zone file(s) to slave server. Am I correct ?
Below is my settings. Hopefully anyone in the list can help me find out
the errors. Thanks in advance :)
----------- Envrionemt -----------------------
Master&Slave are Fedora Core 2,BIND 9.2.3-13
----------- Cfg filez ------------------------
Master DNS (ip address: 55.66.77.88)
-----------------------------------------------
/var/named/chroot/etc/named.conf
-----------------------------------------------
options {
directory "/var/named";
statistics-file "/var/run/named/named.stats";
};
----<snip>---
zone "foo.org" IN{
type master;
file "foo.org.domain";
zone-statistics yes;
notify yes;
also-notify { 11.22.33.44; };
};
-----------------------------------------------
Slave (ip address: 11.22.33.44)
-----------------------------------------------
/var/named/chroot/etc/named.conf (Copy from master's)
-----------------------------------------------
<snip>
zone "foo.org" IN{
type slave;
file "slave/foo.org.domain.bak";
masters { 55.66.77.88; };
zone-statistics yes;
};
-------------------------------------------------
O U T P U T (on slave DNS server)
-------------------------------------------------
# rndc reload
named[25483]: zone foo.org/IN: refresh: non-authoritative answer from
master 55.66.77.88#53
ps.
/var/named/chroot/var/named/slaves is "drwxrwx---", owned by named:named
------------------------------
Date: Thu, 07 Oct 2004 17:32:27 -0400
From: Kevin Darcy <kcd at daimlerchrysler.com>
Subject: Re: DNS Slave server CANNOT get zone files from Master Server
"non-authoritative answer from master" usually means that the zone
didn't load properly on the master server. Look at your logs to see why,
or run named-checkzone.
- Kevin
Patrick Chiang wrote:
>Hi everybody,
>
>I think my question is probably a FAQ, but I still can't find an answer
>from the Internet. Hope someone can give me some hints to fix my
>problems.
>
>I have a master DNS Server working properly, which connects to internet
>directly. Recently I setup a Slave DNS server "behind" a simple firewall
>(actually it's a wireless router D-Link DI-524 with NAT), I've set up a
>mapping to my internal Slave DNS Server, 192.168.0.254.
>
>I was wondering should I open some firewall ports to help them do "Zone
>Transfer" ? I've opened TCP/UDP 53 everywhere (Maser/Slave DNS Server
>with iptables, wireless rounter TCP/UDP 53) and I expected there would
>be a zone file appear in /var/named/chroot/var/named/slave - I was told
>that this was a good sign that master server had successfully transfered
>zone file(s) to slave server. Am I correct ?
>
>Below is my settings. Hopefully anyone in the list can help me find out
>the errors. Thanks in advance :)
>
>----------- Envrionemt -----------------------
>Master&Slave are Fedora Core 2,BIND 9.2.3-13
>
>----------- Cfg filez ------------------------
>Master DNS (ip address: 55.66.77.88)
>-----------------------------------------------
>/var/named/chroot/etc/named.conf
>-----------------------------------------------
>options {
> directory "/var/named";
> statistics-file "/var/run/named/named.stats";
>};
>----<snip>---
>zone "foo.org" IN{
> type master;
> file "foo.org.domain";
> zone-statistics yes;
> notify yes;
> also-notify { 11.22.33.44; };
>};
>
>-----------------------------------------------
>Slave (ip address: 11.22.33.44)
>-----------------------------------------------
>/var/named/chroot/etc/named.conf (Copy from master's)
>-----------------------------------------------
><snip>
>zone "foo.org" IN{
> type slave;
> file "slave/foo.org.domain.bak";
> masters { 55.66.77.88; };
> zone-statistics yes;
>};
>
>-------------------------------------------------
>O U T P U T (on slave DNS server)
>-------------------------------------------------
># rndc reload
>named[25483]: zone foo.org/IN: refresh: non-authoritative answer from
>master 55.66.77.88#53
>
>ps.
>/var/named/chroot/var/named/slaves is "drwxrwx---", owned by named:named
>
>
>
>
>
>
------------------------------
Date: Thu, 07 Oct 2004 17:33:25 -0400
Subject: Re: DNS Slave server CANNOT get zone files from Master Server
From: "Sebastian Castro Avila" <secastro at nic.cl>
On Thu, 7 Oct 2004 16:52:00 -0400, Patrick Chiang <saikang at gmail.com>
wrote:
> Hi everybody,
>
Hi:
> -----------------------------------------------
> Slave (ip address: 11.22.33.44)
> -----------------------------------------------
> /var/named/chroot/etc/named.conf (Copy from master's)
> -----------------------------------------------
> <snip>
> zone "foo.org" IN{
> type slave;
> file "slave/foo.org.domain.bak";
> masters { 55.66.77.88; };
> zone-statistics yes;
> };
>
> -------------------------------------------------
> O U T P U T (on slave DNS server)
> -------------------------------------------------
> # rndc reload
> named[25483]: zone foo.org/IN: refresh: non-authoritative answer from
> master 55.66.77.88#53
>
> ps.
> /var/named/chroot/var/named/slaves is "drwxrwx---", owned by named:named
Here's the problem.
You master server HAS TO BE authoritative for the zone, to be able to
"give" the zone to the secondary server. You should check the zone syntax
using "named-checkzone" or view you primary's logs to check where is the
error.
Correct the zone, reload it and check using DIG.
dig soa foo.org @55.66.77.88, you should look for a line like
;; flags: qr aa rd;
and be sure that answer with "aa" (Authoritative Answer).
As a third step, go to any terminal in your slave and try
dig axfr foo.org @55.66.77.88
That will show you the whole zone.
Finally, try "rndc refresh foo.org" in your secondary, to synchronize
slave with master.
I hope this helps.
Best Regards
--
Sebastian E. Castro Avila sebastian at nic.cl
Administrador de DNS, NIC Chile
Fono: (2) 9407705 Fax : (2) 9407701
------------------------------
From: Mark Andrews <Mark_Andrews at isc.org>
Subject: Re: upgrade bind8.x to bind9.x in RH6.2
Date: Fri, 08 Oct 2004 07:34:23 +1000
> Hai,
> Due to some reasons, still I am using RH6.2 where
> bind8.2 is running. Now I need to upgrade to bind 9.x
> and got the following error when I start named after
> upgradation
>
> # /etc/rc.d/init.d/named start
>
> Starting named: named: -u not supported on Linux
> kernels older than 2.3.99-pre3 or 2.2.18 when using
> threads
>
> [FAILED]
>
> If I haven't specified '-u named' option in named
> script, then it will try to start bind as root user.
>
> Is there any way I can run bind using 'named' user?
>
>
> Sarav
-u fails at this point, with a threaded build, for one of
these reasons.
* The kernel is to old to support capabilities.
* The kernel does not have the capabilities module loaded.
* You have disabled capabilities at build time.
* PR_SET_KEEPCAPS is not supported.
Linux's threads are broken. You cannot call setuid() once
you are multithreaded. Named uses Linux's capabilities to
work around this by keeping the ability to bind to reserved
sockets after the setuid() call.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
------------------------------
From: Mark Andrews <Mark_Andrews at isc.org>
Subject: Re: strange behavior of bind
Date: Fri, 08 Oct 2004 07:51:23 +1000
> bind-users-bounce at isc.org wrote on 10/07/2004 08:26:31 AM:
> > Hi there,
> >
> > i have a problem with my bind (9.2.3) I want to run bind in two
> > instances of one maschine(ext-DNS and int-DNS). I`ve already
>
> You may want to use 'views' instead.
>
> Check out the BIND ARM.
>
>
> Dave...
Or not specify the port to query-source / notify-source /
transfer-source.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
------------------------------
From: Mark Andrews <Mark_Andrews at isc.org>
Subject: Re: How to handle short TTLs?
Date: Fri, 08 Oct 2004 08:20:22 +1000
> Gary Mills wrote:
>
> >We've been getting complaints that web browsers time out when
> >they are attempting to access finance.yahoo.com. The problem
> >seems to be that that name resolves to a CNAME and an A record
> >that both have short TTLs:
> >
> > finance.yahoo.com 300 IN CNAME finance.yahoo2.akadns.net
> > finance.yahoo2.akadns.net 60 IN A 216.109.119.250
> >
> >Consequently, they are never in our DNS cache when the user browses
> >to that web site. When I test the lookup by hand, it does take
> >five or ten seconds for the response to appear. What can be done
> >about this? We are running the BIND 8.3.3 version that is shipped
> >with recent Solaris 9 releases.
> >
> I can resolve finance.yahoo.com in 150 msec even without the CNAME or
> the A record in my cache. So I think there's more to your problem than
> just the shortness of the TTLs...
>
>
> - Kevin
Correct. He has a firewall which is blocking the EDNS
replies. He needs to upgrade / configure the firewall.
Note the size of the response packet below exceeds the
plain DNS response size.
In the meantime he can set "edns-udp-size 512;" (9.3.0,
8.4.0) though it defeats one of the purposes of using EDNS.
The real fix is to upgrade the firewall.
Mark
Network Working Group P. Vixie
Request for Comments: 2671 ISC
Category: Standards Track August 1999
Extension Mechanisms for DNS (EDNS0)
; <<>> DiG 8.3 <<>> finance.yahoo.com +norec @ns1.yahoo.com +dnssec
; (1 server found)
;; res options: init defnam dnsrch dnssec
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38005
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 14
;; QUERY SECTION:
;; finance.yahoo.com, type = A, class = IN
;; ANSWER SECTION:
finance.yahoo.com. 5M IN CNAME finance.yahoo2.akadns.net.
;; AUTHORITY SECTION:
net. 11h42m42s IN NS K.GTLD-SERVERS.net.
net. 11h42m42s IN NS L.GTLD-SERVERS.net.
net. 11h42m42s IN NS M.GTLD-SERVERS.net.
net. 11h42m42s IN NS A.GTLD-SERVERS.net.
net. 11h42m42s IN NS B.GTLD-SERVERS.net.
net. 11h42m42s IN NS C.GTLD-SERVERS.net.
net. 11h42m42s IN NS D.GTLD-SERVERS.net.
net. 11h42m42s IN NS E.GTLD-SERVERS.net.
net. 11h42m42s IN NS F.GTLD-SERVERS.net.
net. 11h42m42s IN NS G.GTLD-SERVERS.net.
net. 11h42m42s IN NS H.GTLD-SERVERS.net.
net. 11h42m42s IN NS I.GTLD-SERVERS.net.
net. 11h42m42s IN NS J.GTLD-SERVERS.net.
;; ADDITIONAL SECTION:
K.GTLD-SERVERS.net. 11h42m42s IN A 192.52.178.30
L.GTLD-SERVERS.net. 11h42m42s IN A 192.41.162.30
M.GTLD-SERVERS.net. 11h42m42s IN A 192.55.83.30
A.GTLD-SERVERS.net. 11h42m42s IN A 192.5.6.30
B.GTLD-SERVERS.net. 11h42m42s IN A 192.33.14.30
C.GTLD-SERVERS.net. 11h42m42s IN A 192.26.92.30
D.GTLD-SERVERS.net. 11h42m42s IN A 192.31.80.30
E.GTLD-SERVERS.net. 11h42m42s IN A 192.12.94.30
F.GTLD-SERVERS.net. 11h42m42s IN A 192.35.51.30
G.GTLD-SERVERS.net. 11h42m42s IN A 192.42.93.30
H.GTLD-SERVERS.net. 11h42m42s IN A 192.54.112.30
I.GTLD-SERVERS.net. 11h42m42s IN A 192.43.172.30
J.GTLD-SERVERS.net. 11h42m42s IN A 192.48.79.30
; EDNS: version: 0, udp=4096, flags=0000
;; Total query time: 180 msec
;; FROM: drugs.dv.isc.org to SERVER: 66.218.71.63
;; WHEN: Fri Oct 8 08:03:22 2004
;; MSG SIZE sent: 46 rcvd: 514
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
------------------------------
End of bind-users Digest V6 #265
********************************
More information about the bind-users
mailing list