On Tue, Oct 21, 2003 at 03:56:41PM -0400, Neezam Haniff wrote:

Has anyone had any fun and exciting DNS issues pertaining to cityinternet.org? For example, try:

http://www.isc.org/services/public/lists/bind-lists.html

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 matt@snark.net If anyone has any further questions, comments or death threats feel free to e-mail me. Neezam.