Miscellaneous Operating Systems/Hardware

This thing is driving me nuts. Either the people running dns here are total morons (possible) or they are very clever people doing it on purpose (also possible) or there are two groups equally responsible, the morons and the cunning bastards. Anyhow ...


The timestamps returned from everything past the gateway in the traceroute are a stone lie - you can sit and watch it take minutes to return on some of those hops.

There is a rumour that enforcing tcp-only on some well-known external dns servers will alleviate this problem. I know that just setting one's dns server settings to known-good servers does not help. The ip's are getting poisoned somewhere. Somewhere north that starts with a B and ends with a g .. Even worse, the poisoned entries eventually screw up the good ones and you have to clear all the cached ip's in the local dns server.

Using the real ip also does not help much. If you know the correct ip, that occasionally works but not usually. Most servers now host several sites on one ip and use the desired hostname to figure out which website will be returned. If you just use the ip you don't get the site you want.

But I'd like to know what is really happening. Too bad I'm not smart enough to figure this out on my own ... but Cisco was behind this and they're smarter than me. Thanks, assholes. Anything for a buck, eh ?


Anyway, first biggest thing I do not understand is, if you do an nslookup the ip is returned right away. Often it's even the correct one. However, a ping immediately thereafter can come back with "domain name not found." Umm, how is that done (and how to get around it ?

first of all, is "urchin" unix?

Woof ! Woof ! Irix Dog Food is the most nutritious for your growing hound !


There are also Windows and Solaris and Mackletosh "It's Yeewwwnix !" machines on the network awailable for testing if need be.

OK, you have configured a working DNS server in /etc/resolv.conf. Name resolution using DNS works...

... but are you using DNS are a source for host name resolution? Other sources (LDAP, NIS, files, ...) exist too.

Your sources are configured in /etc/nsswitch.conf. This is how mine looks:

The crucial bit here is:

Host name resolution tries NIS first, then DNS, then files (/etc/hosts)
Most people can probably eliminate 'nis' here, and/or swap the order of the 'files' and 'dns' entries.

Check

files, dns

As little as possible in files, if the router/dns server does most of it I don't have to mess with hosts files all over the place.

Almost exactly the same except :

for me is


Check

double check

Also ...


