Discuss mailing list

[subhuman <discipline AT gmx.net>]

On Wed, 22 Dec 2010 01:09:30 -0700
Jeff Taylor <shdwdrgn AT sourpuss.net> wrote:

> For the German servers you mentioned, I assume you are referring to 
> 178.63.26.173 and 217.79.186.148?  I just ran a test on both servers, 
> and they are responding fine.  So first we want to see what 
> /etc/resolv.conf looks like.  Grab a copy of that and paste it into an 
> email to the mailing list.

## the original version, created by pppd on startup:
# cat /etc/ppp/resolv.conf.orig 
nameserver 89.246.64.38
nameserver 82.145.9.38

## the opennic version:
# cat /etc/ppp/resolv.conf      
nameserver 178.63.26.173
nameserver 217.79.186.148

> 
> The next step is to make sure your end (either your servers or your ISP) 
> is not blocking the queries.  Try executing this and see what you get:
> 
> # dig NS . @178.63.26.173 +short
> 
# dig NS . @178.63.26.173 +short
ns21.opennic.glue.
ns4.opennic.glue.
ns2.opennic.glue.
ns5.opennic.glue.
ns22.opennic.glue.
ns6.opennic.glue.
ns7.opennic.glue.

looks fine so far, doesn't it? but:

# ping www.opennic.glue
PING www.opennic.glue (89.246.64.39) 56(84) bytes of data.
64 bytes from paxweb.versatel-nord.de (89.246.64.39): icmp_req=1 ttl=59 
time=17.6 ms
64 bytes from paxweb.versatel-nord.de (89.246.64.39): icmp_req=2 ttl=59 
time=19.9 ms

even after having stopped ncsd, deleted its cache db's, and started it again.

> You do NOT need to restart networking, however it may help to restart 
> nscd (if you have it) to flush the DNS cache.  
Which is what I don't understand. Because how can pppd know that from now on 
it must not 'usepeerdns' any longer - when I haven't restarted it?

> After this, start simple 
> - ping google.com.  
# ping google.com
PING google.com (66.102.13.106) 56(84) bytes of data.
64 bytes from ez-in-f106.1e100.net (66.102.13.106): icmp_req=1 ttl=54 
time=35.7 ms
64 bytes from ez-in-f106.1e100.net (66.102.13.106): icmp_req=2 ttl=54 
time=29.8 ms

> Then move into opennic domains by pinging ns0.opennic.glue and grep.geek.  
# ping ns0.opennic.glue
ping: unknown host ns0.opennic.glue

# ping grep.geek
PING grep.geek (89.246.64.39) 56(84) bytes of data.
64 bytes from paxweb.versatel-nord.de (89.246.64.39): icmp_req=1 ttl=59 
time=18.5 ms

All this looks a bit contradictory to me, compared dig's response with all 
the rest.

>If things seem to be working, try the 
> shortened dig command:
> 
> # dig NS . +short
> 
> This should return the same list of nameservers as above.  
It doesn't:
# dig NS . +short
i.root-servers.net.
b.root-servers.net.
h.root-servers.net.
c.root-servers.net.
e.root-servers.net.
j.root-servers.net.
k.root-servers.net.
f.root-servers.net.
m.root-servers.net.
d.root-servers.net.
g.root-servers.net.
l.root-servers.net.
a.root-servers.net.

> If everything 
> appears to be working now, then the problem lies in how your networking 
> script is applying the user DNS entries (which we can probably verify 
> once we see what your original resolv.conf file looks like).  Let us 
> know what works and what doesn't, and we'll proceed from there...

Hope you find through all this. 
--Martin

-- 
Volk ist Opium für eine Religion.