Discuss mailing list

[Jeff Taylor <shdwdrgn AT sourpuss.net>]

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?)...

Now if this is the case, you can try contacting your ISP and complain 
about the problem with their service, but most likely they are 
generating extra income from the DNS redirects, and will not care to 
make an exception just for you.  The good news is that you run linux, 
which makes it very easy for you to set up your own BIND server.  We 
have seen other users in the past who had to do this for the very same 
reason - packets being hijacked by their ISP.  Since your dig queries 
returned the expected results, setting up your own local nameserver will 
side-step your ISP's meddling and give you full control again.

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.


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
>
>