My server's network interfaces are not available anymore since yesterday evening. I didn't change anything, but I added a new DNS-record shortly before.

Unfortunately, the web interface I used to add this DNS record escaped some characters, so I've got a faulty DNS record:

example.com 86400   IN      TXT     "\"v=spf1 mx a -all\""

However, this is the only unusual thing I could notice about this.

Is it possible that the \-characters in my DNS record are confusing for some routers? Or could it be the system itself which is confused by this (it's a Debian Lenny system).

Unfortunately, I can't quick-test it because of the long TTL of the record.


A faulty DNS record should only have impact on name resolution, not pure IP communication and would not have any interference with a router.

One bad zone file can prevent the entire DNS server from running, at least with Bind I've experienced this. So I could see you having issues with name resolution if this is your primary DNS server your workstation is using.

If you are not able to reach the system directly by IP, then something else is going on.

You mentioned a router involved, are you trying to reach this system from a different network so you are traversing a router or are you in the same subnet?

If you are in a different network, are you able to reach other systems in the same network as the server you can't reach?

If you can, get remote access to one of those systems and try to reach the server from the machine in the same network as it, that way taking routing issues out of the equation.


That you can get to others but not that one does point more at it being a system issue over routing, but doesn't rule it out. Best confirmation still would be to get on or to have someone else test pinging that box from another on the same subnet.

How are you traversing to this network, VPN, public internet, point to point?

Is there anything you can test on the box besides SSH, it may just be the SSH daemon not working.

Although the DNS is in question, you could try using nslookup or dig to test DNS resolution.

If there are web or mail servers, you could telnet to 80 (web) or 25 (smtp) to see if it connects. Note: you don't need to do all the testing steps, just the telnet serverip 25 or telnet serverip 80 will be sufficient. If they are there, you will see a text response.

Also, running a trace route from your machine to the non-responding machine and to one of them that is responding could be helpful. Look at the steps they take, if they go different routes, then you may have a routing issue. Depending on your environment your traceroute command could be traceroute, tracert, tracepath.

  • Yes, I'm trying to reach the system from a different network. I can reach other systems in the same subnet, but unfortunately I can't get remote access to any of them. The error message I get when I try to connect via SSH is 'No route to host'. – Bob May 11 '10 at 16:43
  • Just to make sure you got this part, the testing you are doing at this point is to IP address and not a hostname just to take DNS out of the equation. Once you can get to the box via IP, then you can work on resolving any remaining DNS issues. – ManiacZX May 11 '10 at 21:38
  • Thanks for your help. I found out the problem: it was a corrupt /etc/network/interfaces file. An error in DNS resolution initially made me reboot the server because I couldn't connect, and after that it didn't bring up the ethernet devices... – Bob May 12 '10 at 18:03

I don't know about other DNS servers but in the case of BIND, if doesn't like one of the records that zone file will not be loaded. In this case you will be working only with cached records.

As an intermediate measure to allow you to reach the server you might try adding it into your local hosts file.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.