Everything works lovely, then the whole dns thing falls into the pit, then an hour later it all works lovely, then it will quit again. No change whatever from me (although sometimes I'll get antsy and clear the cached host entries on the dns server, which seems to help. But that might be a coincidence.) Local and first-stop dns is done on the router (cisco). Lots of poisoned dns entries even tho I am not (supposedly) using their dns servers.

If I could figure out what the heck they are doing I could either get around it or give up. But just having it screw with me pisses me off and wastes a lot of time, too.

Does this happen with other hosts, or just pop.gmail.com?

Many others but gmail is the only one I care about. I can live without youtube and facebook. In fact ....

I wouldn't care about gmail either but have too many old mails, addresses, people who have my info ... not going to change that just for the harmonica society.

I can't get pissed at them for messing with google, google is essentially shit and should be messed with. It just happens to inconvenince me

Admittedly, having all the dynamic ip's poisoned can be a pita sometimes also.

Well, my only thought was that you were hitting different DNS servers with subsequent queries and one happened to be broken.

that sounds pretty much like an external issue. how about adding more servers to your resolv.conf?

"cisco" routes your subnet to "gateway" and runs a caching-only nameserver? What nameservers does cisco query when you ask it something that's not in its cache?

Excactly ! But I don't think that cisco is getting good ip's even though it is supposed to be querying safe upstream nameservers. I have tried several : currently one is a google server (contributing to the Evil Empire, I should be ashamed of myself), one is maybe OpenDNS ? and the last is 4.2.2.2, the Universal DNS Server.

I can and have changed them around tho, with no real improvement. How can I tell whence the internet addresses are really originating ? One thing that throws me off is the < nslookup >, <ping hostname : "can't find hostname"> sequence. If I do an nslookup and the cisco returns an ip, why cannot Mr O350 find that ip five seconds later for a ping ?

There is a rumor that enforcing tcp queries rather than allowing udp requests fixes this problem but I am skeptical .... any thoughts on that ?

Yes, personal vpn's have been useful in the past but they are problematic at this time. Nor do I think IBM will give me a corporate vpn account so I can get my mail easily

UDP is reputed to be more error prone because it's "fire and forget" whereas TCP is "self healing," so there might be something to that. Presumably the google nameserver that you're querying is in the PRC, and thus might have been tinkered with by the Central Committee? I thought google bailed from the PRC after they got all that bad publicity for caving to the CC's demand for censoring. What version of BIND are you using? I run a caching-only nameserver on my firewall with bind-9.9.1_P3 which queries OpenDNS upstream and it works perfectly, but then I'm in the heart of the good 'ol USA...

Silly test you can do: remove all but one nameserver. Test. If it does work fine, replace by other nameserver. Test again. Repeat for all nameservers you use. Pinpointing the misbehaving one is what I'd attempt first.

Unless multiple ones are misbehaving, and then you're in for a fight.

What does 8.8.8.8 have to say?

Sorry to hear the dragon of misfortune has visited you, hamei.

Personally I would not test with an IRIX system, nsd is a beast of black magic that previously has interfered with my happiness. Is some foul demon eating your udp packets, though? Looking at the man scroll, it seems that IRIX' traceroute uses ICMP packets instead of the traditional UDP, so working replies might not be an indication that it's limited to DNS queries.

Look, now you made me write like you do

Since when has anything but ICMP been "traditional" for traceroute?!

Van Jacobsen's 1988 traceroute used UDP probes.
http://www.kohala.com/start/papers.othe ... 9feb08.txt

you're right, I got confused about where the TTL field that traceroute needs to work actually comes from.

More like the dragon of exasperation They do this on porpoise and the solutions are worse than the problem.

Google I don't care about that much. Yes, it's an okay search engine but way too much baggage and the searches themselves are becoming less and less relevant.

But the mail is annoying. If you run a mail server from China, most of your mail gets bounced. "It's from Chiiina, must be spam !! Pita.

So you give up and use gmail. What happens then ? "You use google, we're going to fuck with you, hrr hrr hrr."

Can't win for losing.


It is strange that a Windows computer on the network acts differently. Not correct, just differently bad.

While an iPad, going through the same router, had no problems. That day, at least.

The intent is Microsoftian : make it so miserable to use that no one will. And I can understand that, but it's an annoyance.


After some frustrating research, it looks like this is maybe what is happening :

I can use the dns server I want. Normally that works correctly. This is designed to fool us proletarian suckers. If you grab the Spinrite tools (yes kids ! We will be testing our DNS today ! DNS, as you know, is one of the main building blocks of the Internet ! ... Steve Gibson hasn't changed one iota in thirty years, bless his pointy little head) and also the Google name server tools seems to work correctly. The google tool mentions all the poisoned dns tho ... how can that happen ? they are getting returns from their own name servers ! how ?

Maybe Cisco IDS. If you look at a traceroute there's one huge jump right before it leaves the country (and travels halfway around the world for fun) :

If you use the Chinese name servers, they are close by but pre-poisoned. So you go for one in the Free World. The theory is, you think you are using the name server that you ask for. And you are. But when you hit a keyword, the friendly neighborhood Cisco Intrusion Detection System somewhere around 219.158.29.218 bounces back a bad address to your requesting server, even as it lets the query continue happily down the road. Or ditches it into the drink, I know not which. The requesting host accepts the first piece of junk that comes back, naturally, and off we go to the wrong place.

Correct me on this but it seems that if you force tcp rather than udp, would the requesting host wait for the correct address rather than assuming the first thing that just came back via udp was the right answer ? Are there any functional secure public dns servers that encrypt or otherwise protect the receiver from poisoned dns ?

There's a software project for someone - an encrypted dns server running on a non-standard secret port ... hmm.

What was confusing was that it seemed like I was using a good name server instead of the crap China Telecom tries to feed you. And I was ... but they can bounce back wrong answers even if you are using a different dns server. Without it being obvious, either.

That still doesn't answer another mystery tho - when this happens (I believe it occurs when they are messing with their poisoning system and things get out of wack) I can (sometimes) do an < nslookup hostname > and get a cached result back instantly. But an immediate following < ping hostname > returns "Host not found" or something to that effect. Happens from both Irix and Windows. WTF is the story here ?

The Internet in China is a never-ending adventure


I'll tell my Mom she scored another victory

just guessing, but nslookup uses its own internal resolver, not the system resolver library. so it's sometimes the case that lookups happen differently (and not surprising that lookups done by nslookup don't enter the system's address cache)