Discuss mailing list

[subhuman <discipline AT gmx.net>]

On Thu, 23 Dec 2010 06:38:03 -0700
Jeff Taylor <shdwdrgn AT sourpuss.net> wrote:

> Actually from the results you are getting, my guess is that your ISP is 
> hijacking your DNS queries and substituting their own results.  This is 
> based in the fact that your pings are returning an IP obviously from 
> your ISP (89.246.64.39 - I assume your ISP is versatel.de?)...
yes it is.
[snip]

[snip]
> If you want to go this path, just follow the setup instructions on the 
> opennic website for creating a tier-2 server, just don't publish it as a 
> public server (unless you want to).  The setup works just as well for 
> local queries, and BIND will also provide local caching for you.
I'll go and try. Thx 4 your advice so far. Without having taken a look
at the opennic website, might "pdns-server - extremely powerful and
versatile nameserver" (result from debian's apt-cache) be of any help?

> 
> 
> On 12/23/2010 03:49 AM, subhuman wrote:
> > 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
> >
> >    
> _______________________________________________
> discuss mailing list
> discuss AT lists.opennicproject.org
> http://lists.darkdna.net/mailman/listinfo/discuss


-- 
Volk ist Opium für eine Religion.