[CentOS] Re: OT: anything in CentOS 5.2 that uses opendns.com when browsing web?

[William L. Maltby]

On Fri, 2008-07-11 at 17:12 -0500, Lanny Marcus wrote:
> On 7/11/08, Lanny Marcus <lmmailinglists at gmail.com> wrote:
> > On 7/11/08, William L. Maltby <CentOS4Bill at triad.rr.com> wrote:
> > <snip>
> >>> I cannot dig +trace from my Desktop, as me or as root and I also
> >>> cannot dig +trace from the ipcop box as of this time.
> >>
> >> Must be either firewall on your desktop or IPCop has some blocked
> >> resources. Try to dig something from your desktop that is on your local
> >> lan. Your IPCop box(es) should make good targets *if* nothing blocks the
> >> needed responses.
> >>
> >> If you can get dig +trace to any other box on the lan, with trace
> >> information shown, that means your desktop should be fine.
> 
> I disabled the Firewall in my Desktop. I can dig to my daughters box,
> but I cannot dig +trace to it. Same results as with the Firewall in my
> Desktop enabled.

After reading your other post, I see why. With no DNS server (caching or
otherwise), your routing is strictly via routing tables and /etc/hosts.
So no trace is possible because no DNS server is involved. When you have
some kind of DNS going on, your *first* attempt to do a look-up
(presuming /etc/hosts on you machine does not contain the host - address
resolution is then required to get the IP address) may give you
something.

> I have SELinux running in Permissive Mode in my box and am not
> receiving Warnings, so I do not believe that is causing the problem. I

Selinux would not be involved in this I think.

> will look at the web interface for the IPCop box, to see if I can find
> something I think might cause this problem.

See above. W/o a DNS function, with hosts defined in /etc/hosts, +trace
should not give anything. Dig needs some kind of DNS server to be found
to get the results we are looking for. For doing a dig *outside* your
local lan, it will/should got to the servers specified when the IPCop
boots and gets dynamic IP from your USP or gets fixed IP and you have
coded the servers in /etc/resolv.conf. E.g. my workstation has this
(populated when IPCop assigns the IP - do not modify by hand if your
IPCop is dispatching dynamic IPs).

$ cat /etc/resolv.conf
; generated by /sbin/dhclient-script
search HomeGroanNetworking
nameserver 192.168.2.20

Note that IPCop is the ...20 address and has the DNS caching active and
also has the dhcpd daemon running to assign IPs to my local network.

> <snip>

WAIT! You *do* have DNS cache running I think. Check the lines below
that say "server::

<*cluebat for me/you/us*>

Knowing this, you can't test on the local lan using +trace because
there are no other servers. One hop and back to you.

</*cluebat for me/you/us*>

> [lanny at dell2400 ~]$ dig dell1602.homelan
> 
> ; <<>> DiG 9.3.4-P1 <<>> dell1602.homelan
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28804
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;dell1602.homelan.              IN      A
> 
> ;; ANSWER SECTION:
> dell1602.homelan.       0       IN      A       192.168.10.57
> 
> ;; Query time: 2 msec
> ;; SERVER: 192.168.10.1#53(192.168.10.1)
> ;; WHEN: Fri Jul 11 16:35:11 2008
> ;; MSG SIZE  rcvd: 50
> 
> [lanny at dell2400 ~]$ dig +trace dell1602.homelan
> 
> ; <<>> DiG 9.3.4-P1 <<>> +trace dell1602.homelan
> ;; global options:  printcmd
> ;; connection timed out; no servers could be reached
> [lanny at dell2400 ~]$ dig dell1602.homelan
> 
> ; <<>> DiG 9.3.4-P1 <<>> dell1602.homelan
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55631
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;dell1602.homelan.              IN      A
> 
> ;; ANSWER SECTION:
> dell1602.homelan.       0       IN      A       192.168.10.57
> 
> ;; Query time: 2 msec
> ;; SERVER: 192.168.10.1#53(192.168.10.1)
> ;; WHEN: Fri Jul 11 16:36:38 2008
> ;; MSG SIZE  rcvd: 50
> 
> [lanny at dell2400 ~]$ dig +trace dell1602.homelan
> 
> ; <<>> DiG 9.3.4-P1 <<>> +trace dell1602.homelan
> ;; global options:  printcmd
> ;; connection timed out; no servers could be reached
> [lanny at dell2400 ~]$
> 
> I then Disabled the Firewall on my daughters box:
> 
> [lanny at dell2400 ~]$ dig +trace dell1602.homelan
> 
> ; <<>> DiG 9.3.4-P1 <<>> +trace dell1602.homelan
> ;; global options:  printcmd
> .                       0       IN      A       192.168.1.1
> ;; Received 33 bytes from 192.168.10.1#53(192.168.10.1) in 2 ms
> 
> [lanny at dell2400 ~]$
> 
> That is the FIRST time I have been able to use the dig +trace
> successfully!   :-)
> 
> The Firewall is off in my Desktop and also in my Daughter's Desktop.
> 
> [lanny at dell2400 ~]$ dig +trace gmail.com
> 
> ; <<>> DiG 9.3.4-P1 <<>> +trace gmail.com
> ;; global options:  printcmd
> .                       0       IN      A       192.168.1.1
> ;; Received 33 bytes from 192.168.10.1#53(192.168.10.1) in 2 ms
> 
> [lanny at dell2400 ~]$
> 
> The dig +trace to gmail.com does not look at all correct to me, but I
> only know about 1% of what I would like to know about Linux or
> Networking.

Try the smtp-server.triad.rr.com or pop-server.triad.rr.com and see if
it looks at all like the sample I sent earlier.

Regardless, that's progress.

> 
> Probably that is caused by settings in the IPCop box?

I couldn't say at the moment. But keep this in mind. The exact results
you get may not approach too closely samples you've been provided.
Different targets will have different gateway involved. Those may have
different levels of caches, there may be distributed servers, etc.

> <snip sig stuff>