Please help by providing comments/ideas for improvement/thanks/death-threats in the comments section below.  Ok, maybe not the death-threats.

Download and License

The current version of this script is v1.03, released under the GPL license.  Click here to download it.


This software is licensed under the CC-GNU GPL version 2.0 or later.

What it can do/Features:

• Keep track of changes (IP addresses, status: existent/gone) to a list of specified domains
• Resolve many many many domains into a greppable format for you!
• Multithreaded in Python
• Does logging to a logfile, and to console at the same time
• Configurable to a certain extent

How to get and use:

• Install the PyDNS library found in the Python Package Index, hosted at SourceForge
• Grab a copy from the download section above and extract the script out
• Configure the script if you need to (see below)
• Create a text file named dns-list.txt in the same folder as the dns_tracker.py script, list the DNS hosts that you want to track in the dns-list.txt file, one host per line
• Run the script from command line: python dns_tracker.py.  The log file written to would be called dns-track.log
• Profit!
• You can stop the script by pressing Ctrl-C in the console ONCE.  It will attempt to kill off the waiting threads and exit gracefully.

What you can configure:

• All the editable options are in the section marked ##Editable options.  Some of the options are...
• Use system configured resolvers: set 'use_server': False,
• Use a DNS resolver of your choice: set 'use_server': True, and also 'server': '<your resolver>',
• The logfile name can be changed too 'logfile': 'dns-track.log',

Changelog:

• v1.03 (15 Aug 2010)

fixed logging hierarchy!  now we can control console and file log levels!

• v1.02 (10 Aug 2010)

added SERVFAIL to recognise as possible status

changed DNS resolving fail behaviour: retry 1min later

changed monitoring start behaviour (faster by using threads)

orphaned threads will also stop themselves if the main thread's killed

• v1.01 (3 Aug 2010)

demarcated editable options section ("##Editable options")

changed logging to append instead of overwriting existing log

remember that CNAMEs are also extracted for comparison of changes

added in minimum delay checks to account for CNAMEs' TTL being 0

adjusted logging levels for logfile, console still outputs everything

• v1.00 (2 Aug 2010)

initial release!

TODO:

• Perhaps migrating configurable options out to command line parameters
  or a separate config file?

import DNS
DNS.DiscoverNameServers()
reqobj = DNS.Request(name="blog.rayfoo.info")
resp = reqobj.req()

for i in resp.answers: print i
...
{'name': 'blog.rayfoo.info', 'data': '74.207.229.183',
'typename': 'A', 'classstr': 'IN', 'ttl': 1790, 'type': 1,
'class': 1, 'rdlength': 4}

resp.show();
PDG.py 1.0 - blog.rayfoo.info 1
;; options: recurs
;; got answer:
;; -HEADER- opcode 0, status NOERROR, id 60299
;; flags: qr rd ra; Ques: 1, Ans: 1, Auth: 0, Addit: 0
;; QUESTIONS:
;;      blog.rayfoo.info, type = A, class = IN

;; ANSWERS:
blog.rayfoo.info        1790    A       74.207.229.183

;; AUTHORITY RECORDS:

;; ADDITIONAL RECORDS:

;; Total query time: 367 msec
;; To SERVER: <sanitized>
;; WHEN: Sat Jul 31 11:06:24 2010

>>> resp.args
{'protocol': 'udp', 'name': 'blog.rayfoo.info',
'server': 'sanitized', 'rd': 1, 'opcode': 0,
'timeout': 30, 'timing': 1, 'elapsed': 367.52486228942871,
'qtype': 1, 'port': 53}

Taking a search through Ubuntu's APT system, to see whether any IDN related tools are available...

$ apt-cache search punycode

libidn11 - GNU Libidn library, implementation of IETF IDN specifications
libidn11-dev - Development files for GNU Libidn, an IDN library
idn - Command line and Emacs interface to GNU Libidn
libidn11-java - Java port of the GNU Libidn library, an IDN implementation
libidna-punycode-perl - encodes Unicode string in Punycode

