Tag Archives: linux

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.

Using grep to Exclude Lines Containing Certain Characters/Text

I like to watch Apache log files using tail -f but they often get filled up with data I don’t want/need to see – like, when I access the web site.

grep is a great tool to search for certain information in text files – but it can also exclude certain pieces of information which can be equally as useful.

So, for example, if I want to watch a log file using tail -f, but exclude any information relating to the IP address “192.168.1.101” then we can use the grep -v switch:

tail -f access.log | grep -v "192.168.1.101"

What this will do is show everything, apart from a line with that IP address in.

Of course, this works with any other command with text being piped into grep:

cat file.txt | grep -v "heh"

This would output the contents of file.txt but remove any lines with “heh” in them.

You can find out more about the various grep options in it’s man page (man grep from the command line)

Kill a GNU Screen Session from the Command Line

This article is about GNU Screen – you can read about GNU Screen here: http://www.gnu.org/software/screen/

There may be times when you have multiple, or even a single, screen session which you want to kill without attaching to it and ending it as you normally would.

You can kill a screen session using the session ID or the name (if the name is unique enough).

Warning: Both ways end all processes within the screen session, so if you have any open files/applications, make sure you don’t need/want them – they’ll be kill’d along with the session.

Killing by session ID

First, run screen -list to get the id of the current sessions (we use the id to kill the screen session)

daz@scampi:~$ screen -list
There are screens on:
11493.irssi     (04/01/10 16:25:44)     (Detached)
30784.newapps   (01/01/10 19:42:38)     (Detached)

As you can see in this example, I have two sessions, a session called “irssi” with id 11493, and a session called “newapps”, with an id of 30784.

So, to kill the “newapps” session, I’d run:

daz@scampi:~$ screen -X -S 30784 kill
daz@scampi:~$

.. and the session will now be gone.  You can verify that by running screen -list again.

Killing by session name

If your screen session name is unique enough (for example, if you have one called “newapps” and another called “irssi” as per my example) you can kill by name:

daz@scampi:~$ screen -X -S newapps kill
daz@scampi:~$

The reason I say unique enough –  if you have a session called “newapps” and one called “newapps1”, you will need to use the ID to end “newapps” before “newapps1” – you’ll simply be asked to specify the session again otherwise.