The Security Skeptic

WebProNews reporter Jason Lee Miller does an admirable job of characterizing the debate over the existence or non-existence of domain name front running in his article, Domain Frontrunning: A Ghost In The Machine. I like this guy. He did his homework to the point of getting the chronology of events as well as the meat of the matter correct. In particular, he honed in on several of the most important statements from the SSAC report on Domain Name Front Running by emphasizing that the SSAC found no evidence of frontrunning in the 120 complaints submitted and SSAC doesn't say that front running doesn't happen, only that SSAC could find no evidence that it did among those 120 complaints. He accurately reported counter-statements by Jon Nevett that domain name front running does exist, that Network Solutions had evidence to prove it, and that confidentiality agreements with client prevented him from disclosing details. He also obtained some very sharply worded quotes from Jay Daley, author of a Nominet position paper debunking the existence of front running, who challenged Nevett's claims and insisted on seeing the data. Read the article, and expect to read more on this topic here in the future. SSAC didn't find a smoking gun among the 120 claims submitted by Internet users, but as a long-time X-files fan, I'll leave you with, "The truth is out there... somewhere."

Archived at http://www.securityskeptic.com/arc20080201.htm#BlogID674 by Dave Piscitello  

In BlogID 671, I mention that a simple NS query on any root name server will confirm that IANA has included IPv6 addresses of 6 authoritative root name servers in the hints and root zone files. The simple "dig" example I gave will only return as many complete resource records as the root name server can fit into an RFC 1035 compliant, UDP-encapsulated DNS response. If you want to see all the resource records for all the root name servers, you must tell dig to advertise a larger receive buffer size by signaling Extended DNS (EDNS0) support, as follows:

 c:\dig +bufsize=1024  @a.root-servers.net NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 20
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	NS
;; ANSWER SECTION:
.			518400	IN	NS	M.ROOT-SERVERS.NET.
.			518400	IN	NS	A.ROOT-SERVERS.NET.
.			518400	IN	NS	B.ROOT-SERVERS.NET.
.			518400	IN	NS	C.ROOT-SERVERS.NET.
.			518400	IN	NS	D.ROOT-SERVERS.NET.
.			518400	IN	NS	E.ROOT-SERVERS.NET.
.			518400	IN	NS	F.ROOT-SERVERS.NET.
.			518400	IN	NS	G.ROOT-SERVERS.NET.
.			518400	IN	NS	H.ROOT-SERVERS.NET.
.			518400	IN	NS	I.ROOT-SERVERS.NET.
.			518400	IN	NS	J.ROOT-SERVERS.NET.
.			518400	IN	NS	K.ROOT-SERVERS.NET.
.			518400	IN	NS	L.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET.	3600000	IN	A	198.41.0.4
A.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:503:ba3e::2:30
B.ROOT-SERVERS.NET.	3600000	IN	A	192.228.79.201
C.ROOT-SERVERS.NET.	3600000	IN	A	192.33.4.12
D.ROOT-SERVERS.NET.	3600000	IN	A	128.8.10.90
E.ROOT-SERVERS.NET.	3600000	IN	A	192.203.230.10
F.ROOT-SERVERS.NET.	3600000	IN	A	192.5.5.241
F.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:500:2f::f
G.ROOT-SERVERS.NET.	3600000	IN	A	192.112.36.4
H.ROOT-SERVERS.NET.	3600000	IN	A	128.63.2.53
H.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:500:1::803f:235
I.ROOT-SERVERS.NET.	3600000	IN	A	192.36.148.17
J.ROOT-SERVERS.NET.	3600000	IN	A	192.58.128.30
J.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:503:c27::2:30
K.ROOT-SERVERS.NET.	3600000	IN	A	193.0.14.129
K.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:7fd::1
L.ROOT-SERVERS.NET.	3600000	IN	A	199.7.83.42
M.ROOT-SERVERS.NET.	3600000	IN	A	202.12.27.33
M.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:dc3::35
;; Query time: 78 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Mon Feb 11 14:57:13 2008
;; MSG SIZE  rcvd: 615

If you don't specify EDNS0, not only will your answer be abbreviated, but it will differ depending on the root name server you query. Root name server operators use several software implementations, each has a preferred configuration, and these variations result in NS response messages being composed slightly differently. No worries, however: you will *always* get at least two AAAA resource records in an NS response.

If you want to see the differences, simply dig DNS to a.root-servers.net and b.root-servers.net - or dig them all!

Archived at http://www.securityskeptic.com/arc20080201.htm#BlogID673 by Dave Piscitello  

Who is Cary Duffy Marsan and why is she so interested in IPv6 when (apparently) few others are?

Cary Duffy Marsan is Senior Editor, Enterprise Applications for Network World magazine. Why she is interested in IPv6 is a mystery, but she has done some "responsible journalism" by publishing a series of articles on IPv4 address exhaustion (February 2008) and transition (switching) to IPv6 (December 2007). The February 2008 article, "Who's afraid of IPv4 address depletion? Apparently no one." has particularly dismal statistics from BT INS, who claim that only 1 in 3 service providers support IPv6 and 2 per cent of IT professionals have migrated their organizations to IPv6. Yes, two (2), and if that's a misprint, it's not mine.

Comments posted to both articles are predictable: NAT will save us. No, it will not. China will have IPv6, so it's well past time for the US to enter the addressing arms race. Sigh...

The December 2007 interview with Jim Bound, IPv6 guru, is not much help. Bound is quoted as saying, "There’s no one-size-fits-all transition plan. The first thing is to upgrade the infrastructure. You need to get your network plumbing in order so that IPv6 can co-exist and be interoperable with IPv4."

