North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: cityinternet.org DNS issues..

  • From: Neezam Haniff
  • Date: Wed Oct 22 13:50:23 2003 
Hi,

	Several people have e-mailed me asking what happened and possible
solutions to the problem. In hopes that this may someday help other people
in trying to track down the problem; I will re-iterate the problem and
possible solutions.

	Originally, I just wanted a means of overriding the data being
returned for NS1.CITYINTERNET.ORG and NS2.CITYINTERNET.ORG. Reason being
was that our nameservers were getting inundated with the following
message:

Oct 21 00:00:17 ns named[3203]: sysquery: nslookup reports danger (NS1.
CITYINTERNET.ORG)

	I'll also give you the research I did in determining what was
going on.

	Based on references I found in google, it appeared that there may
have been a configuration issue on our nameserver. I went through our
nameservers to determine if we were primary or secondary for this domain,
which we are not. I also checked all the zones to see if CITYINTERNET.ORG
was referenced anywhere. This was also not the case.

	Please note, just because you see this error in your logs, does
not mean there is something wrong with your nameserver configuration. You
need to do some follow up to determine the source of the problem.

	Going through the nameserver logs, I found the following entry:

Oct 21 00:04:08 ns named[3203]: ns_resp:  query(149.70.64.69.in-addr.arp
a) Bogus (0.0.0.0) A RR (NS1.CITYINTERNET.ORG:0.0.0.0) learnt
(A=64.247.9.98:NS=192.41.162.32)

	From this point, I activated debugging on the named process.
Processing the queries for the period that debugging was turned on;  we
found that there were customers who were trying to resolve 69.64.70.149.
Hence the reason our nameserver was making queries to
NS1.CITYINTERNET.ORG. Why anyone would be querying that IP block is a
totally different exercise.

	Now, if you try to resolve NS1.CITYINTERNET.ORG, this is what you
will see:

; <<>> DiG 9.2.2 <<>> ns1.cityinternet.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11247
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.cityinternet.org.          IN      A

;; ANSWER SECTION:
ns1.cityinternet.org.   43200   IN      A       0.0.0.0

;; AUTHORITY SECTION:
ns1.cityinternet.org.   43200   IN      NS      .

;; Query time: 77 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Oct 22 11:36:04 2003
;; MSG SIZE  rcvd: 67

	The A record is invalid, so is the NS record. I decided to go one
step further and determine what IP space CITYINTERNET.ORG was assigned.
Doing a WHOIS lookup revealed that they had 64.64.64.0/20.

	At this point, I was trying to figure out if we would have to
override the zone. I figured you guys would deal with this stuff
constantly. :) I just wanted to know if there was a 'correct' answer.

	Someone followed up with me and pointed out there were zone
inconsistencies between ns1.zoneedit.com and ns2.zoneedit.com. Several
other individuals followed up with suggestions as possible solutions to
this problem.

	The polite, correct solution is to contact someone at
cityinternet.org or zoneedit.com and ask them to change or remove the
data.

	The not-so-polite, not-very-correct solution is to override the
zone via your nameserver locally. It won't try to connect to
0.0.0.0 or . when it tries to do lookups associated with that nameserver.
Be aware that doing this may cause earthquakes, floods, other natural
disasters, unnatural disasters and many other things.

	I'd like to thank the following individuals for providing useful
insight:

John Souvestre
Chris Parker
[email protected]

	If anyone has any further questions, comments or death threats
feel free to e-mail me.

Neezam.