Using dig to Query a Specific DNS Server (Name Server) Directly (Linux, BSD, OSX)

There may be occasions when you wish to query a DNS server directly.  I often do it before changing DNS servers for a domain; I’ll setup the new records on the new DNS servers, and then query them directly to ensure they are returning the correct records.

I recommend that anyone running DNS services for any domain looks into these commands – they’re very useful, especially when you’re making changes.

dig has a feature which allows you to specify a name server along with the record you want to query.

For example, one of the DNS servers for droptips.com is “ns.123-reg.co.uk”.  We can query this server directly, for the www record by doing the following:

$ dig droptips.com @ns.123-reg.co.uk

You’ll get some output with a section titled Answer Section:

;; ANSWER SECTION:
 droptips.com.       86400   IN      A       89.238.134.5

This details the result (89.238.134.5) and also the TTL for the record (in seconds).  The TTL is important, as this is how long caching DNS servers should cache the result for – in this case, 86400 seconds which is 1 day. Using this command to find out a TTL value for a particular record is also quite useful, especially if you’re investigating DNS cache issues.

You can also do the same to check other records such as MX records, by simpling adding the record type to the command.  For example, to get the MX records ns1.google.com is reporting for google.co.uk:

$ dig MX google.co.uk @ns1.google.com

… with the results:

;; ANSWER SECTION:
 google.co.uk.           10800   IN      MX      10 google.com.s9a2.psmtp.com.
 google.co.uk.           10800   IN      MX      10 google.com.s9b1.psmtp.com.
 google.co.uk.           10800   IN      MX      10 google.com.s9b2.psmtp.com.
 google.co.uk.           10800   IN      MX      10 google.com.s9a1.psmtp.com.

You can see in this instance, that the TTL is 10800 seconds which is 3 hours, and all MX records have the same priority level of 10.

iPhone Data Usage: My Average Monthly Data Usage

Here in the UK, mobile operators include different amounts of data with the iPhone data tarrifs – some even offer unlimited (with fair use making them not unlimited at all).  Check the terms very closely, to know exactly how much data is included with your tariff on a monthly basis.

I bought an iPhone 3GS just under a year ago (20th June 2009) and my data usage in that time has been just 908MB, sent and received.  That’s not much.  I do use WiFi when at home, though.

I have an Exchange push account (with quite a bit of mail flow), random other push apps, I use the browser quite a bit when out and about, I use the maps, and I send a fair few e-mails, often including pictures etc.  I’d say my use is fairly typical.

My average data use (none-WiFi data) a month is 75MB.  So, even if you doubled the use, it’s still only 150MB.  You could say you use data on your iPhone five times as much as me, and it’s still only 375MB a month!

The allowances are often quite high (for a phone) – I’d be surprised if you hit the limit (at time of this post) offered by the mobile companies, certainly in the UK, unless you’re tethering it and using it as a modem, or constantly streaming video such as YouTube etc.

What’s your data usage?  Let me know in comments below!

iPhone Data Usage
iPhone Data Usage

When Did You Last Reboot Your Microsoft Windows 7 Machine? (Check Uptime)

Finding out when you last rebooted your Windows 7 machine can be completed using the “systeminfo” command.

Open a Command Prompt by going to Start and opening “cmd”. You will then be presented with a command prompt window, where you need to type the systeminfo command below:

C:\> systeminfo | find "System Boot Time"
System Boot Time:          05/06/2010, 12:55:07

You will then be shown the date and time the server was booted (as seen in the example above).

You can just run “systeminfo” on it’s own (with no ‘| find “System Boot Time”‘), and you will be presented with a lot of other information such as Hotfixes, Network Connections, etc.