3:20 p.m.
I've done "yum install caching-nameserver" and with a few crude tests
it appears that it might be working.
Is there a file of cached addresses that I can look at and see that
they are actually being cached?
Bob Goodwin
4:40 p.m.
Bob Goodwin wrote:
I've done "yum install caching-nameserver" and with a few crude tests
it appears that it might be working.
Is there a file of cached addresses that I can look at and see that
they are actually being cached?
Not that I know of....
However, you can do a "host -v somehost.com" were somehost is equal to a
host name you've not visited. The first time you do it you may see
something like:
Received 194 bytes from 127.0.0.1#53 in 1291 ms
But if you do it again, and it is working, you should see something on
the order of:
Received 194 bytes from 127.0.0.1#53 in 1 ms
--
We are not loved by our friends for what we are; rather, we are loved in
spite of what we are.
-- Victor Hugo
4:58 p.m.
*Ed Greshko wrote:*
*Bob Goodwin wrote:
*
> *I've done "yum install caching-nameserver" and with a few crude tests
> it appears that it might be working.
>
> Is there a file of cached addresses that I can look at and see that
> they are actually being cached?
> *
*
Not that I know of....
However, you can do a "host -v somehost.com" were somehost is equal to a
host name you've not visited. The first time you do it you may see
something like:
Received 194 bytes from 127.0.0.1#53 in 1291 ms
But if you do it again, and it is working, you should see something on
the order of:
Received 194 bytes from 127.0.0.1#53 in 1 ms
*
*Ok, I tried:
*
*host -v speakeasy.net *
*First time:
Received 109 bytes from 127.0.0.1#53 in 745 ms
Second time:
Received 109 bytes from 127.0.0.1#53 in 105 ms
That would seem to indicate that it works?
I'm not sure it's of much value considering the round trip time to the
satellite but I guess every little bit helps. I was timing the "Looking
up google.com" or whatever at the bottom of the Thunderbird screen and
timing that. It looked faster after the initial trial ...
Thank you.
Bob Goodwin
*
5:24 p.m.
On Mon, 2006-08-21 at 17:58 -0400, Bob Goodwin wrote:
I'm not sure it's of much value considering the round trip
time to the
satellite but I guess every little bit helps.
But can caching-nameserver be configured with a list of ad sites
it will always reject as not valid? That would be the real value
add :-).
4:04 a.m.
On Mon, 2006-08-21 at 18:24 -0400, Tom Horsley wrote:
But can caching-nameserver be configured with a list of ad sites
it will always reject as not valid? That would be the real value
add :-).
Yes, but you'll have to redo the configuration if you update the name
server (simple enough to do if you keep a backup, you've just got to
remember to so). The caching package is a pre-configured system. You
can manually configure the server in the same way, not using the caching
pre-configuration package, to avoid that little snag.
I have a collection of entries in my /etc/named.conf file like this:
------- begin paste -------
zone "doubleclick.net" { type master; file "dead.zone"; };
zone "doubleclick.com" { type master; file "dead.zone"; };
zone "ads.optusnet.com.au" { type master; file "dead.zone"; };
------- end paste -------
And this is the /var/named/chroot/var/named/dead.zone file:
------- begin paste -------
$TTL 86400
@ IN SOA ns.localdomain. hostmaster.mail.localdomain. (
200 ; serial
28800 ; refresh
7200 ; retry
604800 ; expire
86400 ; ttl
)
IN NS ns.localdomain.
------- end paste -------
It ensures that there is no IP address returned for the query, at all,
so they instantly fail (may require configuration of some browsers not
to throw up annoying pop-up error warnings in the way).
I found this better than directing all queries at a real IP address. It
was slower, and meant that I had to have a local webserver running.
--
(Currently running FC4, in case that's important to the thread)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
5:59 p.m.
From: "Bob Goodwin" <bobgoodwin(a)wildblue.net>
*Ed Greshko wrote:*
> *Bob Goodwin wrote:
> *
>> *I've done "yum install caching-nameserver" and with a few crude
tests
>> it appears that it might be working.
>>
>> Is there a file of cached addresses that I can look at and see that
>> they are actually being cached?
>> *
> *
> Not that I know of....
>
> However, you can do a "host -v somehost.com" were somehost is equal to a
> host name you've not visited. The first time you do it you may see
> something like:
>
> Received 194 bytes from 127.0.0.1#53 in 1291 ms
>
> But if you do it again, and it is working, you should see something on
> the order of:
>
> Received 194 bytes from 127.0.0.1#53 in 1 ms
> *
*Ok, I tried:
*
*host -v speakeasy.net *
*First time:
Received 109 bytes from 127.0.0.1#53 in 745 ms
Second time:
Received 109 bytes from 127.0.0.1#53 in 105 ms
That would seem to indicate that it works?
I'm not sure it's of much value considering the round trip time to the
satellite but I guess every little bit helps. I was timing the "Looking
up google.com" or whatever at the bottom of the Thunderbird screen and
timing that. It looked faster after the initial trial ...
No - that would include cached images and all that nonsense. Use the
commandline and something like "host nlzero.com", one I bet you have
never touched before. Google you have touched before regularly and
is probably still cached.
Round trip to the satellite? Then the second one did not come via
the satellite. But the delay is incredibly long for coming from
something local. (The first one does look like a satellite hop round
trip, potentially. One hop is a touch over 1/4 second absolute minimum.
Add to that some overhead for communications reliability and the
satellite's processing time, also.)
{^_^}
6:28 p.m.
*jdow wrote:*
*From: "Bob Goodwin" <bobgoodwin(a)wildblue.net>
*
> **Ed Greshko wrote:*
> *
>> **Bob Goodwin wrote:
>> *
>> *
>>> **I've done "yum install caching-nameserver" and with a few
crude
>>> tests
>>> it appears that it might be working.
>>>
>>> Is there a file of cached addresses that I can look at and see that
>>> they are actually being cached?
>>> *
>>> *
>> **
>> Not that I know of....
>>
>> However, you can do a "host -v somehost.com" were somehost is equal
>> to a
>> host name you've not visited. The first time you do it you may see
>> something like:
>>
>> Received 194 bytes from 127.0.0.1#53 in 1291 ms
>>
>> But if you do it again, and it is working, you should see something on
>> the order of:
>>
>> Received 194 bytes from 127.0.0.1#53 in 1 ms
>> *
>> *
> **Ok, I tried:
> *
>
> *host -v speakeasy.net *
>
> *First time:
>
> Received 109 bytes from 127.0.0.1#53 in 745 ms
>
> Second time:
>
> Received 109 bytes from 127.0.0.1#53 in 105 ms
>
> That would seem to indicate that it works?
>
> I'm not sure it's of much value considering the round trip time to
> the satellite but I guess every little bit helps. I was timing the
> "Looking up google.com" or whatever at the bottom of the Thunderbird
> screen and timing that. It looked faster after the initial trial ...
> *
*
No - that would include cached images and all that nonsense. Use the
commandline and something like "host nlzero.com", one I bet you have
never touched before. Google you have touched before regularly and
is probably still cached.
Round trip to the satellite? Then the second one did not come via
the satellite. But the delay is incredibly long for coming from
something local. (The first one does look like a satellite hop round
trip, potentially. One hop is a touch over 1/4 second absolute minimum.
Add to that some overhead for communications reliability and the
satellite's processing time, also.)
{^_^}
*
*Yeah, the satellite introduces a bit less than 500 ms of delay for transit
time in addition to the usual system delays. When I look at ntpq I see
typically 600-700 ms there.
I thought the 100 ms I'm seeing for the local dns looked long but I have no
experience other than this. As it is it's till less than the 700-800
otherwise.
Yes, I understand that google is frequently used and should be in the
local cache,
that was merely an example, thought I made that clear.
Bob Goodwin
*
7:14 p.m.
Bob Goodwin wrote:
*jdow wrote:*
> *From: "Bob Goodwin" <bobgoodwin(a)wildblue.net>
> *
>> **Ed Greshko wrote:*
>> *
>>> **Bob Goodwin wrote:
>>> *
>>> *
>>>> **I've done "yum install caching-nameserver" and with a few
crude
>>>> tests
>>>> it appears that it might be working.
>>>>
>>>> Is there a file of cached addresses that I can look at and see that
>>>> they are actually being cached?
>>>> *
>>>> *
>>> **
>>> Not that I know of....
>>>
>>> However, you can do a "host -v somehost.com" were somehost is equal
>>> to a
>>> host name you've not visited. The first time you do it you may see
>>> something like:
>>>
>>> Received 194 bytes from 127.0.0.1#53 in 1291 ms
>>>
>>> But if you do it again, and it is working, you should see something on
>>> the order of:
>>>
>>> Received 194 bytes from 127.0.0.1#53 in 1 ms
>>> *
>>> *
>> **Ok, I tried:
>> *
>>
>> *host -v speakeasy.net *
>>
>> *First time:
>>
>> Received 109 bytes from 127.0.0.1#53 in 745 ms
>>
>> Second time:
>>
>> Received 109 bytes from 127.0.0.1#53 in 105 ms
>>
>> That would seem to indicate that it works?
>>
>> I'm not sure it's of much value considering the round trip time to
>> the satellite but I guess every little bit helps. I was timing the
>> "Looking up google.com" or whatever at the bottom of the Thunderbird
>> screen and timing that. It looked faster after the initial trial ...
>> *
> *
> No - that would include cached images and all that nonsense. Use the
> commandline and something like "host nlzero.com", one I bet you have
> never touched before. Google you have touched before regularly and
> is probably still cached.
>
> Round trip to the satellite? Then the second one did not come via
> the satellite. But the delay is incredibly long for coming from
> something local. (The first one does look like a satellite hop round
> trip, potentially. One hop is a touch over 1/4 second absolute minimum.
> Add to that some overhead for communications reliability and the
> satellite's processing time, also.)
>
> {^_^}
>
> *
*Yeah, the satellite introduces a bit less than 500 ms of delay for
transit
time in addition to the usual system delays. When I look at ntpq I see
typically 600-700 ms there.
I thought the 100 ms I'm seeing for the local dns looked long but I
have no
experience other than this. As it is it's till less than the 700-800
otherwise. Yes, I understand that google is frequently used and should
be in the local cache,
that was merely an example, thought I made that clear.
Bob Goodwin
*
Now another problem, I rebooted the computer and /etc/resolv.conf
is re-written without the "nameserver 127.0.0.1" line and whatever
cache was collected is gone, so the local stuff has to be collected again.
That and now you've got me worried about the time, I'm still seeing
130-150 ms,
much shorter than using the Wildblue dns server but perhaps it should be
better?
Before and after for "host -v google.com"
Received 252 bytes from 127.0.0.1#53 in 917 ms
Received 252 bytes from 127.0.0.1#53 in 151 ms
Bob Goodwin
12:57 a.m.
Bob Goodwin wrote:
Before and after for "host -v google.com"
Received 252 bytes from 127.0.0.1#53 in 917 ms
Received 252 bytes from 127.0.0.1#53 in 151 ms
Actually, the 100% sure way to know that your caching name server is
working is to run something like "tcpdump" or "ethereal" and capture
only packets for port 53.
When you do a "host" for a known non-cached host you'll see the query
going out. The second time you do the "host" you should not see a query
going out.
Ed
2:38 a.m.
Ed Greshko wrote:
Bob Goodwin wrote:
> Before and after for "host -v google.com"
>
> Received 252 bytes from 127.0.0.1#53 in 917 ms
> Received 252 bytes from 127.0.0.1#53 in 151 ms
>
Actually, the 100% sure way to know that your caching name server is
working is to run something like "tcpdump" or "ethereal" and capture
only packets for port 53.
When you do a "host" for a known non-cached host you'll see the query
going out. The second time you do the "host" you should not see a query
going out.
Ed*
*
*Ethereal might work but set-up is beyond me! I'll have to look at that
for a while. But "locate" found "tetehereal" which showed DNS
activity
clearly on the first lookup and nothing on subsequent tries which I
interpret
as an indication that it is working. The times measured with "host" are
still varying
widely from as little as ~10 ms to typically a bit more than 100 ms?
And the need to rewrite "resolv.conf" after reboot is bothersome as is the
loss of the cached address data when that is done although I suspect
that may be done
to accommodate address changes?
Bob
*
2:57 a.m.
Bob Goodwin wrote:
*Ethereal might work but set-up is beyond me! I'll have to look
at that
for a while. But "locate" found "tetehereal" which showed DNS
activity
clearly on the first lookup and nothing on subsequent tries which I
interpret as an indication that it is working. The times measured with "host"
are
still varying widely from as little as ~10 ms to typically a bit more than 100 ms?
Could be a function of how busy your system and/or CPU size, memory, etc.
And the need to rewrite "resolv.conf" after reboot is
bothersome as is the
loss of the cached address data when that is done although I suspect
that may be done to accommodate address changes?
Well, you can prevent "resolv.conf" from being overwritten. You uncheck
the "Automatically obtain DNS information from provider" selection in
the configuration of your Internet connection.
You will lose the cache on a reboot since that information is contained
in memory.
Also, if you don't access a given site again within the time specified
by the TTL (Time To Live) setting of the master DNS the cache for the
host will be cleared and a new request will be sent.
Ed
--
Calculon: I've seen plagues that had better opening nights than this.
3:12 a.m.
Ed Greshko wrote:
Bob Goodwin wrote:
> *Ethereal might work but set-up is beyond me! I'll have to look at that
> for a while. But "locate" found "tetehereal" which showed DNS
activity
> clearly on the first lookup and nothing on subsequent tries which I
> interpret as an indication that it is working. The times measured with
"host" are
> still varying widely from as little as ~10 ms to typically a bit more than 100 ms?
>
Could be a function of how busy your system and/or CPU size, memory, etc.
> And the need to rewrite "resolv.conf" after reboot is bothersome as is the
> loss of the cached address data when that is done although I suspect
> that may be done to accommodate address changes?
>
*
Well, you can prevent "resolv.conf" from being overwritten. You uncheck
the "Automatically obtain DNS information from provider" selection in
the configuration of your Internet connection.
*
That wouldn't be a viable solution.
*
You will lose the cache on a reboot since that information is contained
in memory.
Also, if you don't access a given site again within the time specified
by the TTL (Time To Live) setting of the master DNS the cache for the
host will be cleared and a new request will be sent.
*
*Interesting, now I'm curious to see what "TTL" is set to?
*
*
Ed
*
*Thanks for the help.
BobG*
3:46 a.m.
Ed Greshko:
> you can prevent "resolv.conf" from being overwritten.
You
> uncheck the "Automatically obtain DNS information from provider"
> selection in the configuration of your Internet connection.
Bob Goodwin:
That wouldn't be a viable solution.
Why not? Once you're running your own name server, you don't need the
ISP's for using the internet. You may find, with some ISPs, that you
might need to use their name servers to resolve names within their own
network (their mailserver, newserver, etc.). You can just put their DNS
server IP addresses into your name.conf as a "forwarder". Your own
server will then use it for requests it can't manage itself.
--
(Currently running FC4, in case that's important to the thread)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
6:16 a.m.
On Tue, 2006-08-22 at 04:12 -0400, Bob Goodwin wrote:
Ed Greshko wrote:
> Well, you can prevent "resolv.conf" from being overwritten. You uncheck
> the "Automatically obtain DNS information from provider" selection in
> the configuration of your Internet connection.
> *
That wouldn't be a viable solution.
Hi Bob,
If you are running the caching server on a system without X, you can
still do this:
Assuming that you are using your 2nd network interface (eth1), then you
need to edit /etc/sysconfig/network-scripts/ifcfg-eth1. Locate the line
PEERDNS and change it from PEERDNS=yes to PEERDNS=no. When you reboot,
the /etc/resolv.conf will not get over-written.
--
Pascal Chong
email: chongym(a)cymulacrum.net
web: http://cymulacrum.net
pgp: http://cymulacrum.net/pgp/cymulacrum.asc
"La science ne connaît pas de frontière parce que la connaissance
appartient à l’humanité. et que c’est la flamme qui illumine le monde."
-- Louis Pasteur
8:32 a.m.
*Chong Yu Meng wrote:*
*
Hi Bob,
If you are running the caching server on a system without X, you can
still do this:
Assuming that you are using your 2nd network interface (eth1), then you
need to edit /etc/sysconfig/network-scripts/ifcfg-eth1. Locate the line
PEERDNS and change it from PEERDNS=yes to PEERDNS=no. When you reboot,
the /etc/resolv.conf will not get over-written.
*
*Chong:
"edit /etc/sysconfig/network-scripts/ifcfg-eth1 [eth0 in this case].
Locate the line
*
*PEERDNS and change it from PEERDNS=yes to PEERDNS=no"
That seems to have fixed that problem.
Thanks.
BobG
*
10:09 p.m.
On 22Aug2006 04:12, Bob Goodwin <bobgoodwin(a)wildblue.net> wrote:
| >>And the need to rewrite "resolv.conf" after reboot is bothersome as is
the
| >>loss of the cached address data when that is done although I suspect
| >>that may be done to accommodate address changes?
| >*
| >Well, you can prevent "resolv.conf" from being overwritten. You uncheck
| >the "Automatically obtain DNS information from provider" selection in
| >the configuration of your Internet connection.
| >*
| That wouldn't be a viable solution.
I've been doing the dhclient kickoff, then sucking the DNS entries out
of /etc/resolv.conf into the named.conf file, starting the local named,
and putting 127.0.0.1 in my resolv.conf for quite a while now. This:
http://www.cskk.ezoshosting.com/cs/css/bin/rig-named.conf
sucks the IPs from /etc/resolv.conf and the whole incantation after DHCP
has run is:
if rig-named.conf
then
bsed '/nameserver/d' /etc/resolv.conf
echo nameserver 127.0.0.1 >>/etc/resolv.conf
fi
bsed and rlr come from the same script collection.
--
Cameron Simpson <cs(a)zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
Here was a man who not only had a ready mind and a quick wit,
but could also sing. - _Rope_
3:16 a.m.
From: "Bob Goodwin" <bobgoodwin(a)wildblue.net>
Bob Goodwin wrote:
Before and after for "host -v google.com"
Received 252 bytes from 127.0.0.1#53 in 917 ms
Received 252 bytes from 127.0.0.1#53 in 151 ms
The caching name server should respond in a millisecond or so.
You probably need to use the networking GUI to make the change
to resolv.conf permanent, too.
Hm, those are "host -v" responses which do include a lot of data.
The time you're seeing is mostly what it takes to print it to the
screen. Try "host -a". It's a shorter printout. (Regardless -v on
google is about 2ms here. It just performs several queries each with
its own 2ms or 3ms. That's not long enough to leave this system and
get anywhere else. Ping time to the first hop is about 25ms.)
{^_^}
3:56 a.m.
On Tue, 2006-08-22 at 05:40 +0800, Ed Greshko wrote:
The first time you do it you may see something like:
Received 194 bytes from 127.0.0.1#53 in 1291 ms
But if you do it again, and it is working, you should see something on
the order of:
Received 194 bytes from 127.0.0.1#53 in 1 ms
If I do something like "dig google.com", the first results come back
after a while: ;; Query time: 1077 msec
The subsequent results come back much quicker: ;; Query time: 8 msec
Which is, kind of, what I'd expect. Oddly though, on one the boxes,
here, it never returns an answer quicker than 60 odd milliseconds. At
one stage, I noticed that it was quicker to query another box than use
the DNS server on itself.
This is the slower box, today:
dig google.com.au (querying itself)
;; Query time: 420 msec (first query)
;; Query time: 66 msec (subsequent query)
dig google.com.au @192.168.1.4 (querying a different PC)
;; Query time: 862 msec (first query)
;; Query time: 63 msec (subsequent query)
--
(Currently running FC4, in case that's important to the thread)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
7:44 a.m.
Tim wrote:
If I do something like "dig google.com", the first results
come back
after a while: ;; Query time: 1077 msec
The subsequent results come back much quicker: ;; Query time: 8 msec
> The first time you do it you may see something like:
>
> Received 194 bytes from 127.0.0.1#53 in 1291 ms
>
> But if you do it again, and it is working, you should see something on
> the order of:
>
> Received 194 bytes from 127.0.0.1#53 in 1 ms
Is it not doing four look-ups; I
would think that takes longer?
First look-up:
;; ADDITIONAL SECTION:
ns1.google.com. 172521 IN A 216.239.32.10
ns2.google.com. 172521 IN A 216.239.34.10
ns3.google.com. 172521 IN A 216.239.36.10
ns4.google.com. 172521 IN A 216.239.38.10
;; Query time: 1817 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 22 08:21:19 2006
;; MSG SIZE rcvd: 212
Second look-up:
;; ADDITIONAL SECTION:
ns1.google.com. 172496 IN A 216.239.32.10
ns2.google.com. 172496 IN A 216.239.34.10
ns3.google.com. 172496 IN A 216.239.36.10
ns4.google.com. 172496 IN A 216.239.38.10
;; Query time: 58 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 22 08:21:44 2006
;; MSG SIZE rcvd: 212
However, I never see single digit delays!
BobG
7:58 a.m.
Bob Goodwin wrote:
;; Query time: 58 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 22 08:21:44 2006
;; MSG SIZE rcvd: 212
However, I never see single digit delays!
This isn't going to help much, except
as another data point, but I tried
'dig google.com' just out of curiosity. The first response took 66
msec; here's the second:
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 22 08:52:20 2006
;; MSG SIZE rcvd: 212
My machine is nothing special (Athlon 1<>2 GHz).
--
John Miller
8:09 a.m.
John Miller wrote:
Bob Goodwin wrote:
> ;; Query time: 58 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Tue Aug 22 08:21:44 2006
> ;; MSG SIZE rcvd: 212
>
> However, I never see single digit delays!
>
This isn't going to help much, except as another data point, but I tried
'dig google.com' just out of curiosity. The first response took 66
msec; here's the second:
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 22 08:52:20 2006
;; MSG SIZE rcvd: 212
My machine is nothing special (Athlon 1<>2 GHz).
*Yes, I considered that it might be this ancient box, but it can ping
itself in less than 100µs!
I intend to try it on one of the faster computers I have but this is
my primary box. An old Pentium III 450 mHz w/~400 megs of RAM. And
this is the one I am most interested in, everything I do seems to be
done here. So maybe single digit times are out of the question?
BobG*
8:23 a.m.
On Tue, 2006-08-22 at 09:09 -0400, Bob Goodwin wrote:
I intend to try it on one of the faster computers I have but this is
my primary box. An old Pentium III 450 mHz w/~400 megs of RAM. And
this is the one I am most interested in, everything I do seems to be
done here. So maybe single digit times are out of the question?
One more thing to check, Bob : are you running IPv6? Not sure if it can
slow down name resolution, but it sure used to slow down web browsing.
P/S: everytime I say/write Bob, I can't help but think of that character
in "the Incredibles". My nieces watch that show over and over and
over ...
--
Pascal Chong
email: chongym(a)cymulacrum.net
web: http://cymulacrum.net
pgp: http://cymulacrum.net/pgp/cymulacrum.asc
"La science ne connaît pas de frontière parce que la connaissance
appartient à l’humanité. et que c’est la flamme qui illumine le monde."
-- Louis Pasteur
8:40 a.m.
On Tue, 2006-08-22 at 08:09, Bob Goodwin wrote:
John Miller wrote:
> Bob Goodwin wrote:
>
>> ;; Query time: 58 msec
>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>> ;; WHEN: Tue Aug 22 08:21:44 2006
>> ;; MSG SIZE rcvd: 212
>>
>> However, I never see single digit delays!
>>
> This isn't going to help much, except as another data point, but I tried
> 'dig google.com' just out of curiosity. The first response took 66
> msec; here's the second:
>
> ;; Query time: 2 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Tue Aug 22 08:52:20 2006
> ;; MSG SIZE rcvd: 212
>
> My machine is nothing special (Athlon 1<>2 GHz).
>
*Yes, I considered that it might be this ancient box, but it can ping
itself in less than 100µs!
I intend to try it on one of the faster computers I have but this is
my primary box. An old Pentium III 450 mHz w/~400 megs of RAM. And
this is the one I am most interested in, everything I do seems to be
done here. So maybe single digit times are out of the question?
I get 3 msec on a dual PII 450 on the 2nd query for
www.google.com:
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(localhost)
;; WHEN: Tue Aug 22 08:37:06 2006
;; MSG SIZE rcvd: 180
--
Les Mikesell
lesmikesell(a)gmail.com
9:24 a.m.
*Les Mikesell wrote:*
*On Tue, 2006-08-22 at 08:09, Bob Goodwin wrote:
*
> *John Miller wrote:
> *
>> *Bob Goodwin wrote:
>>
>> *
>>> *;; Query time: 58 msec
>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>> ;; WHEN: Tue Aug 22 08:21:44 2006
>>> ;; MSG SIZE rcvd: 212
>>>
>>> However, I never see single digit delays!
>>>
>>> *
>> *This isn't going to help much, except as another data point, but I tried
>> 'dig google.com' just out of curiosity. The first response took 66
>> msec; here's the second:
>>
>> ;; Query time: 2 msec
>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>> ;; WHEN: Tue Aug 22 08:52:20 2006
>> ;; MSG SIZE rcvd: 212
>>
>> My machine is nothing special (Athlon 1<>2 GHz).
>>
>> *
> **Yes, I considered that it might be this ancient box, but it can ping
> itself in less than 100µs!
>
> I intend to try it on one of the faster computers I have but this is
> my primary box. An old Pentium III 450 mHz w/~400 megs of RAM. And
> this is the one I am most interested in, everything I do seems to be
> done here. So maybe single digit times are out of the question?
> *
*
I get 3 msec on a dual PII 450 on the 2nd query for
www.google.com:
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(localhost)
;; WHEN: Tue Aug 22 08:37:06 2006
;; MSG SIZE rcvd: 180
*
*I wonder if my system may be introducing unanticipated [by me] delays?
I am assuming that the DNS process is internal to my computer once an
address has been cached however I have an ethernet switch, a wireless
bridge, and a wireless router that may be sneaking into the picture by
some means not obvious to me?
I have a system diagram at
http://users.wildblue.net/bobgoodwin/system.png.
The computer I am using is labeled box1.
BobG*
2:31 p.m.
Around 03:24pm on Tuesday, August 22, 2006 (UK time), Bob Goodwin scrawled:
I have a system diagram at
http://users.wildblue.net/bobgoodwin/system.png.
The computer I am using is labeled box1.
Bob, have you tried doing a host -v command, and then disconnecting the
Internet connection before repeating it. That should show conclusively
if the local name server is caching but slow, or not working at all.
Cheers
Steve
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting a bad thing?
20:26:56 up 3 days, 21:52, 1 user, load average: 0.33, 0.09, 0.02
2:52 p.m.
Steve Searle wrote:
Around 03:24pm on Tuesday, August 22, 2006 (UK time), Bob Goodwin
scrawled:
> I have a system diagram at
> http://users.wildblue.net/bobgoodwin/system.png.
> The computer I am using is labeled box1.
>
Bob, have you tried doing a host -v command, and then disconnecting the
Internet connection before repeating it. That should show conclusively
if the local name server is caching but slow, or not working at all.
Cheers
Steve
*Yes it works with the cat5 ethernet cable pulled from the
wireless bridge that is my internet source:
host -a google.com
Received 156 bytes from 127.0.0.1#53 in 115 ms
I'm satisfied that it works, the time is greatly reduced,
it's just that others report faster operation!
BobG
*
11:45 a.m.
On Tue, 2006-08-22 at 10:24 -0400, Bob Goodwin wrote:
I wonder if my system may be introducing unanticipated [by me]
delays?
I am assuming that the DNS process is internal to my computer once an
address has been cached however I have an ethernet switch, a wireless
bridge, and a wireless router that may be sneaking into the picture by
some means not obvious to me?
I have a system diagram at
http://users.wildblue.net/bobgoodwin/system.png.
The computer I am using is labeled box1.
If you were doing queries across the wireless link to another box, I
would have said it's a fair bet. But doing queries on the localhost
shouldn't involve the rest of the network.
It looks like you might have a similar issue to what I had (that one of
the PCs is slower to use its own DNS server than another was). You
could try running the caching nameserver on several boxes, comparing the
results. Today, the fastest internal response I can get is 33 mS doing
a lookup up on localhost.localdomain at the DNS server localhost
address. i.e. dig localhost.localdomain @ 127.0.0.1 It varies between
33 and 60+ mS to return results.
--
(Currently running FC4, occasionally trying FC5.)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
12:39 p.m.
*Tim wrote:*
*would have said it's a fair bet. But doing queries on the
localhost
shouldn't involve the rest of the network.
It looks like you might have a similar issue to what I had (that one of
the PCs is slower to use its own DNS server than another was). You
could try running the caching nameserver on several boxes, comparing the
results. Today, the fastest internal response I can get is 33 mS doing
a lookup up on localhost.localdomain at the DNS server localhost
address. i.e. dig localhost.localdomain @ 127.0.0.1 It varies between
33 and 60+ mS to return results.
*
*If you were doing queries across the wireless link to another box, I
*
*
I have observed instances where the initial response time was near 1000 ms,
the second in the tens of ms and then subsequent checks would be above
100 ms?
Initially for host -a google.com:
Received 220 bytes from 127.0.0.1#53 in 1047 ms
Then a few seconds later:
Received 220 bytes from 127.0.0.1#53 in 38 ms
Now some hours later:
Received 156 bytes from 127.0.0.1#53 in 467 ms
Then using dig <dig google.com>
;; Query time: 168 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Aug 23 13:15:23 2006
;; MSG SIZE rcvd: 148
Repeated several times, always 164-168 ms.
Then here's one I have not visited today, an address Joanne provided the
other day.
dig nlzero.com
; <<>> DiG 9.3.2 <<>> nlzero.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3375
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;nlzero.com. IN A
;; ANSWER SECTION:
nlzero.com. 38400 IN A 209.166.88.53
;; AUTHORITY SECTION:
nlzero.com. 38400 IN NS ns1.domainvanhorn.com.
nlzero.com. 38400 IN NS ns2.domainvanhorn.com.
;; Query time: 3180 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Aug 23 13:21:48 2006
;; MSG SIZE rcvd: 94
dig nlzero.com
; <<>> DiG 9.3.2 <<>> nlzero.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48766
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;nlzero.com. IN A
;; ANSWER SECTION:
nlzero.com. 38383 IN A 209.166.88.53
;; AUTHORITY SECTION:
nlzero.com. 38383 IN NS ns2.domainvanhorn.com.
nlzero.com. 38383 IN NS ns1.domainvanhorn.com.
;; Query time: 244 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Aug 23 13:22:05 2006
;; MSG SIZE rcvd: 94
Then the same address using <host -a nlzero.com>
Received 122 bytes from 127.0.0.1#53 in 382 ms
The correlation between the two methods is not perfect?
I need to try the same things with another FC5 computer. But that requires
sometime to update again and install the caching-nameserver on it.
I did try pinging google with the Dell XP box yesterday.
The average of three pings was 775 ms but I don't know how to check the dns
response time with Windows? I did try pinging itself and all it gave me
was
less than 1ms to 127.0.0.1. Unlike FC5, it does not read out in the
µsec range.
BobG*
7:45 p.m.
On Wed, 2006-08-23 at 13:39 -0400, Bob Goodwin wrote:
I have observed instances where the initial response time was near
1000 ms,
the second in the tens of ms and then subsequent checks would be above
100 ms?
Same here.
Initially for host -a google.com:
Received 220 bytes from 127.0.0.1#53 in 1047 ms
Then a few seconds later:
Received 220 bytes from 127.0.0.1#53 in 38 ms
Now some hours later:
Received 156 bytes from 127.0.0.1#53 in 467 ms
Then using dig <dig google.com>
;; Query time: 168 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Aug 23 13:15:23 2006
;; MSG SIZE rcvd: 148
Repeated several times, always 164-168 ms.
I've noticed similar sort of things, myself. Just to be clear, it
doesn't matter what made the first query (host, dig, etc.). Once
something's looked up an address in your nameserver (e.g. web browser)
it can cache the results for the next thing (e.g. dig).
Then here's one I have not visited today, an address Joanne
provided the
other day.
dig nlzero.com
;; Query time: 3180 msec
dig nlzero.com
;; Query time: 244 msec
Then the same address using <host -a nlzero.com>
Received 122 bytes from 127.0.0.1#53 in 382 ms
The correlation between the two methods is not perfect?
Various factors are going to mean there's variable delays between
results (other things your PC is doing at the time, it's not a real-time
system, and whether a thing works through several other things, in
sequence, to get its results).
Query goes out (takes time), DNS checks for local data (takes time), DNS
server may fetch remote data (takes time), DNS server responds (takes
time), querying program acts on data (takes time). Quite probably the
more data returned with a record (i.e. several A records) the longer the
time reported by dig, though I would expect other things to be a more
significant variance to the time. And certainly, if it has to go
through several remote DNS servers before finding the responses (queries
root server to find authoritative server for a domain, which then turns
out to not be authoritative and refers onto another server...), that'll
take longer.
I did try pinging google with the Dell XP box yesterday.
The average of three pings was 775 ms
That's a different thing, altogether. You're measuring the time it
takes for ICMP (usually) traffic to get between their system and yours,
DNS data may or may not be obtained from the same systems. And DNS
traffic is usually UDP (a different scheme, probably with different
timing issues - depending on all the software systems involved from one
end to another).
e.g. Here I have several PCs, a few of them have webservers, a few of
them have DNS servers. But it's most likely that if you pinged one of
them, some other PC's DNS server would have provided you with IP address
to ping.
but I don't know how to check the dns response time with Windows?
There are dig type of tools for Windows, but I don't know a name to give
you a search parameter. A quick search of "dig for windows" produces
some results, but I know nothing of them to give any recommendation
(other than to be cautious).
However, remember that, I think, you're mostly looking up the response
time of the queried DNS server, not the response time of the machine
asking the question. If you're not running a DNS server on that Windows
box, you're probably not going to see the sort of results that you're
thinking about.
--
(Currently running FC4, occasionally trying FC5.)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
8:45 p.m.
*Tim wrote:*
*On Wed, 2006-08-23 at 13:39 -0400, Bob Goodwin wrote:
*
> *I have observed instances where the initial response time was near 1000 ms,
> the second in the tens of ms and then subsequent checks would be above
> 100 ms?
> *
*
Same here.
*
> *Initially for host -a google.com:
> Received 220 bytes from 127.0.0.1#53 in 1047 ms
>
> Then a few seconds later:
> Received 220 bytes from 127.0.0.1#53 in 38 ms
>
> Now some hours later:
> Received 156 bytes from 127.0.0.1#53 in 467 ms
>
> Then using dig <dig google.com>
> ;; Query time: 168 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Wed Aug 23 13:15:23 2006
> ;; MSG SIZE rcvd: 148
>
> Repeated several times, always 164-168 ms.
> *
*
I've noticed similar sort of things, myself. Just to be clear, it
doesn't matter what made the first query (host, dig, etc.). Once
something's looked up an address in your nameserver (e.g. web browser)
it can cache the results for the next thing (e.g. dig).
*
*Yes I understand that.
*
*
*
> *Then here's one I have not visited today, an address Joanne provided the
> other day.
>
> dig nlzero.com
> ;; Query time: 3180 msec
>
> dig nlzero.com
> ;; Query time: 244 msec
>
> Then the same address using <host -a nlzero.com>
>
> Received 122 bytes from 127.0.0.1#53 in 382 ms
>
> The correlation between the two methods is not perfect?
> *
*
Various factors are going to mean there's variable delays between
results (other things your PC is doing at the time, it's not a real-time
system, and whether a thing works through several other things, in
sequence, to get its results).
Query goes out (takes time), DNS checks for local data (takes time), DNS
server may fetch remote data (takes time), DNS server responds (takes
time), querying program acts on data (takes time). Quite probably the
more data returned with a record (i.e. several A records) the longer the
time reported by dig, though I would expect other things to be a more
significant variance to the time. And certainly, if it has to go
through several remote DNS servers before finding the responses (queries
root server to find authoritative server for a domain, which then turns
out to not be authoritative and refers onto another server...), that'll
take longer.
*
*Yes, but I was getting opinions that the response time should be in the
single
digit range and that got me off looking for improvement. I was quite
happy with
the results I got initially after installing "caching-namserver." And I
guess
I still am, it's doing what it's supposed to do ...*
> *I did try pinging google with the Dell XP box yesterday.
> The average of three pings was 775 ms
> *
*
That's a different thing, altogether. You're measuring the time it
takes for ICMP (usually) traffic to get between their system and yours,
DNS data may or may not be obtained from the same systems. And DNS
traffic is usually UDP (a different scheme, probably with different
timing issues - depending on all the software systems involved from one
end to another).
e.g. Here I have several PCs, a few of them have webservers, a few of
them have DNS servers. But it's most likely that if you pinged one of
them, some other PC's DNS server would have provided you with IP address
to ping.
*
> *but I don't know how to check the dns response time with Windows?
> *
*
There are dig type of tools for Windows, but I don't know a name to give
you a search parameter. A quick search of "dig for windows" produces
some results, but I know nothing of them to give any recommendation
(other than to be cautious).
However, remember that, I think, you're mostly looking up the response
time of the queried DNS server, not the response time of the machine
asking the question. If you're not running a DNS server on that Windows
box, you're probably not going to see the sort of results that you're
thinking about.
*
*It appeared that my dns response times were poor and I was beginning to
think
it was just this old computer. I knew it would ping 127.0.0.1 in under
100 µs
so I tried the same thing on the new Dell XP box and found that Windows
ping
won't display anything smaller than 1.0ms. So there was no common
ground there,
that's all I was doing, it seemed there might be an observable
difference between
a 450 mHz and a 2.8 gHz machine. There probably is but I couldn't make any
meaningful measurements on the Windows computer. I really should put a
Linux
partition in it but it means buying an SATA drive for a computer that I
don't
use often and it already has more space than I am likely to need.
*
*Many thanks for the help.
BobG
*
2:59 a.m.
On Wed, 2006-08-23 at 21:45 -0400, Bob Goodwin wrote:
I was getting opinions that the response time should be in the
single digit range and that got me off looking for improvement. I was
quite happy with the results I got initially after installing
"caching-namserver." And I guess I still am, it's doing what it's
supposed to do ...
I'd be keen to know how they've managed it. Trying out DNS servers on
different PCs around here (266 MHz PII, 450 MHz PIII, 500 MHz Celeron,
566 MHz Celeron, 1.1 GHz Duron), they all get the same results, pretty
much (as I posted before).
it seemed there might be an observable difference between a 450 mHz
and a 2.8 gHz machine. There probably is but I couldn't make any
meaningful measurements on the Windows computer. I really should put
a Linux partition in it but it means buying an SATA drive for a
computer that I don't use often
For testing purposes, you could try just swapping drives between boxes,
and using Linux that was installed on another PC. It often works
without too many dramas. That's presuming that you don't mention SATA
because it's the only way to attach a HDD to that box.
Just going by raw clock speed is hard to gauge one PC against another.
As soon as a peripheral comes into the equation, that'll slow everything
down, the top CPU speed can only be achieved within its internal cache.
Considering the task at hand, I doubt it'd be working in that way.
--
(Currently running FC4, in case that's important to the thread)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
11:45 a.m.
On Tue, 2006-08-22 at 08:44 -0400, Bob Goodwin wrote:
Is it not doing four look-ups; I would think that takes longer?
First look-up:
;; ADDITIONAL SECTION:
ns1.google.com. 172521 IN A 216.239.32.10
ns2.google.com. 172521 IN A 216.239.34.10
ns3.google.com. 172521 IN A 216.239.36.10
ns4.google.com. 172521 IN A 216.239.38.10
I'll go out on a limb and say that you've looked up one thing, and got
back one answer, with that answer being more than just a single answer.
Having said that, I can do dig queries on other demains, that don't
return numerous records, and they're not really any faster.
--
(Currently running FC4, occasionally trying FC5.)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
11:32 p.m.
On Mon, 2006-08-21 at 16:20 -0400, Bob Goodwin wrote:
Is there a file of cached addresses that I can look at and see that
they are actually being cached?
The cache is kept in memory, but you dump it's contents to file with
"rndc dumpdb". The file will be named named_dump.db, and
lives /var/named/var/named.
Cheers
Steffen.
3:26 a.m.
Steffen Kluge wrote:
On Mon, 2006-08-21 at 16:20 -0400, Bob Goodwin wrote:
> Is there a file of cached addresses that I can look at and see that
> they are actually being cached?
>
The cache is kept in memory, but you dump it's contents to file with
"rndc dumpdb". The file will be named named_dump.db, and
lives /var/named/var/named.
Cheers
Steffen.
Interesting, an ascii file, it certainly contains a lot more addresses
than I imagined it would! How to interpret the data it provides is the
question?
I guess all those addresses are available via "caching-nameserver?"
BobG
11:45 a.m.
Steffen Kluge:
> The cache is kept in memory, but you dump it's contents to
file with
> "rndc dumpdb". The file will be named named_dump.db, and
> lives /var/named/var/named.
Here, it ended up at: /var/named/chroot/var/named/data/cache_dump.db
Bob Goodwin:
Interesting, an ascii file, it certainly contains a lot more
addresses
than I imagined it would!
Every website that you visited will have left some data in the cache (up
until it's expiry time), likewise for any external information that they
referenced (off-site adverts, etc.), same again for mail you've
received, even more so if you have anti-spam software that checks upon
the headers and content of mail.
How to interpret the data it provides is the question?
Well, you can see DNS addresses and associated IP addresses, the type of
record (NS - name server, A - a record, etc.). I'm guessing the number
left of the type would be a time to live (expires/expunged afterwards),
as it tallies with some TTL figures for same domain names later on.
Other stuff would require more research to work out.
I guess all those addresses are available via
"caching-nameserver?"
That depends on what you mean. If you meant that installing the
caching-nameserver included those details, no. If you meant that your
nameserver, now, had those details in memory, yes (that's where they cam
from).
--
(Currently running FC4, occasionally trying FC5.)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
11:56 a.m.
Doesn't named have a signal you can send it so that it dumps all its
in-memory data?
-----Original Message-----
From: fedora-list-bounces(a)redhat.com [mailto:fedora-list-bounces@redhat.com]
On Behalf Of Bob Goodwin
Sent: Monday, August 21, 2006 2:20 PM
To: For users of Fedora Core releases
Subject: caching-namserver
I've done "yum install caching-nameserver" and with a few crude tests it
appears that it might be working.
Is there a file of cached addresses that I can look at and see that they are
actually being cached?
Bob Goodwin
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
5:36 p.m.
Heads-up for those using caching-nameserver. It's been replaced by
bind-config. A bit of a shock when yum update removes
caching-nameserver.
2:42 a.m.
On Thu, 2006-08-24 at 15:36 -0700, Geoffrey Leach wrote:
Heads-up for those using caching-nameserver. It's been replaced
by
bind-config. A bit of a shock when yum update removes
caching-nameserver.
You may find it gets changed back again soon:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197493
Paul.
2:43 a.m.
On Thu, 2006-08-24 at 10:56 -0600, Michael P. Brininstool wrote:
Doesn't named have a signal you can send it so that it dumps all
its
in-memory data?
That used to be the case but "rndc dumpdb" is now preferred and the
manpage says that the result of sending any signal other than SIGHUP to
named is undefined.
Paul.
6498
days inactive
6502
days old
38 comments
14 participants
participants (14)
-
Bob Goodwin -
Cameron Simpson -
Chong Yu Meng -
Ed Greshko -
Geoffrey Leach -
jdow -
John Miller -
Les Mikesell -
Michael P. Brininstool -
Paul Howarth -
Steffen Kluge -
Steve Searle -
Tim -
Tom Horsley