Thanks to everyone for the many replies.
It appears it was dnscache. The fix for me was to set FORWARDONLY
option ON and set the ISP dns server addresses (for use in FORWARDONLY).
I hope this helps others. Thanks,
On Tue, 2008-08-26 at 12:21 +, Erich Titl wrote:
Hi Trev
Trev Peterson
Hi Trev
Trev Peterson wrote:
Hello,
I'm having a bit of a problem with dnscache. If anyone has run into
this problem and/or has a suggested solution it would be greatly
appreciated. I should note we are not interested in changing to another
package (we use tinydns extensively and are
Hi
on 26.8.2008 04:17 Trev Peterson wrote:
I'm having a bit of a problem with dnscache. If anyone has run into
this problem and/or has a suggested solution it would be greatly
appreciated.
Firewall Version: Leaf Bering 2.4.32
Package Name: dnscache.lrp
Description: Some hosts are not
I encountered the same problem about a year+ ago but for different
websites, though I'm only running Dachstein. I got tired of dealing
with it and put my ISP's dns as the dhcpd distribution.
Trev Peterson wrote:
Hello,
I'm having a bit of a problem with dnscache. If anyone has run into
Hello,
I'm having a bit of a problem with dnscache. If anyone has run into
this problem and/or has a suggested solution it would be greatly
appreciated. I should note we are not interested in changing to another
package (we use tinydns extensively and are otherwise happy with
dnscache). Below
Hello LEAF friends,
can some one tell me why my dnscache don't work if I run my Bering on a
computer without a Networkcard?
I use ISDN for connect to the internet
thanks in advance
sayangoin
_
Holen Sie sich den neuen
to
dnsmasq and have not gotten any more complaints.
Hope this helps,
- Original Message -
From: Nathan Angelacos [EMAIL PROTECTED]
To: ALParada [EMAIL PROTECTED]
Sent: Tuesday, November 30, 2004 10:07 AM
Subject: Re: [leaf-user] dnscache inconsistent
Al,
You mentioned you were having
Thanks for the info. Installed and configured dnsmasq and seems to be
working well. I did had some problems getting it to respond on only one
interface but it looks like it worked itself out.
Thanks
ALParada wrote:
Hello,
I'm having problems with what I think can only be dnscache. I am
Hello,
I'm having problems with what I think can only be dnscache. I am using
uClibc 2.1.0 with Shorewall and Openvpn. Dnscache is setup to forward to my
internal DNS. Openvpn is setup to use dnscache as the primary dns on the
config file. Somtimes it simply doesn't resolve. I have tried it from
Hello everyone.
Can anyone tell me how I can configure dnscache to send its requests using
the internal interface. For some reason it has chosen the external
interface to send out the requests, but that interface won't work with my
IPSEC connection. I am not sure why it is picking that
[EMAIL PROTECTED] wrote:
Hello everyone.
Can anyone tell me how I can configure dnscache to send its requests
using the internal interface. For some reason it has chosen the
external interface to send out the requests, but that interface won't
work with my
IPSEC connection. I am not sure
but the rest
of the DNS servers are not that forgiving. I am masqing the internal IP
so who knows.
Many thanks.
- Original Message -
From: Ray Olszewski [EMAIL PROTECTED]
To: ALParada [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, November 07, 2003 8:31 PM
Subject: Re: [leaf-user] dnscache
: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of ALParada
Sent: Thursday, November 06, 2003 8:36 PM
To: [EMAIL PROTECTED]
Subject: [leaf-user] dnscache
Hello,
I am running Bering with dnscache. Either I don't understand how a
caching server works, or I missed something in the configuration
Coffman Jr - Info From Data Corporation
[EMAIL PROTECTED]
To: ALParada [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, November 07, 2003 8:28 AM
Subject: RE: [leaf-user] dnscache
Nothing in your config sounds incorrect, but here is what I did:
1. change LRP box internal IP
2. Changed
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of ALParada
Sent: Thursday, November 06, 2003 8:36 PM
To: [EMAIL PROTECTED]
Subject: [leaf-user] dnscache
Hello,
I am running Bering with dnscache. Either I don't understand how a
caching server works, or I missed
See below.
- Original Message -
From: Ray Olszewski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; ALParada
[EMAIL PROTECTED]
Sent: Friday, November 07, 2003 1:38 PM
Subject: Re: [leaf-user] dnscache
Sorry to be coming into this one late.
At 12:19 PM 11/7/2003 -0500, ALParada wrote:
When
Offnhand, I do not see a cause for this problem, now that I understand it a
bit better. I'll give it some additional thought, though. In the meantime,
could I ask you to clarify one detail?
If you tell the test host to use 192.168.63.11 as its DNS server, can
nslookup then do a reverse lookup
Subject: Re: [leaf-user] dnscache
Offnhand, I do not see a cause for this problem, now that I understand
it a
bit better. I'll give it some additional thought, though. In the
meantime,
could I ask you to clarify one detail?
If you tell the test host to use 192.168.63.11 as its DNS server, can
At 06:52 PM 11/7/2003 -0500, ALParada wrote:
There is no record for the LRP in the primary DNS. Now that I added one
and the associated PTR it works. However, why did it work with the ISP
DNS servers?
Beats me. Ask your ISP. Me, I can only *guess* that the ISP did something
to its DNS servers
Hello,
I am running Bering with dnscache. Either I don't understand how a
caching server works, or I missed something in the configuration.
Dnscache is running because I verified it with ps aux. I however can't
resolve any names. I changed the internal ip address under option1. Set
option 4 to
On Monday 16 December 2002 09:10 pm, you wrote:
First, thanks to all who contributed to the development of LEAF. The
various packages just keep getting better.
Now to my question. Recently, I moved from Dachstein to Bering. After doing
this I noticed that the images at www.weather.com do not
Thank you, Charles, et al. for your continued participation . . .
Charles Steinkuehler wrote:
root@bluetrout:/root
# ip addr
. . .
7: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:a0:c9:9e:57:70 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd
OK, it gets more interesting ;
[1] As you know, here is a summary of the dcd:
root@bluetrout:/etc
# ip addr
. . .
7: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:a0:c9:9e:57:70 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd
Sorry to jump into this late.
You say:
[4] I need help understanding what is going on in lines like this:
64.4.197.69 64.4.197.65: icmp: 64.4.197.69 udp port 32868
unreachable [tos 0xc0]
I am confused with both icmp and udp specified on same line ???
I believe what this reports
Thank you, for your participation . . .
Ray Olszewski wrote:
Sorry to jump into this late.
You say:
[4] I need help understanding what is going on in lines like this:
64.4.197.69 64.4.197.65: icmp: 64.4.197.69 udp port 32868
unreachable [tos 0xc0]
I am confused
Comments inline.
Yes, I, too, have been confused by some of this. We have several
successful proxy-arp dmz's; so, when we built this one, we started by
cloning those other config's and changing addresses, c. and it
appeared
to be working as expected.
# ip route
64.4.222.158 dev ipsec0
Charles Steinkuehler wrote:
Comments inline.
Yes, I, too, have been confused by some of this. We have several
successful proxy-arp dmz's; so, when we built this one, we started by
cloning those other config's and changing addresses, c. and it
appeared
to be working as expected.
OK, it gets more interesting ;
Indeed! Lots of in-line comments, or just skip to the executive
summary at the end :-)
config info snipped
[3] As it turns out, some name resolution stuff works (e.g.,
nslookup);
but, other stuff does *NOT* work (e.g., host, dig, ping). tcpdump
# ping -c 3 64.4.197.127
PING 64.4.197.127 (64.4.197.127): 56 data bytes
64 bytes from 64.4.197.65: icmp_seq=0 ttl=255 time=0.3 ms
64 bytes from 64.4.197.69: icmp_seq=0 ttl=255 time=0.7 ms (DUP!)
64 bytes from 64.4.197.68: icmp_seq=0 ttl=128 time=0.9 ms (DUP!)
64 bytes from
17: wan1: POINTOPOINT,NOARP,UP mtu 1500 qdisc pfifo_fast qlen
100
link/ppp
inet 64.4.222.157 peer 64.4.222.158/32 scope global wan1
inet 64.4.197.99/32 scope global wan1
inet 64.4.197.100/32 scope global wan1
inet 64.4.197.101/32 scope global wan1
Please
Charles Steinkuehler wrote:
snip /
So...it looks like either dnscache is mis-configured (bad send-from IP),
or more likely, that your masquerade rule connecting the internal
network with the DMZ is mangling (masquerading) the return traffic.
Why am I thinking about correcting the error and
Charles Steinkuehler wrote:
17: wan1: POINTOPOINT,NOARP,UP mtu 1500 qdisc pfifo_fast qlen
100
link/ppp
inet 64.4.222.157 peer 64.4.222.158/32 scope global wan1
inet 64.4.197.99/32 scope global wan1
inet 64.4.197.100/32 scope global wan1
inet
I'd suggest configuring dnscache to listen on the 64.4.197.65 IP for
your DMZ hosts. You can setup a second dnscache to listen on
192.168.1.254 for your internal network. The two tinydns instances
can
be run on loopback interfaces (there's more than just 127.0.0.1
available,
Charles Steinkuehler wrote:
I think Charles hit the nail on the head when he said:
cs You have to point the DMZ systems at the IP of dnscache, *NOT*
tinydns,
cs as tinydns does not do recursive queries. I think that's the
root of
cs your problem. Switch the IP in your
root@bluetrout:/root
# ip addr
snip lo, ipsec, brg
7: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:a0:c9:9e:57:70 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd 192.168.1.255 scope global eth0
8: eth1: BROADCAST,MULTICAST,UP mtu 1500 qdisc
On Fri, 11 Oct 2002 09:26:54 EST mds wrote:
I'm beginning to believe that this maybe the problem. Remember, I
witness the queries in dnscache and witness the answers sent; but,
nothing gets back to dmz.
Are you sure? Snippets from the ipchains logs you posted
[c] 59:52 output - eth1
Brad Fritz wrote:
On Fri, 11 Oct 2002 09:26:54 EST mds wrote:
I still think using two instances of dnscache in front of two
instances of tinydns would be a cleaner solution if you need
separate DMZ and LAN namespaces. Otherwise you might end up
in routing kludge hell getting this to work.
I think Charles hit the nail on the head when he said:
cs You have to point the DMZ systems at the IP of dnscache, *NOT*
tinydns,
cs as tinydns does not do recursive queries. I think that's the
root of
cs your problem. Switch the IP in your non-working DMZ resolv.conf
to the
cs IP
Michael D. Schleif wrote:
How about you tell
me what ip tinydns-public is bound to?
==cat /etc/tinydns-public/env/IP
How about what ip is dnscache bound to?
==cat /etc/dnscache/env/IP
# cat /etc/tinydns-public/env/IP
64.4.197.65
# cat /etc/dnscache/env/IP
0.0.0.0
I've not
Michael D. Schleif wrote:
Matthew Schalit wrote:
snip /
Please tell me you've added ipchains -l logging to every packet
1) inbound on dmz nic
2) outbound from dmz nic
3) inbound on internal nic
4) outbound on internal nic
5) forwarded by any forward
Michael D. Schleif wrote:
Michael D. Schleif wrote:
does anybody have a proxy-arp dmz and also running tinydns dnscache?
Anybody have such setup that works?
I have three nics in Bering rc3
eth1 10.10.10.0/24 + tinydns private + dnscache
Michael D. Schleif wrote:
thank you, for your continued interest . . .
Matthew Schalit wrote:
Michael D. Schleif wrote:
Michael D. Schleif wrote:
does anybody have a proxy-arp dmz and also running tinydns dnscache?
Anybody have such setup that works?
I have three nics in Bering rc3
Matthew Schalit wrote:
Michael D. Schleif wrote:
thank you, for your continued interest . . .
Matthew Schalit wrote:
Michael D. Schleif wrote:
Michael D. Schleif wrote:
does anybody have a proxy-arp dmz and also running tinydns dnscache?
Anybody have such setup that
Michael D. Schleif wrote:
Matthew Schalit wrote:
snip /
Do you forward and masq from the dmz to internal or just forward?
Have you posted all the rules you're using for that?
this could be it:
http://www.helices.org/tmP/ipchains.bluetrout.txt
this page will update as i
Matthew Schalit wrote:
snip /
Please tell me you've added ipchains -l logging to every packet
1) inbound on dmz nic
2) outbound from dmz nic
3) inbound on internal nic
4) outbound on internal nic
5) forwarded by any forward rule
and
Michael D. Schleif wrote:
Matthew Schalit wrote:
snip /
Please tell me you've added ipchains -l logging to every packet
1) inbound on dmz nic
2) outbound from dmz nic
3) inbound on internal nic
4) outbound on internal nic
5)
On or before Wed, 09 Oct 2002 11:06:30 EST mds and Charles S wrote:
mds I cannot get dmz hosts to resolve addresses for remote internet
mds sites solely via tinydns-public and dnscache ; tinydns tries to
mds resolve the name and gives up, without so much as asking dnscache.
[other details
Brad Fritz wrote:
On or before Wed, 09 Oct 2002 11:06:30 EST mds and Charles S wrote:
mds I cannot get dmz hosts to resolve addresses for remote internet
mds sites solely via tinydns-public and dnscache ; tinydns tries to
mds resolve the name and gives up, without so much as asking
Erich Titl wrote:
At 07:57 09.10.2002, you wrote:
does anybody have a proxy-arp dmz and also running tinydns dnscache?
thought that I'd resolved this sometime ago; but, tonight, for life of
me, I cannot get dmz hosts to resolve addresses for remote internet
sites solely via
Michael D. Schleif wrote:
does anybody have a proxy-arp dmz and also running tinydns dnscache?
Anybody have such setup that works?
--
Best Regards,
mds
mds resource
888.250.3987
Dare to fix things before they break . . .
Our capacity for understanding is inversely proportional to how
On Wed, 2002-10-09 at 15:07, Michael D. Schleif wrote:
Michael D. Schleif wrote:
does anybody have a proxy-arp dmz and also running tinydns dnscache?
Anybody have such setup that works?
Yes, on Dachstein 1.0.2CD, BUT tinydns and dnscache only serve the
private network. I have a DNS
does anybody have a proxy-arp dmz and also running tinydns dnscache?
thought that I'd resolved this sometime ago; but, tonight, for life of
me, I cannot get dmz hosts to resolve addresses for remote internet
sites solely via tinydns-public and dnscache ; tinydns tries to
resolve the name and
Michael
At 07:57 09.10.2002, you wrote:
does anybody have a proxy-arp dmz and also running tinydns dnscache?
thought that I'd resolved this sometime ago; but, tonight, for life of
me, I cannot get dmz hosts to resolve addresses for remote internet
sites solely via tinydns-public and dnscache
On 2002.09.24_21:26:59_+, Sean wrote:
I'm using Dachstein. TinyDNS is on the CD. Guess I'll try to set it
up. Thanks for the pointers! Another question: Is this a GOOD IDEA?
It can be done, but should it be done?
Depends on what you and your users needs. On some sites I worked on,
H. D. Lee wrote:
On 2002.09.24_21:26:59_+, Sean wrote:
I'm using Dachstein. TinyDNS is on the CD. Guess I'll try to set it
up. Thanks for the pointers! Another question: Is this a GOOD IDEA?
It can be done, but should it be done?
Depends on what you and your users needs. On some
Is there any way to pre-load the dnscache with some
entries? Like telling it that *.doubleclick.* and
*.x10.* are 127.0.0.1?
TIA
Sean
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
On Tue, 24 Sep 2002 19:27:55 GMT Sean wrote:
Is there any way to pre-load the dnscache with some
entries? Like telling it that *.doubleclick.* and
*.x10.* are 127.0.0.1?
Yes, it's called tinydns. ;) In a nutshell, the setup for that
you describe on Bering rc3 is:
1.) Install
Is there any way to pre-load the dnscache with some
entries? Like telling it that *.doubleclick.* and
*.x10.* are 127.0.0.1?
Not exactly...you can, however, setup a DNS server for those domains
(see, for instance, tinydns), and configure dnscache to query the local
name-server for those
On 2002.09.24_19:27:55_+, [EMAIL PROTECTED] wrote:
Is there any way to pre-load the dnscache with some
entries? Like telling it that *.doubleclick.* and
*.x10.* are 127.0.0.1?
As Charles and Britz suggested, use tinydns and dnscache to achieve
that. Please also note that to run
Sent: Tuesday, September 24, 2002 8:27 PM
To: Leaf-User
Subject: Re: [leaf-user] DnsCache
On 2002.09.24_19:27:55_+, [EMAIL PROTECTED] wrote:
Is there any way to pre-load the dnscache with some
entries? Like telling it that *.doubleclick.* and
*.x10.* are 127.0.0.1?
As Charles and Britz
I have enabled dnscache on my Bering-rc3 floppy version. When the system comes, up I
get beau coup of the following message:
Unable to write to dnscache/supervise/status.new: Out of disk space.
I transferred the installation to a hard disk and still getting the messages. I am
even able to
Can I make syst_size much bigger since i have 64M ram?
Godfried Duodu
(713)802-5146
fax # (713}802-5140
Jacques Nilo [EMAIL PROTECTED] 7/25/02 1:24:33 PM
Le Jeudi 25 Juillet 2002 18:46, Godfried Duodu a écrit :
I have enabled dnscache on my Bering-rc3 floppy version. When the system
Le Jeudi 25 Juillet 2002 21:59, Godfried Duodu a écrit :
Can I make the syst_size much bigger siNCE i HAVE 64m RAM?
Sure but you need to leave room for /var/log and /tmp and you also need some
memory to run linux :-)
Go for 16M it should be more than enough
Jacques
Le Jeudi 25 Juillet 2002
Im running bering rc1 with dnscache. Installed per nilo site instructions, no
problems. But when i enter dnscache at prompt i get
dnscache: fatal: $IP not set. What could be causing this also cant see any logs
generated from dnscache to verify that it is even working.
Le Vendredi 17 Mai 2002 21:06, Jim Van Eeckhoutte a écrit :
Im running bering rc1 with dnscache. Installed per nilo site instructions,
no problems. But when i enter dnscache at prompt i get dnscache: fatal: $IP
not set. What could be causing this also cant see any logs generated
from
Hi,
I was reading dnscache documentation and I wanted it to resolve
internal addresses using our internal DNS server.
In http://cr.yp.to/djbdns/faq/cache.html it reads:
How do I tell my cache to consult internal DNS servers? Our network has internal
servers at IP addresses 10.1.2.5 and
Hi,
I have a question I hope someone can help me with. Here goes:
I'm running dachstein on a 1722K floppy, with dhclient.lrp,
dhcpd.lrp, daemontl.lrp, tinydns.lrp and dnscache.lrp. Currently
I'm in the testing phase, but I hope to use this setup in a
couple of situations soon.
Question:
Scott C. Best wrote:
Heyaz. So I'm using a fairly stock DS relase,
and I've a question about properly setting up dnscache
and my host entries in network.conf.
So, these host entries are visible from the DS system.
How can I keep my LAN machines from making PTR?
requests
Michael:
Heya. Each of the LAN machines gets a DHCP lease
from the DS box, with the DS box indicated as the DNS
server. Only the DS box has the /etc/hosts entries.
For example, in the /etc/hosts file it reads:
192.168.123.1 pc.private.network pc1
192.168.123.2
Scott C. Best wrote:
Heyaz. So I'm using a fairly stock DS relase,
and I've a question about properly setting up dnscache
and my host entries in network.conf.
Scott!
I hope all is well in the South Bay. Are you going to make it
up to SF for the Linux Embedded conference this week:
At 10:37 PM 3/9/02 +, Scott C. Best wrote:
Michael:
Heya. Each of the LAN machines gets a DHCP lease
from the DS box, with the DS box indicated as the DNS
server. Only the DS box has the /etc/hosts entries.
For example, in the /etc/hosts file it reads:
192.168.123.1
Normally, we've been setting up all systems with dhcp and assigning dns
servers thusly:
192.168.1.254 # firewall, w/dnscache
x.y.z.2 # ISP assigned dns server(s)
x.y.z.3 ...
I suppose, our theory is, if dnscache gets trashed, at least dns
Not sure if this makes any difference in your situation, but Win2k does
client-side DNS caching (and negative caching, I believe)
To disable for testing:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q245437
___
Leaf-user mailing list
Charles Steinkuehler wrote:
Under Package configuration - dnscache there is a menu entry called LRP
box
internal IP (default: 192.168.1.254).
But if I open menu entry 1) there is not 192.168.1.254, it's
0.0.0.0.
What's correct now? Is the menu entry description wrong or the
Sandro Minola wrote:
hi
Under Package configuration - dnscache there is a menu entry called LRP box
internal IP (default: 192.168.1.254).
But if I open menu entry 1) there is not 192.168.1.254, it's 0.0.0.0.
What's correct now? Is the menu entry description wrong or the value itself?
One
are bind and tinydns. Most people recommend tinydns
if I'm not mistaken - due to security vulnerablilties and performance
issues with bind.
Simon
From: Steven Cayford [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Leaf-user] dnscache and nslookup
Date: Thu, 18
Hi. I'm enjoying setting up a 486 with Oxygen as a router for my home
network. I wanted to set up dnscache on the machine since my isp's name
servers seem kind of slow sometimes and that seems to work pretty well. For
the internal side I just listed my machines (only two of them so far, more
Somebody on the list suggested that I should use DNS Cache on my LRP.
Because to get my Linux box to connect to the outside world, I must
edit my resolv.confg file and add two nameservers that are provided from
my ISP.
Ok I found a copy of dnscache.lrp. How do I install it back into the
Robert Chambers wrote:
Somebody on the list suggested that I should use DNS Cache on my LRP.
Because to get my Linux box to connect to the outside world, I must
edit my resolv.confg file and add two nameservers that are provided from
my ISP.
Ok I found a copy of dnscache.lrp. How do I
79 matches
Mail list logo
