|
|
|
| |||||||||
![]() |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Rate Thread | Display Modes |
|
#16
|
||||
|
||||
|
hm, well doesn't this just make things mysterious.
This is what we know: :::UDP queries to port 53 are getting through If your server is showing something in its logs, then it recieved the request perfectly fine. No ifs, ands, or buts about it. :::The server is not simply failing to respond We've tested locally and the server does respond to queries. It is rediculous to think that it is only responding to local queries and not to external ones. This only happens if you tell the server to do this. :::The server responses are not getting through Ordinarily, I would pick on the redhat firewall for being too restrictive. However, you said XP doesn't work either, and I don't think it blocks outgoing packets at all. So now I'm looking at the router. Perhaps you are blocking outgoing UDP packets? Certainly not all of them, or you wouldn't be able to resolve domains, but maybe just non-standard UDP ports. You wouldn't happen to have experience sniffing traffic do you? If I were in your position I would bust out my packet sniffer so fast... Very handy technique.
__________________
Send me a private message if you would like me to setup your DNS for you for a price of your choosing. This is the preferred method if your DNS needs to be fixed/setup fast and you don't have the time to bounce messages back and forth on a forum. Also, check out these links: Whois Direct | DNS Crawler | NS Trace | Compare Free DNS Hosts |
|
#17
|
|||
|
|||
|
Alright... My patience is growing thin with POSSIBLE router problems, so lets eliminate that!
So... Now I have my active internet line run straight to my computer with Xp on it (no router). I do NOT have the Xp firewall enabled for this connection. Now when I use your crawler as before I get the same results. TCP works fine, and UDP does not. When I use your Crawler I get this in my log: Feb 22 18:52:44.572 client 68.51.39.58#1675: query: ocranch.us IN A When I run dig @24.53.231.244 ocranch.us any from campus I get this in my log: Feb 22 18:57:15.631 client 199.237.74.140#42890: query: ocranch.us IN ANY Feb 22 18:57:20.628 client 199.237.74.140#42890: query: ocranch.us IN ANY I don't know what to say/think. How bout you? --- (edited at a later time) --- I downloaded a packet sniffing program called 'Sniffem' and you can find an export of the results when I ran DiG from a campus computer. I actually ssh'd into the campus computer and ran DiG from the SSH shell. That's what the SSH connections are. You can see from the 4th and 10th packets that UDP 53 requests were made, but I haven't worked with packet sniffers before and don't really know what to think of the output from the program. You can view that program at the following site: Sniffem Output This site is ran off my personal computer so it may not be up all the time ( I shut it off when I sleep). Last edited by skiloup : February 23rd, 2004 at 01:58 AM. |
|
#18
|
||||
|
||||
|
Could you try sniffing requests sent from the DNS Crawler to your server? Be sure to start the sniffing before you send the request and then wait a little bit to make sure you log the replies. If you can, filter for only DNS traffic, or at least only UDP traffic. That way other traffic won't clutter the log. Also, if there's a better log format I would like to see it. This one gives approximated raw data after each packet info header.
|
|
#19
|
|||
|
|||
|
Alright, I am trying a new sniffer called PacScope. Unfortunately its only a trial version so my export capabilities stink. I have taken a couple screen shots, hopefully you can see what you need to see from them. The trial version is a real bear. Only ten seconds of listening and the whole program only runs for ten minutes. So I have a small window to work with. Also the screen shots are about 150k apiece so I am sorry if the page loads slowly. Anyhow, here's what I got.
http://scorbin.chickenkiller.com:69/sniff2.html In the meantime while I was trying to FIND a sniffing program, I managed to get a TON of spy/adware. What a pain in the dairy aire! |
|
#20
|
||||
|
||||
|
the only discrepency I can see is that in the packet info in the first image it shows the first packet to have a destination of my IP address, and a source of yours. However, in the packet list at the top, and in the packet info header above the detailed header display both agree that the original UDP datagram was source me and destination you.
In your first test where you sniffed requests from the school I only saw packets coming FROM "192.168.0.65" and TO your IP. Not sure where the private IP came from which is why I suggested using the crawler instead of the shell deal. However the second test seems to say that there was both a request and reply packet. Most definately in the second screen shot analysis showed without a doubt that the packet was indeed a response packet. So now I can finally say that most definately the BIND server is working perfectly fine. Whatever networking related problems you're having is outside of my expertise. One thing I suggest. Find out if that linuxforum guy has the same ISP as you do. This could be a problem specific to that ISP. |
|
#21
|
|||
|
|||
|
Haha... You are right, I think that might be a slight programming error. I'm pretty sure that the IP Header is right though. As for the first test, I'm thinking that I was still 'inside' my router's firewall when I did that sniff so, I wouldn't trust any source/destination info (mindless actions have poor results; my bad). I'm with you though, I think my ISP is blocking more than they let the tech support know. Could they be dropping such packets locally, in town, and maybe not nationwide? Do you happen to know of any other people setting up DNS successfully under Adelphia Powerlink? As a side note, that's a pretty neat trick tracking me down in that other forum.
Thanks again for all the help, I'll be sure to let you know when/if I get this working. In the mean time, keep up the good work! We all appreciate it! |
|
#22
|
||||
|
||||
|
"Adelphia Powerlink"
I've never even heard of that ISP much less know other people with dns configurations with them. I really am sorry I couldn't help figure out the problem. The ISP is not blocking incoming UDP packets, but I guess there's a chance they're blocking the outgoing UDP packets - via what rule I have no clue since domain resolution appears to work fine and it uses UDP. "neat trick" heh, I never really thought about it but I guess I do kinda specialize in monitoring. Whether it be packet sniffing, file sniffing, registry sniffing, process monitoring, or website monitoring I tend to make it a kind of art form. What can I say, I want to know everything. ![]() |
![]() |
| Viewing: Dev Shed Forums > System Administration > DNS > Problems making my DNS resolve my new domain |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|
|
|