View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002274 | unreal | ircd | public | 2005-01-11 22:24 | 2005-03-01 16:26 |
| Reporter | matridom | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | random |
| Status | closed | Resolution | open | ||
| Product Version | 3.2.2 | ||||
| Summary | 0002274: DNS resolution problem. | ||||
| Description | I posted in regards to this on the forums, but after more investigation, I feel it's best to post this problem here. I will go over 1 example in detail. I'm getting about 5-10% of IP's not resolving properly. I'm getting this also across 2 servers with 2 different names server in 2 different regional areas. Here are some results from the SQL database and a page I wrote to get the right info out. The below outputs are in 3 colums: Time, IP/DNS that the server logged, DNS name if IP was logged. 2005-01-11 13:11:48 67.177.127.XXX c-67-177-127-XXX.client.comcast.net now, here are the results from the nslookup > 67.23.150.87 Server: bossman.private.net Address: 192.168.0.1 Name: c-67-177-127-XXX.client.comcast.net Address: 67.177.127.XXX > c-67-177-127-XXX.client.comcast.net Server: bossman.private.net Address: 192.168.0.1 Name: c-67-177-127-XXX.client.comcast.net Address: 67.177.127.XXX The name resolves fine both ways.. now here is the interesting part.. withing 10 minutes 2005-01-11 13:19:37 c-67-177-127-171.client.comcast.net - So the server properly logged the DNS name for the same IP. -> Server: dns - Ca 233 Cd 225 Ce 180 Cl 0 Ch 0:120 Cu 120 - Re 80 Rl 438/269 Rp 715 Rq 587 - Ru 0 Rsh 2 Rs 715(128) Rt 5 -> Server: dns i - Nameserver list has 1 server(s): - 0. 192.168.0.1 - retrans=5 s, retry=4 times - Default domain name: private.net - End of info. please refer to here http://www.phpmemx.net/~unrealir/forums/viewtopic.php?t=1324 for other troubleshooting that I have already completed | ||||
| Steps To Reproduce | The problem is persitant, however occurs randomly. I am unable to consitantly recreate the problem but I am always able to detect an instance of it. | ||||
| 3rd party modules | activeusers sqllog | ||||
|
|
*Just realized it's on the wrong catagory. Could someone please place it in the correct catagory? |
|
|
I had to think quite a while what the best method of tracing this is. I think the best solution for both of us is if you capture dns packets for ~24h by using the following command: tcpdump -i <iface> -s 0 -n -w capturefile port 53& Where <iface> is your ethernet interface to the nameserver (eg: eth0). And then at the end of the 24h you do a killall -15 tcpdump (or directly the pid, but in either case not with -9, but with -15). And then you mail me 'capturefile' (well, gzip it first with 'gzip capturefile' and then send me the .gz), along with a database dump of the connects (including the exact date/time! so I can match up dns packets with the results). If you are concerned about security, then you can always use my PGP key (http://www.vulnscan.org/pubkey.asc) to encrypt your email&attachements. Hope this will help. |
|
|
I was trying different DNS servers to see if that was the issue (.1 is non-localhost) i'm back on localhost and the capture has started. will e-mail you tomorow around same time. |
|
|
Initial results from the dump file seem to indicate an issue with the DNS server. Under recommendation, I redirected to my ISP's external DNS server. The issue still apears to be ongoing. Resolved IPs: 81, Unresolved IPs: 39, Unresolvable IPs: 24, Errored IPs: 15 If anything the results are worse using the ISP's DNS server. Is there anyway to change the timeout for dns resolution? |
|
|
The thing is, unreal just didn't receive a (correct) reply, so this is a nameserver problem (or in any case non-unreal). As I told you, the timeout did not seem to be the issue in the dump you gave me since it received all responses within 0.3 seconds. If you however want me to doublecheck you can give me a dump again (like with this thing directly to your isp nameserv). But if it then still turns out not to be unreal I'm gonna close this bug, I hope you will understand that.. :). |
|
|
I think this can be closed, it was never confirmed to be an unreal issue. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-01-11 22:24 | matridom | New Issue | |
| 2005-01-11 22:24 | matridom | 3rd party modules | => activeusers sqllog |
| 2005-01-11 22:27 | matridom | Note Added: 0008782 | |
| 2005-01-12 00:03 | syzop | Category | documentation => ircd |
| 2005-01-12 00:09 | syzop | Note Added: 0008784 | |
| 2005-01-12 17:57 | matridom | Note Added: 0008789 | |
| 2005-01-13 19:42 | matridom | Note Added: 0008806 | |
| 2005-01-13 19:52 | syzop | Note Added: 0008807 | |
| 2005-03-01 16:26 | syzop | Status | new => closed |
| 2005-03-01 16:26 | syzop | Note Added: 0009386 |