There's the idn package!  Which allows encoding of IDNs in punycode in the command line...

Doing an install...

$ sudo apt-get install idn -y

And trying it out!

$ idn правительство.рф

libidn 1.15
Copyright 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Simon Josefsson.
GNU Libidn comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Libidn under the terms of
the GNU Lesser General Public License.  For more information
about these matters, see the file named COPYING.LIB.
xn--80aealotwbjpid2k.xn--p1ai

And resolving the domain...

$ nslookup xn--80aealotwbjpid2k.xn--p1ai

Non-authoritative answer:
Name:	xn--80aealotwbjpid2k.xn--p1ai
Address: 95.173.135.62

Note that resolving the domain directly results in rubbish!

$ nslookup правительство.рф

Non-authoritative answer:
Name:	\208\191\209\128\208\176\208\178\208\184\209\130\208\181\208\187\209\140\209\129\209\130\208\178\208\190.\209\128\209\132
Address: 67.215.65.132

So, basically from this we understand that applications will need to use the punycode encoded version of the IDN, NOT the original IDN, when resolving.  And there're tools out there already can do that for us.

Since Ubuntu has these packages, Debian would also have the corresponding packages available too.

SecureMe is a project I started to try out and get some experience from running an operational combination like this, and I have been using it without much issues for the past quarter year to date.

I'm opening this as a service to people who'd like to make use of this service too, and for no minimum cost! I only ask for the following:
1. feedback/suggestions/complaints/compliments!
2. (if you're feeling generous) donations to help me upkeep my server at least (I don't intend to strike it rich with this anyway)

If you wish to use this, email me at secureme{@T}rayfoo[dot]info to enquire on availability. Alternatively you could tweet or FB me...

I'll support this as much as possible where time/resources permits, but for now I'd suggest that (at least) the slightly more technically inclined try this.

A short review on the different parts of this system so far...

1. Automatic starting

The OpenVPN client installed can be made to autostart and run as a background service, (re-)connecting to the VPN automatically whenever there's network connectivity to the OpenVPN server.  Coupled with automatic configuration of the client's DNS resolver list this allows for automatic protection/privacy of the DNS queries sent out.  The automatic configuration of the DNS resolver can be disabled too if need be.

2. Ease of use

Connecting to the proxy afterward is a "simple" proxy configuration change in the browser of choice.  This can be conveniently done (and undone) with extensions like Proxy Switchy! for Google Chrome, or FoxyProxy for Firefox.

3. Initial setup efforts needed

All this is working nice and dandy for me now, with little inconvenience involved in activating SecureMe. Now one of the problems faced in making this user-friendly/"idiot-proof" would be the high setup efforts needed (really plenty of hoops to jump through, especially for the no-so-technically-inclined user).  One way would be to come up with some sort of "portable" package that has been preconfigured as much as possible, or an installer that helps you to do most of the work.

4. DNS requests leakage

Another issue is the small possibility of DNS request leaks.  For example, the behaviour of the OpenVPN client in linux is to add the DNS resolver at the top of the resolver list (/etc/resolv.conf), but if the DNS query is deemed to take "too long", the request goes out to the next DNS resolver in the list, which usually is the DNS resolver for the public wifi hotspot.  Though this won't cause things to break, it does allow some queries to go out in the open network.  One of the ways I know of to solve this would be to configure a SOCKS proxy, so that it would be possible for browsers like Firefox to send all DNS queries to the SOCKS proxy.

Conclusion:

This seems to be working well so far, with Linode's rare downtime the past months.  More work could be done to make this simpler for others to setup, but I guess I will only do this sparingly in my free time.  No one seems to be geeky/interested enough to want to have this available to them for free so far, heh. ]]> http://blog.rayfoo.info/2010/02/secureme-so-far/feed 0