Tag: dns

Posted on

Benchmarking DNS servers with Java

I’m currently in the process of moving our DNS over to another provider and I was curious as to whether the old or new provider offers faster lookups. dig shows query times, but I didn’t want to just run that over and over. I decided to write something to do this, in Java since I like Java. I found this post, which has the meat of the work done already. I also read some of Sun’s JNDI/DNS lookup info, which was pretty dense. All I want to do is specify the name server’s IP and do the lookup. I don’t even really care about the result, just how long the query takes.

The thing I wrote only looks up A records, but can easily be modified to do CNAMEs or whatever. Here’s how you call it:

$ java -jar DNSTester.jar 4.2.2.2 www.google.com 25
Resolved www.google.com to 74.125.235.19 against NS 4.2.2.2
Performed 25 lookups in 233.29 milliseconds.  Average 9.3316ms per lookup.

$ java -jar DNSTester.jar 8.8.4.4 www.google.com 25
Resolved www.google.com to 74.125.226.146 against NS 8.8.4.4
Performed 25 lookups in 450.034 milliseconds.  Average 18.00136ms per lookup.

Code is in github here. Jar is available here.

Posted on

Back on FiOS again (finally)

Well, that was quite an ordeal. But Verizon came today and finally installed FiOS. All’s well that ends well, I suppose. My phone number was finally ported over and the internet is insanely fast. This is 25/25 internet with my desktop Fedora box plugged into the TP-Link router which is then plugged into the FiOS ActionTec router. I didn’t want to have to reconnect all my computers to a new SSID so I’ll just continue using the TP-Link until I have a reason not to.

FiOS 25/25 Speed Test - May 20th, 2011
FiOS 25/25 Speed Test - May 20th, 2011

One thing I did right away was change my DNS servers. The default DNS servers with Verizon were 68.237.161.12 and 71.243.0.12. By default, Verizon uses “DNS assistance,” meaning that DNS queries against these servers will return IP addresses when they should return NXDOMAIN, so if you mistype the hostname in a URL it can direct you to a page full of ads. You can disable this by replacing the last octet of the default DNS IP with 14. So for the two IPs above, it would be 68.237.161.14 and 71.243.0.14. I figured I’d compare the response times of these servers with Google’s 8.8.8.8 and 8.8.4.4. I used dig to time DNS requests and also used ping to measure latency. 68.237.161.14 was the fastest for me, followed by 8.8.4.4 and then 71.243.0.14, so those are my primary, secondary, and tertiary DNS servers.

Posted on

Going back to FiOS

I’m not sure why these guys operate this way – they’re more than happy to lose me as a customer and then throw huge discounts at me to get me back. If they’d just give me a good price I’d love not to have to go through this rigmarole. But after being with Cablevision for 2 months I checked Verizon’s pricing and it beat my current deal with Cablevision.

FiOS digital voice with number ported for free; 25/25 Mbps internet; HMDVR free “forever” plus a second HD STB, Showtime, Movie Channel and Flix. Since I already had the battery thing installed last time I had FiOS they gave me a fair discount. Basically the whole package for $87/month + tax, price locked for 2 years, no contract. Not as great of a deal as I’d had with FiOS originally, but it’s pretty good, and FiOS’s service is definitely better than Cablevision’s. I’ve heard Cablevision was rolling out their “DVR plus” service with all programs recorded “in the cloud” rather than on the actual box, but it’s been two months and I haven’t heard of it coming to Long Island. So basically 2 years later Cablevision’s service is exactly the same while Verizon has iPhone apps to control the DVR and use the phone as a remote, plus DVR that’s much faster and just generally better service.

On a side note, I noticed tonight I was having problems trying to stream Netflix to my Wii. I tried loading netflix.com on my laptop and that also didn’t work, it said “couldn’t find server movies.netflix.com.” I tested this via dig on my linux box and sure enough, movies.netflix.com isn’t resolving against the default Cablevision nameserver (167.206.3.206) – getting a SERVFAIL:

[evan@lunix ~]$ dig movies.netflix.com

; <> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <> movies.netflix.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17569
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;movies.netflix.com.            IN      A

;; ANSWER SECTION:
movies.netflix.com.     232     IN      CNAME   merchweb-frontend-1502974957.us-east-1.elb.amazonaws.com.

;; Query time: 2129 msec
;; SERVER: 167.206.3.206#53(167.206.3.206)
;; WHEN: Sun Apr 24 01:23:58 2011
;; MSG SIZE  rcvd: 103

I tried the same query against Google’s nameserver (8.8.8.8) and it resolves correctly:

[evan@lunix ~]$ dig movies.netflix.com @8.8.8.8

; <> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <> movies.netflix.com @8.8.8.8
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43718
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;movies.netflix.com.            IN      A

;; ANSWER SECTION:
movies.netflix.com.     300     IN      CNAME   merchweb-frontend-1502974957.us-east-1.elb.amazonaws.com.
merchweb-frontend-1502974957.us-east-1.elb.amazonaws.com. 39 IN A 174.129.220.6

;; Query time: 34 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Apr 24 01:37:26 2011
;; MSG SIZE  rcvd: 119

I set my router to resolve against 8.8.8.8 rather than whatever Cablevision provides and now it works. I’m not sure if this is related to the big EC2 disaster of the past few days but it looks more like Cablevision’s fault than Amazon’s or Netflix’s.

Posted on

Outlook 2007 & Exchange 2010 Autodiscover SSL certificate error annoyance

One of the more annoying side effects of migrating my mailbox to Exchange 2010 has been the nagging of Outlook 2007’s Autodiscovery feature. Now, every time I start Outlook I get hit with a certificate error for autodiscover.domain.com. Now, autodiscover.domain.com is a CNAME to mail.domain.com, which is the OWA URL for the CAS. The SSL certificate is valid – but it’s valid for mail.domain.com. I could buy a SSL certificate from GoDaddy for $12.99 (an insanely great price, btw) for “autodiscover” but that would also require using another IP address on the CAS (since you can can only bind one SSL certificate to an IP:port pair), and that seems like a waste of an IP address.

I found a possible solution in KB 940726. Basically you use this cmdlet to change the Autodiscover URI for internal clients:

Set-ClientAccessServer –AutodiscoverServiceInternalUri https://mail.contoso.com/autodiscover/autodiscover.xml

You’d replace mail.contoso.com with the external URL of your OWA server (in my case, mail.domain.com). I’ve made the changes but I think I need to wait for AD propagation. Hopefully this will resolve it, because I don’t want to move everyone’s mailboxes over until this thing is “perfect,” whatever that means.

Edit: I also needed to add a SRV record so Outlook would know what host to check for autodiscovery when outside the domain.

Edit 2:: Also need to install a hotfix or be running Outlook 2007 SP1 or later for the SRV functionality.

Edit 3: It occurs to me that a simpler fix for this issue may be simply to delete the DNS record for autodiscover entirely. That way, when Outlook attempts to open the SSL connection to autodiscover.domain.com, it gets a NXDOMAIN error (should) silently skip it. Unfortunately we have wildcard DNS active for our domain.

Other useful resources: