Tag Archives: DNS

DDoS DNS leads to User Interface Woes

When I moved my server a little more than a year ago I decided that I would try to get away from System Admin tasks by offloading services where possible. The first one to go was DNS. DNS is simple to manage, but just one more thing to look after. I had bought into the marketing hype about having off-site DNS so I decided to try a third party DNS. Unfortunately, having a service that many people rely on for ALL their services is just a target for attackers. After several DDos attacks with at least two providers I decided it was time to manage my own DNS again.

After my DNS was all setup I decided to retain those other third party people for my DNS secondary. After nearly a week of frustration I discovered one very important thing – not everyone that CAN program a computer SHOULD program a computer.
When I moved my server a little more than a year ago I decided that I would try to get away from System Administration tasks by offloading services where possible. The first one to go was DNS. DNS is simple to manage, but just one more thing to look after. I had bought into the marketing hype about having off-site DNS so I decided to try a third party DNS. Unfortunately, having a service that many people rely on for ALL their services is just a target for attackers. After several DDoS attacks with at least two providers I decided it was time to manage my own DNS again.

After my DNS was all setup I decided to retain those other third party people for my DNS secondary. After nearly a week of frustration I discovered one very important thing – not everyone that CAN program a computer SHOULD program a computer.

Sure, you know your network services, as much as anyone really can understand them, and you’ve administered a box for a while. You’ve got a great idea for a free online service so you set out at hacking away a user interface to allow your potential users to connect with your good idea. The problem is, you probably aren’t a programmer. Sure, you can figure out the semantics of a language pretty easy because you already know Shell script, but that certainly doesn’t make you an accomplished application developer.

How do I know? Because I’ve used your applications. Here’s some things that frustrated me:

– inaccurate error messages
– no error messages on an error
– the WRONG error message for an error
– a blank screen instead of an error message
– your PHP path and MySQL info echoed to screen on an error
– assuming the error was MY fault

Of course that is just a mild sampling that kept me from using a service properly in the past week. We really don’t know what goes on behind the scenes. When you built your application was there a white board involved? Did you have developer meetings? Is there a printout of a schema? Or did you just sit down and start typing until it looked good? Whatever way you chose, it didn’t work, it didn’t work well, or it just plain failed.

Either way, not everyone is a programmer. Too bad that scripting for the Internet is so easy that everyone has had a crack at it. Most of those people would probably get queasy if they were asked to rewrite that application in the C programming language.

We are taught to examine and verify user input but that makes us assume that all problems are caused by the user. Make sure you put in checks on your own code. Check for database connects, rows returned, function returns, etc. This way you can debug your own code as well. I used to put secret checks into my code that would either log or email me on an unexpected problem that didn’t throw an error.

As you can guess, I quit using this service. It was too frustrating to setup and I could never be sure that the values I input in the user interface were accepted. Trying to bypass the inconsistencies was remnant of hacking on a TRS-80. I think we can all learn a good lesson about user interface design when faced with problems we see on other sites. The key to a better programmer is remembering what that was, and then applying it to your sites. Sometimes you can be too close to your own project to see them.