Wednesday, March 28, 2012

Performing NAPTR queries on Windows

While testing out my PowerDNS setup, which I blogged about yesterday I discovered that nslookup can not perform NAPTR queries.I poked around for a while to see what I was doing wrong, however it seems that even though Windows Server supports supplying NAPTR responses to DNS nslookup can not perform this query. (Yeah this seems odd to me as well.)

Thankfully I found this easy to use port of dig for Windows and within 30 seconds of downloading it I was performing successful NAPTR queries from my windows box. It is worth grabbing if you need anything beyond simple DNS queries on your windows box.

Tuesday, March 27, 2012

Setting up PowerDNS for ENUM

I have a few installations coming up that are going to be using ENUM for call routing. ENUM is a form of DNS that allows mapping of telephone numbers to URIs. While I understand the idea behind ENUM and how it works in a basic sense I wanted to get some hands on experience. So with that in mind I decided to set-up PowerDNS. I built mine within a VM running Cent OS but it can easily run on any version of *nix.

There are heaps of guides out there on how to set it up and I ended up using a combination including this one. Now, I didn't end up installing PowerAdmin as really it seemed like overkill in my case so I just stopped at step 3. Now all that is left is to add ENUM records into the database. These are simply standard NAPTR records with the correct format for ENUM which is specified in RFC 2916. I followed the instructions here, mainly because SQL is something that I can never seem to remember after a few days. 

Obviously I wanted to check that I had everything set-up by performing some queries. In my case local queries worked fine but I had some troubles with remote queries, I was getting no response. Stopping iptables sorted this out for me, obviously in a more permanent machine you would want to open up the firewall not remove it completely. Finally, while nslookup worked great for normal DNS queries it couldn't perform NAPTR queries so I had to turn to a windows port of dig, which can be found here.

Wednesday, March 21, 2012

Wifi Roaming

Some of you may have read my post a week or so ago entitled Wifi is too Fiddly. Well, according to this press release on Engadget it seems that the GSMA and WBA agree with me. It is nice to feel vindicated.

Essentially they are proposing that SIM based authentication could be utilised to connect to WiFi access points. Thus your mobile service provider could setup some access points in areas where there is very high data usage and shift users onto this, thus freeing up the radio network for voice traffic and users outside the wireless range. Areas like airports and train stations immediately spring to mind for this type of hand off.

Tuesday, March 20, 2012

No battery backup of NBN data connection

I'm not sure if everyone out there is following the National Broadband Network (NBN) as closely as I am, so I thought I should point out one small snippet that I know a lot of people are missing. In fact, it was only recently confirmed for me when reading the NBN blog yesterday.

The UNI-D port will not have battery backup.

This means of course during a power outage you'll lose your internet connection. If you do opt for the battery backup option it will only back up voice services connected via the UNI-V port (up to 5 hours of talk time is the stated backup). Now, initially this struck me as quite a silly option, however on second thoughts it does make some sense. I can't imagine too many people will be connecting to the NBN with an ethernet cable and a laptop. Most will use some form of router, most likely with wireless. This of course would also require some form of battery backup. So really if people want to ensure their internet connection (and any voice services delivered over the UNI-D port) they'll need a UPS providing backup to the NBN CPE and their router.

Saturday, March 3, 2012

Wifi is too fiddly...

I have to travel a fair bit for work and hence waste a bit of time connecting to various wireless networks hotels, offices etc.

If everything goes smoothly then typically the steps are something like this:
  1. What's the name of the wireless network?
  2. The password is "ASDAHSDknaksdnaskjdnSAdasdasdaslkdj" great thanks.
  3. Re type password.
  4. Re type password
  5. Re type password
  6. Connect to wireless.
  7. Wait 30 seconds for IP address to be assigned and to get actual internet connection.
More typically in hotels etc you have no security and a web landing page that you have to answer some questions on, so it goes something like this.
  1. Find wireless network "AwesomeHotelWifi" "Free Airport Wifi"
  2. Open browser and try to go to random page (better not be a https page though).
  3. Repeat for ~45 seconds until login page appears. (Or alternatively when you have opened your browser all of your saved tabs have reloaded and gone to the network landing page that doesn't have working redirect after logging in.)
  4. Enter details
  5. View cheesy ad/sign life away
  6. Get disconnected after ten minutes for no apparent reason.

A recent post on BuddeBlog got me thinking that there has to be a better way of connecting to wifi networks that would make them more widely used, trusted and less frustrating. The main idea is a better way of communicating the connection information or rather a method that allows most of the above steps to be automated.

I've seen a couple of applications, like Wifi Joiner, that have basically nailed the connecting to private network problem.  Wifi Joiner lets you create QR codes with network connection information and then others to scan it to connect, no need to enter pesky passwords. While this is a great idea I think to be successful we need to see it expanded initially to other smart phones (I'm looking at you here Apple) and secondly into desktops via a little config utility. In addition, beyond just carrying the bare bones network information it could also contain account details etc so that your login can be personalise and automated. Obviously you would need to have the data on the laptop initially for it to be useful but consider this.
  1. You book at a new hotel overseas that has internet over wifi.
  2. Hotel sends a confirmation email containing a config file/text string that contains all the information needed to connect to the network.
  3. You check in, sit down in your room open your laptop and run the network utility.
  4. It connects to the correct network, logs into the access control system and connects you to the internet in one step.
I would also like to see more advanced routing in mobile phones, so that I can go to a dedicated site over wifi connection but maintain the rest of my connections over my mobile data link. Think of the uses, you are in a shopping centre and the store is giving you discounts if you use their app or similar. Or you would like to be able to look at the directory for the centre to find a particular store. In this case the centre would like to provide you access to a certain webpage but nothing else. So you scan a QR code in the store, automagically connect to their network and this adds a route so that you can hit their server over the wifi, but everything else stays on your data connection.

Obviously there are some security implications that need to be worked out for these scenarios and I can't profess to have thought of all the attack vectors and problems with the new approaches. (Now that I work from home I don't have anyone technical to bounce my ideas off before posting.)