Monthly Archives: July 2008

More fun with DNS packet captures

Following my last post on DNS query port usage, here are some more interesting DNS graphs.

The following graphs are based on a packet capture taken from the network interface of a recursive DNS server. This DNS server is one of the primary recursive DNS servers for a small Internet service provider. The capture includes all UDP DNS traffic to the DNS server as well as UDP DNS traffic from the DNS server to addresses within the local AS.

/usr/sbin/capinfos local.pcap
File name: local.pcap
File type: Wireshark/tcpdump/... - libpcap
File encapsulation: Ethernet
Number of packets: 200000
File size: 30702100 bytes
Data size: 27502076 bytes
Capture duration: 2659.328827 seconds
Start time: Sat Jul 26 01:45:31 2008
End time: Sat Jul 26 02:29:50 2008
Data rate: 10341.74 bytes/s
Data rate: 82733.89 bits/s
Average packet size: 137.51 bytes
Scatter plot of DNS query source ports

Scatter plot of DNS query source ports

DNS query UDP port usage histogram

DNS query UDP port usage histogram

Scatter plot of DNS query response time

Scatter plot of DNS query response time

Scatter plot of failed DNS query response time

Scatter plot of failed DNS query response time

Scatter plot of successful DNS query response time

Scatter plot of successful DNS query response time

DNS queries by type

DNS queries by type

DNS query response time

DNS query response time

Failed DNS query response time

Failed DNS query response time

Successful DNS query response time

Successful DNS query response time

IP packet size histogram

IP packet size histogram

DNS query UDP source port graphs

Recently Dan Kaminsky announced a new DNS vulnerability. This isn’t a vulnerability in a particular DNS implementation but a problem with the DNS protocol itself. You can find information from CERT here. The exact details of the vulnerability were kept quiet even after DNS software vendors simultaneouslly released patches to mitigate the problem. One of the main changes made by these patches was to increase the number of source ports used for outgoing queries to other DNS servers. From this information it was wildly speculated that the vulnerability is related to cache poisoning.

Perhaps partly due to an accidental, early release of information the full vulnerability details are now available.

I happened to have some DNS captures available from before and after the patch was applied so I thought it might be interesting to graph the UDP query port usage behaviour for before and after the patch. The graphs presented below come from a RHEL 5.2 based DNS server. The post-patch DNS server version is bind-9.3.4-6.0.2.P1.el5_2. I don’t have the pre-patch version number handy but presumably it is the previous Bind package released by RedHat. Both of the captures came from the same DNS server but note that the capture length is different.

The difference is quite dramatic. Bind appears to be making good use of almost the entire port space.

DNS server source UDP query port usage before patch

DNS server source UDP query port usage before patch

DNS server UDP query port usage after patch

DNS server source UDP query port usage after patch

Also note the interesting banding in the second graph. This behavior is not limited to the new patch. I have noticed this in other pre-patch captures as well. More on that later.

Search Engine on CBC

This probably isn’t news to many people by now but CBC’s Search Engine will not be returning in the fall. What a loss. To me Search Engine is a great example of what a radio show and Podcast can be. The show had strong audience participation and felt almost more like a blog post than a traditional radio show. More importantly, Search Engine covered digital issues such as Copyright reform in a way that is greatly needed at this time.

I really hope that CBC will reconsider this cancellation. Public broadcasters need to bring in young people and new listeners. A new and experimental format like Search Engine is a great way to accomplish this. The huge amount of interest in this spring’s Copyright reform bill shows that many Canadians are becoming aware of the topics Search Engine covered. Now is not the time to give up on this show.

Fortunately it looks like Search Engine’s sister show, Spark, is still going to continue.