Ok I miss-typed that "mapings" comment but basically if I do this:
> nslookup 126.96.36.199
Then I get all sorts of stuff in my cache which is *perfectly normal*:
--forward zone edu.net
A AC-DDNS1 188.8.131.52
A AC-DDNS2 184.108.40.206
A DDNS-A100 220.127.116.11
A t-ns1 18.104.22.168
A t-ns2-sec 22.214.171.124
--reverse zone 128.2.2
PTR 142 gruel-2-142.ppp.andrew.cmu.edu.
The only question is why would something on my network be wanting to look up that IP address.. or alternatively why would it want to look up gruel-2-142.ppp.andrew.cmu.edu?
Apart from a few more gruels, does your cache have anything significantly different or not? In particular do any of the IP addresses in the cache belong to your network?
Meanwhile 2.142 should not be the network part of your address (i.e. the first two octets) because whois says 126.96.36.199/8 is reserved. So I think you're saying it's the last two octets that match e.g. x.x.2.142 and that doesn't prove anything.
I also don't get is what you mean with "scans" and "clients were reporting their DNS names". It's typically the scanner itself that looks up DNS names to fit IP addresses, so what were you running and where from? Could it be buggy?
Is there any reason some 128.2.x.x addresses might be floating about on your network. Have you seen any say with Ethereal? Could a small typo on some machine/device result in that?
Rootkit Revealer is good.. I'd have run that on all the DCs.. probably followed by Autoruns (with don't display signed MS stuff turned on to reduce the clutter)... and then some AV scanner.. provided everything looked fine I'd then change all the admin passwords. Then I'd scour the event logs for anything unusual concerning DNS & DHCP.
Then I'd find a hub, connect it between your network and router, then connect a laptop with Ethereal on it to see if anything on my network is trying to talk to 128.2.x.x addresses (obviously then checking any workstation that are).
NMap isn't so useful in this scenario unless you scan the full 65K+ ports on each machine.
OK – we’ve got something similar but with the addition of a number of gruel entries.
The reason I mentioned DDNS was because ALL records in the cache are ordinary A or NS entries with the exception of those pertaining to CMU. Nevertheless, if it’s normal to have ddns in a cache then all well and good.
However, in our cache there are reverse lookups and the only PTR records in the cache are the Gruel ones which can number a good 80 or so.
I can’t see this as being normal.
If I do nbtstat – a, for example 188.8.131.52 I get the correct netbios name ‘FTT10’.
If I ping the same machine with the a switch I get
This is despite their being a legitimate A record for the machine in the forward lookup.
Nslookup 184.108.40.206 returns GRUEL-2-9.PPP.andrew.cmu.edu.
I am wondering what is the significance of all gruel entries being ptr records?
Our network runs on 220.127.116.11 (16) and the corresponding gruel address will always have the host part of our network (I origionaly posted ‘network’ - sorry about that) e.g.
18.104.22.168 will become
gruel – 2-9 ………..
It was ethereal which first alerted us to this problem and all our monitoring stuff says the same (we use network supervisor from 3com and we’ve just acquired observer after running a load of trials).
I’ve changed all passwords as you’ve suggested and I continually monitor event logs.
I’m going to have a deeper look at anti-rootkit tools. Your suggestion running ethereal inbetween the network and the gateway sounds like a good idea.
I know it's not strictly correct because it should be in the private range but we are behind that many layers of NAT. The internet is provided by the York council/Kingston/Affinity and they set this network up here long time before I got here.
Other schools in this area also use 22.214.171.124.
As far as the internet is concerned our machines are seen to have one single class C address which is one of Kingstons machines.
.... so, could this point to a configuration issue within our providers systems?
They really need to look at the RFCs to get an idea of what ranges they should be using.
Ok ... subnet masks can change to expand your "class 'c'" ranges to give you more than your usually 254 usable addresses, but the use of a public range on a private network, even behind something doing NAT is a no-no.
If you are really unhappy with the amount of work you have had to put in because of this you can complain to IANA (or RIPE), who do take a dim view of poor practice like this.
I would also have a whinge at Kingston/Affinity/York and explain your problems. If it is a range that they have put in there is no guarantee that they have been pubbering around with things either.
I shudder to remember that when EMBC came to set up our connection they did not have a working range for us, they decided to use a temporary range only to find that it was already in use by someone else and they buggered up their connection too.
Ok - its all coming out now. The head of ICT now remembers that the council had set us up with 192.168. blah.
Apparently the school ran out of IP addresses so a guy came in from another school and set the school up with a class B - only instead of 172 he assigned 128 telling all who cared to listen that we were natted so it would be OK.
And it was OK for two years.
I tried to log on to one of our Access Points yesterday and was presented with the portal for the Carnegie Mellon VPN. - highly amusing
So it looks like we'll be able to nail this one now.
I can't believe everyone has missed the absolutely blindingly obvious. I think its something like - how can anyone make such an elementary, basic error? Sometimes I suppose it just needs an outsider to point these things out.
OK - we managed to get a 'real' IP scheme given to us by Kingston.
I did the change over yesterday and did as you suggested and created a reverse lookup. All is well with the exception of IIS which appears to have lost its virtual directories and will not not work. Unfortunately this server seems to have corrupt event logs - not the most useful thing when trying to diagnose problems. I guess I'll have to try the Microsoft fixes to try and get the events back up. I was wondering if anyone had heard of problems with IIS after IP changes. I did find one obscure post somewhere but that was NT4.
I wonder if I should contact the admin at CMU, after all, we did seem to be a part of the university campus at one point LOL ;-)
Sorry to hijack, but whos a good DNS expert whos brain I can pick in a few days time, I am setting a new server up and I always seem to make a mess of DNS, or it works well but seems to after a few weeks get the hickley pups. I just want to run past them the way I am doing it and if its right or not