apache up, sites down?

Did you verify that named is actually listening on udp port? I dont see how if you do a local lookup on the box it still wont work.

Do this and make sure it says udp and tcp:

Code: 
netstat -na | grep 53
 
Last edited:
I'm still not sure where the problem lies, but I'm going to look here:
Code: 
eonetworks.com.         172800  IN      NS      ns4.eonetworks.com.
eonetworks.com.         172800  IN      NS      pop.eonetworks.com.
eonetworks.com.         172800  IN      NS      pop.dns-stn.com.
eonetworks.com.         172800  IN      NS      plus.googlelife.us.
The above comes from a dig trace. This comes from the nameservers registered at your registrar where the domain is registered.

I can't find NS records for any of these. This could be because they're all pointing to your broken server. Are they?

But did you register these nameserves anywhere? ns4.eonetworks.com appears to be registered at 64.34.182.182. Is that an IP# pointing to your server? If so, then probably something is broken because neither apache, nor exim, nor BIND is answering at that IP#.

What about the other nameservers?
Code: 
pop.EoNetworks.com.   ['64.34.192.206']
pop.dns-stn.com.   ['64.34.192.206']
plus.googlelife.us.   [] (NO GLUE)[code]
pop.eonetworks.com and pop.dns-stn.com appear to be registered at the registrar at 64.34.192.206 and digs at those nameservers, by IP#, do work.

64.34.192.206 is working, and is responding to requests for apache, exim, and BIND.  Is that IP# on your server?

And as for plus.googlelife.us, it appears it has never been registered as a nameserver at your registrar and therefore you should not be using it.

For me, the eonetworks.com site DOES work, and it resolves to a DirectAdmin placeholder.  Is that where you expect it to resolve?

The only way I'm going to be able to resolve this is to do some forensic (investigative) work on your server.  If you're interested in learning how to hire me, please send an email to the address below in my siglines.  I do guarantee my work; if I can't fix the problem, I will refund your payment, based on the agreement we come to before we begin work.

Jeff
 
jlasman said:
I'm still not sure where the problem lies, but I'm going to look here:
Code: 
eonetworks.com.         172800  IN      NS      ns4.eonetworks.com.
eonetworks.com.         172800  IN      NS      pop.eonetworks.com.
eonetworks.com.         172800  IN      NS      pop.dns-stn.com.
eonetworks.com.         172800  IN      NS      plus.googlelife.us.
The above comes from a dig trace. This comes from the nameservers registered at your registrar where the domain is registered.

I can't find NS records for any of these. This could be because they're all pointing to your broken server. Are they?

But did you register these nameserves anywhere? ns4.eonetworks.com appears to be registered at 64.34.182.182. Is that an IP# pointing to your server? If so, then probably something is broken because neither apache, nor exim, nor BIND is answering at that IP#.

What about the other nameservers?
Code: 
pop.EoNetworks.com.   ['64.34.192.206']
pop.dns-stn.com.   ['64.34.192.206']
plus.googlelife.us.   [] (NO GLUE)[code]
pop.eonetworks.com and pop.dns-stn.com appear to be registered at the registrar at 64.34.192.206 and digs at those nameservers, by IP#, do work.

64.34.192.206 is working, and is responding to requests for apache, exim, and BIND.  Is that IP# on your server?

And as for plus.googlelife.us, it appears it has never been registered as a nameserver at your registrar and therefore you should not be using it.

For me, the eonetworks.com site DOES work, and it resolves to a DirectAdmin placeholder.  Is that where you expect it to resolve?

The only way I'm going to be able to resolve this is to do some forensic (investigative) work on your server.  If you're interested in learning how to hire me, please send an email to the address below in my siglines.  I do guarantee my work; if I can't fix the problem, I will refund your payment, based on the agreement we come to before we begin work.

Jeff[/QUOTE]

Hi Jeff long time no hear :) is Ivan.

all works now restoring, but i noticed these attacks
199.180.131.179	1436	Oct 26 23:35	Oct 26 23:35	Yes	IP Info	
202.102.89.81	770	Oct 26 23:35	Oct 26 23:35	Yes	IP Info

i had to block it in the deny area, once i block them everything was working (should of look there before the new os and all this restoring) 

Can we add a option right after "IP Info" with " block " ? or auto block after so many failed?
Click to expand...
 
There are a few firewalls discussed on these forums which will automatically block. I'm in testing mode now; I don't generally like automatic blocking. For example during my testing I accidentally locked myself out of the test server I was on.

In my opinion if you autoblock, unless you have static IP# from your office and can whitelist yourself, you may want to set up a startup script so your firewall won't start for five minutes after a system start. That way as long as you have remote power switch, if you lock yourself out you can restart your server and log back in before the firewall kicks in.

Or consider another method, such as wiping the last hour or two of entries (if you can track that) on system start.

I don't have any easy answers yet.

Jeff
 
You must log in or register to reply here.
Back
Top