No "one-size-fits-all" transition plan? There's no plan, period, Jim. If "NAT will save us" is the war cry of the IPv6 averse part of the community, then "dual stack will save us" is the counter-cry of the IPv6 advocates who've left the hard nuts in deployment for someone else to crack. Dual stack frustrates me to no end. It's engineering hand-waving, blue-smoke and mirrors. It's interesting in the context of a core switching infrastructure but offers relatively little insight at the network edge, where many of us operate, and on endpoints, where nearly all of us live. Here's a tough nut to crack, folks: endpoints that have only IPv4 addressed interfaces will hang around for decades, and before they disappear entirely from the face of the addressable universe, the number of addressable *public* interfaces will exceed 2**32; in fact, you'll have endpoints with IPv6 only addressable interfaces long before then.

Everyone is worrying about address exhaustion, and this thinking is too narrow. Whether you think IPv4 address exhaustion is imminent or not, you better be thinking about ways you will accommodate *application* communications between IPv4 and IPv6 only hosts, not only for client-server applications but peer to peer as well, because apparently, few others are.

And while you're expanding your thinking regarding IPv4 and IPv6, think a bit more carefully about security. As my study of IPv6 firewall support among commercial firewalls suggests, few others are thinking about this issue as well.

Archived at http://www.securityskeptic.com/arc20080201.htm#BlogID671 by Dave Piscitello  

IANA has implemented the recommendations of ICANN's Security and Stability Advisory Committee (SAC 018) by adding AAAA records for six the thirteen listed authorities for the root zone.

An updated hints file is available from ftp://ftp.internic.net/domain/named.root.

A simple "dig NS" of one of the root name servers illustrates that IPv6 addresses for root name servers A, F, H, J, K and M will be returned, as follows:

 c:\dig  @a.root-servers.net NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION:
;.				IN	NS
;; ANSWER SECTION:
.			518400	IN	NS	M.ROOT-SERVERS.NET.
.			518400	IN	NS	A.ROOT-SERVERS.NET.
.			518400	IN	NS	B.ROOT-SERVERS.NET.
.			518400	IN	NS	C.ROOT-SERVERS.NET.
.			518400	IN	NS	D.ROOT-SERVERS.NET.
.			518400	IN	NS	E.ROOT-SERVERS.NET.
.			518400	IN	NS	F.ROOT-SERVERS.NET.
.			518400	IN	NS	G.ROOT-SERVERS.NET.
.			518400	IN	NS	H.ROOT-SERVERS.NET.
.			518400	IN	NS	I.ROOT-SERVERS.NET.
.			518400	IN	NS	J.ROOT-SERVERS.NET.
.			518400	IN	NS	K.ROOT-SERVERS.NET.
.			518400	IN	NS	L.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET.	3600000	IN	A	198.41.0.4
A.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:503:ba3e::2:30
B.ROOT-SERVERS.NET.	3600000	IN	A	192.228.79.201
C.ROOT-SERVERS.NET.	3600000	IN	A	192.33.4.12
D.ROOT-SERVERS.NET.	3600000	IN	A	128.8.10.90
E.ROOT-SERVERS.NET.	3600000	IN	A	192.203.230.10
F.ROOT-SERVERS.NET.	3600000	IN	A	192.5.5.241
F.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:500:2f::f
G.ROOT-SERVERS.NET.	3600000	IN	A	192.112.36.4
H.ROOT-SERVERS.NET.	3600000	IN	A	128.63.2.53
H.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:500:1::803f:235
I.ROOT-SERVERS.NET.	3600000	IN	A	192.36.148.17
J.ROOT-SERVERS.NET.	3600000	IN	A	192.58.128.30
J.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:503:c27::2:30
;; Query time: 78 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Mon Feb 11 12:07:40 2008
;; MSG SIZE  rcvd: 500

Grats to IANA for providing access to the root servers over IPv6 transport.

Archived at http://www.securityskeptic.com/arc20080201.htm#BlogID672 by Dave Piscitello  

ICANN's SSAC has published the results of its study and analysis of domain name front running. The report (SAC 024) reviews 120 claims submitted by Internet users following an Advisory SSAC issued in October 2007 where the committee defined domain name front running and identified the many ways one could (theoretically) obtain information about an Internet user's interest in a domain name and use that information to preemptively register the domain.

None of the claims provided sufficient information for SSAC to dismiss all other plausible explanations for the claimant's failure to register a desired name and conclude that a claim was indeed a case of domain name front running. While many Internet users may be disappointed by this finding, some may be comforted by the fact that SSAC determined that most of the claims were not acts of front running but rather of domain tasting, monetization, typo-squatting and speculation (resale). Bear in mind that SSAC's findings are based on a small sampling, and the results are important but neither prove nor disprove the existence of front running.

The results also demonstrate that front running is hard distinguish from other domain name market activities, and reveal that the Internet community doesn't fully understand the the complexities of the domain registration process and the domain name marketplace; specifically the report states, "Domain name kiting, front running, hijacking,monetization and tasting are not readily distinguishable to the average Internet user and the conclusion many users draw from the sum of these activities is that the (parties who comprise the) registration process is not trustworthy". SSAC recommends several actions for ICANN, registrars and resellers, principal among these is to help users better understand how the domain name registration process works how monetization and speculator (resale) markets influence domain names, and how the existence of secondary markets affects domain name availability.

Archived at http://www.securityskeptic.com/arc20080201.htm#BlogID670 by Dave Piscitello