Joomla Advice

I know Joomla. If you need help or advice with your Joomla site please feel free to contact me. I would love to help.

Comment (0)

In late August the White House mandated that all of the agencies in the US government have functioning DNSSEC capabilities deployed and operational by December 2009. I am suggesting here that we, as a community, commit to the same timetable. I call upon VeriSign and other registries to bring up DNSSEC support by January 2009. While DNSSEC is not the best ultimate solution, it is the best option currently available.Here are the additional resources suggested by the White House:

The following resources provide additional technical information and guidance to support your agency’s DNSSEC deployment.                

The USG DNSSEC deployment email list: http://www.usg-forum@dnssec-deployment.org                

Comment (0) Read More...

I have been thinking about how much people are thinking about DNS and I came across the Google Zeitgeist project (http://www.google.com/intl/en/press/zeitgeist/index.html). Basically this is an interface to understand what people are using the Google search engine for. Specifically, I was poking around Insights for Search and queried a few terms related to DNS. The information is fascinating. The most interesting part I noticed is the number of searches and the countries they are coming from. Again, I find this stuff fascinating. We beat the drum each day for DNS and most people never give it a thought, much as it should be, but if you are reading this you probably have a bit more interest. DNS searches have actually decreased over the past few years. Maybe people are more educated? Less concerned? However, DNS attacks are on the rise that is certain.

In our last TechTalk event we had a great number of participants and fielded a lot of questions. There was some good discussion about DNSSEC implementation. Based on what we discussed - you should plan to have your DNSSEC implementations done by the end of 2011, at the latest. Also there were lots of questions about reverse DNS. Reverse DNS is just like DNS but specifically for the IP addresses, for example when you want to know what an IP address points to you would do a reverse DNS query.

The questions were focused on how admins setup a reverse DNS. Reverse DNS is typically maintained by the organization who “owns” the IP address(s) or block. In their DNS server they create records for each of their IP address that point to hostnames. Many times those host names will be generic, which is fine. For certain things, especially email, having the hostname come back as generic can create a problem. For example, when you email server attempts to send a message to another server (the receiving server), nine times out of ten, the receiving server will do a reverse DNS lookup on the IP address of the sending server, if the hostname returned is not related to your email zone or if there is no reverse DNS record the receiving server may reject the message. Some email servers can get particularly persnickety about this.

So make sure your reverse DNS ducks are in a row. One of the easiest ways to verify all of your DNS settings is to run a DNSreport at DNSstuff.com. You first need to get a free 21-day trial account to have access to all tools.

Comment (0)

Email is one of the most important communication mediums to date. We have become dependent on it and since it works so well, we have high expectations that it will work when we need it. But, how does it really work, and what if any role does DNS play in email. First as we discussed in the past, every communication on the Internet depends on DNS, including email. So let’s dig in to what we need to know about DNS and email.

When a user sends an email they are not actually sending the email directly to the recipient. They are, rather, asking their server to take the message and deliver it for them. Once the server accepts the message it tries to deliver it. Here is what, in the simplest manner, the server does. It looks at the envelope and finds the address of the recipients mailbox, for example parisi@yada123.com.

The server then looks at the domain part of the address, everything to the right of the @ sign, yada123.com{dot} and does a DNS lookup. In effect the server asks what are the MX records for yada123.com{dot}? (By the way MX stands for Mail eXchanger, i.e. the server/host responsible/able to receive email for a domain) If DNS is working for that zone, in this example, it should receive an answer of yada123.com{dot} – what – huh? Didn’t we just ask for yada123.com’s address? What is the deal? Well we did, but we asked for the MX records for the domain. As a rule MX records point to A records. So we got back an A record. A records are also called host records, and A records resolve to IP addresses, cool, feels like we are getting closer.

What does the server do now? It needs to ask a second question of the DNS, please (servers are very polite) give me the IP address associated with the A record yada123.com{dot}. In this example the result returned should be 70.120.44.51 – finally, “whoo hoo” an IP address - we can do something with that! The mail server attempts to make a TCP/IP connection to 70.120.44.51 and does so using the SMTP protocol. If all goes well, we won’t get into SMTP details here; the receiving server accepts the message and, again in the simplest of examples, puts it in your mailbox.

Comment (0)

Let's move on. Let's suppose you want to put up a web site on your new domain name? You find a suitable, reliable web hosting company, buy an account and visit their control panel and create your web site, even if it is just a simple page with "Hello, world" on it.

Now you have a choice to make - you need to setup your DNS settings. For this example, let's say your DNS is currently hosted at GoDaddy, you can continue with that and go and add records there or you could move your DNS to your web hosting company, it's your choice (dedicated DNS hosting is available from EasyDNS, DNS Made Easy and DynDNS - all excellent companies with good infrastructure). If you want to stay with GoDaddy for DNS, you will need to change a few things, basically, remove your entries from pointing to parking servers to point to real servers. There is nothing inherently wrong with staying with GoDaddy, they have reasonable controls and they seem to work well. But, being IT people we never can leave well enough alone. So let's use our own DNS server, at our hosting company. We will need to use their control panel to add all of our DNS records to the new name server. Minimally, we need to create the following records:

; Zone file for yada123.com
$TTL 14400
@      86400    IN      SOA     ns1.examplehost.com. hostmaster.examplehost.com. (                2009031602      ; serial, todays date+todays
             86400           ; refresh, seconds
             7200            ; retry, seconds
             3600000         ; expire, seconds
             86400 )         ; minimum, seconds

Comment (1) Read More...

Over the past few weeks I have been seeing reports that some ISP's are actually subverting DNS queries to their own DNS server. Oh the humanity! What this means is that when you (your computer) does a UDP or TCP Port 53 DNS query the ISP is intercepting that and directing it to their own servers. Has anyone been told by their ISP that they are doing this? No? I didn't think so. Subversion of DNS, even for your own good, is not a good thing. This has the effect of controlling wherever you go on the internet. It is a good thing our ISP's know better than we do. Not!

I need your help here. I would like you to run some simple tests and report your results to me. I need you to run an NSLOOKUP or DIG to a specific name server on a specific zone that the DNS has not been made aware of. Using the zone for the query will cause any subverted queries to return non-existent domain (NXDOMAIN). If you have a few minutes please go to the following link on my home page and give it a try. Go to http://www.paulparisi.com/queryproject and input your findings. Once we get a critical mass we will start to publish the report. 

 

Comment (1) Read More...

Download it now: http://secunia.com/vulnerability_scanning/personal/ Secuina PSI is a great Windows application to give you visibility into what security threats are sitting on your computer. There are so many pieces and parts of software that can be easily compromised... how do you keep up with all the updates? Use Secuina PSI. It is free for personal use and I don't compute without it. Not only does it show you what has an issue but gives direct links on how to fix it. Cool.

Comment (0)

Many DNS issues result from gaps in our knowledge – typically because we do not work with DNS all that much. So I thought it would be good to give you an overview of what happens from the beginning. The premise here is you want to implement a new DNS domain name. Let’s pick something to experiment with, yada123.com, first we need to see if the domain name is available and if so, we need to register it. For this example we are going to use GoDaddy, but any registrar should be fine. Go to www.godaddy.com. Find the search field on the form, GoDaddy’s home page is a bit cluttered but the search is there. Type in yada123.com and hit enter or click go. Congratulations we see that yada123.com is available. We need to buy the domain name. Complete the purchase process and once done, you will have a new domain name.

Now what actually happened here? Once you paid for your domain. GoDaddy added a record to its database, and being that it is a registrar, it sends that information to the root servers for the domain you registered, in this example, the {dot}com domain. The root servers are a collection of servers distributed all over the world that keep the initial pointers to the sub domains for which it is responsible. For example, there are root servers which hold the pointers to the servers responsible for the next level zones. When you read a domain name you read from right to left, and all DNS zones begin with a period, which indicates the root, sometimes people do not type the period when referring to domains but it is implicitly there. So for example, we look at yada123{dot}com{dot} we see that we can start at the {dot} zone, the root, and ask those servers “where do I go to get information on the {dot}com zone?”, the root servers will return a list of server which can be asked about {dot}com zones. These are the servers that GoDaddy has to notify that it has a new domain that has been registered and that the nameservers for that domain are NS57.DOMAINCONTROL.COM and NS58.DOMAINCONTROL.COM, for this example.

Ok, so here is the deal, you open a browser right now and type in www.yada123.com, what happens? Your browser checks its internal DNS cache to see if there is an entry for yada123.com, since there is not, the browser then asks the local resolver if it has an entry for yada123.com, the local resolver says no, but says please hold, it (the local resolver) then asks the DNS server it has been configured with if it knows anything about yada123.com, that DNS server checks its cache, finding nothing, it asks the root servers for the {dot}com servers, it gets the answer then asks the {dot}com servers what they know about the yada123{dot}com zone, if the changes have propagated to the server you asked it should return the SOA record (Start of Authority) for yada123{dot}com, which is NS57.DOMAINCONTROL.COM and NS58.DOMAINCONTROL.COM. Ok now we know which server we have to ask about the www record for yada123{dot}com. Next, the DNS server opens a connection to one of those two servers (NS57 or NS58) and asks for the www record in zone yada123{dot}com – what is the answer? If the record is an A record it will return an IP address. If it is a CNAME (canonical name) it will return another record to lookup, ultimately resulting in an IP address. Now wait, what is the IP address that we are going to get in this specific case? When we registered with GoDaddy, they created a placeholder for the domain and it will direct browsers to a “parking” page hosted by GoDaddy.

Comment (0) Read More...

Every IT person has some interaction with a DNS server, even if it is not managing it. Most DNS servers, certainly the majority are sitting in some closet or rack somewhere dutifully running and collecting dust. Like a certain battery operated bunny, these services just keep on running. The durability of DNS (Domain Name System, that is) is a testimony of just how well it was designed. DNS serves every single user of the Internet consistently, day-in and day-out. What DNS does and how well it does it is nothing short of an engineering miracle simple, elegant, scalable - truly amazing. How often do you think about your DNS server? Here is my plan for how to keep your relationship with your DNS server alive and well.

1. Check your system logs to make sure there are no impending hardware failures on the horizon. For example, be sure you have SMART enabled to check your systems hard disks and make sure that you can receive the SMART alerts should they occur. You should also review your logs for any other errors such unexpected reboots that you may have missed.
2. Monitoring, you should really think about monitoring your DNS server. Is it up? Is it responsive? Is it giving the right answers? Can those who need to access it connect?
3. Don’t confuse things. Don’t run a recursive name server that is also the start of authority for a DNS zone. You really, and I mean really, need to separate these functions to different servers. If you don’t you are opening your zone to a very high level of risk.
4. Check your DNS server version. Make sure you are running the latest version of you DNS server software. This is imperative.
5. OS updates are critical as well. Make sure you keep your system up-to-date!
6. Run only DNS on your DNS server. You can run other software but you then have to be concerned that periodic (required) updates to your DNS software could impact other parts of that server. So the less you are running on that server the less risk. Just an idea.
7. Never have only one DNS server. You absolutely need two resolver servers and two SOA servers, at a minimum.
8. Try to have your SOA DNS servers on different networks with different paths to the Internet. If you do this and one of your networks goes down people will still be able to resolve your zone.
9. Backups. Right now - go and do a dry run to restore your DNS server. If you are thinking, “boy, how do I do that?” you should panic. You don’t want to ask that question when it really fails. Get your ducks in a row right now.
10. Replace older hardware. The nature of hardware is that it fails. Proactively plan for replacement of your DNS server.

So please take a few minutes and at least think through each of these issues. DNS will always be an attack target. DNSstuff can help with robust tools and proactive alerts that verify configuration and assist with troubleshooting and resolution. Having DNSstuff’s web application at your fingertips is a must for IT professionals.

Comment (0)

This is a test

Comment (0)