Excerpt
New Referral Behavior

When queried for an existing A or AAAA record serving as glue (an address record at or below NS records at a delegation point), the authoritative name servers for .com and .net respond with the glue record in the answer section. However, the answer is not marked authoritative, i.e., the AA bit is not set. While this behavior conforms to the DNS standards, recent authoritative servers do not respond this way. Instead, when queried for a name at or below a delegation point, recent authoritative servers respond with a referral to the delegated zone. This behavior is also supported by the DNS standards. More info

My take on this:
This will effect people who fail to properly create a glue record with the registry. I have seen people setup A records to point to company X nameservers ips. Well this is not going to fly anymore, you will need to properly setup the nameservers with the registry.

DNS Cycle:
A users request a domain name > This request goes to the root servers first> the root server will now only return the NS record without the A record > **Referral to the actual nameservers for the domain ** > The actual nameserver will return the A record for the domain > the user is then directed to the hosting server.

Current cycles :

The root nameserver were returning the A record for the nameserver. So it was actually doing query on the assigned nameservers for the requested domain. This added a few miliseconds to the users request for the web content. By eliminating this cycle should increase the response time.

I used yahoo.com as an example of what a domain request looks like
*** this is returns the nameservers from the root server *****
;; Received 499 bytes from 192.36.148.17#53(I.ROOT-SERVERS.NET) in 219 ms

yahoo.com. 172800 IN NS ns1.yahoo.com.
yahoo.com. 172800 IN NS ns2.yahoo.com.
yahoo.com. 172800 IN NS ns3.yahoo.com.
yahoo.com. 172800 IN NS ns4.yahoo.com.
yahoo.com. 172800 IN NS ns5.yahoo.com.
;; Received 197 bytes from 192.54.112.30#53(h.gtld-servers.net) in 124 ms

*the nameservers are then queried for the A record for yahoo.com. as you can see they have their servers load balanced for failover. *Multiple ips were returned for their A records *

yahoo.com. 21600 IN A 209.131.36.159
yahoo.com. 21600 IN A 209.191.93.53
yahoo.com. 21600 IN A 209.191.122.70
yahoo.com. 21600 IN A 67.195.160.76
yahoo.com. 21600 IN A 69.147.114.224
yahoo.com. 21600 IN A 69.147.125.65
yahoo.com. 21600 IN A 72.30.2.43
yahoo.com. 21600 IN A 98.137.149.56
yahoo.com. 172800 IN NS ns8.yahoo.com.
yahoo.com. 172800 IN NS ns6.yahoo.com.
yahoo.com. 172800 IN NS ns3.yahoo.com.
yahoo.com. 172800 IN NS ns2.yahoo.com.
yahoo.com. 172800 IN NS ns5.yahoo.com.
yahoo.com. 172800 IN NS ns4.yahoo.com.
yahoo.com. 172800 IN NS ns1.yahoo.com.
;; Received 393 bytes from 68.180.131.16#53(ns1.yahoo.com) in 1 ms

Fast DNS response within 1ms , good job yahoo

dig com. ns

DNS Root Servers
274683 IN NS I.ROOT-SERVERS.NET.
. 274683 IN NS J.ROOT-SERVERS.NET.
. 274683 IN NS K.ROOT-SERVERS.NET.
. 274683 IN NS L.ROOT-SERVERS.NET.
. 274683 IN NS M.ROOT-SERVERS.NET.
. 274683 IN NS A.ROOT-SERVERS.NET.
. 274683 IN NS B.ROOT-SERVERS.NET.
. 274683 IN NS C.ROOT-SERVERS.NET.
. 274683 IN NS D.ROOT-SERVERS.NET.
. 274683 IN NS E.ROOT-SERVERS.NET.
. 274683 IN NS F.ROOT-SERVERS.NET.
. 274683 IN NS G.ROOT-SERVERS.NET.
. 274683 IN NS H.ROOT-SERVERS.NET.

===================================

Query root servers for namserver information
=================

dig a.gtld-servers.net domain.com -t ns

or
nslookup
#server a.gtld-servers.ne
#domainname.com

=============

Note the root server only store information about the nameservers that the domain is currently pointed to. The nameservers then point to the dns server that host the dns zone file.
Reference Dig command

reference : http://support.microsoft.com/kb/922120

This problem occurs if the Link-Layer Topology Discovery (LLTD) Responder component is not installed on the Windows XP-based computer.

Network Map in Windows Vista makes network diagrams of the connections between network devices that can be used to troubleshoot connectivity problems. Network Map uses a discovery protocol called Link-Layer Topology Discovery (LLTD) that queries other devices on the network to determine how the network is organized.

Windows Vista includes the software components that implement the LLTD protocol. For other devices on the network to be displayed on the map, they must enable a discovery protocol that can respond to the mapping requests from the Windows Vista-based computer.

Solution:

To resolve this problem, install the update that is described in this section. The update installs the LLTD Responder component on Windows XP-based computers. The following file is available for download from the Microsoft download center:

Download the Windows XP package now.

Download Putty and Run
Type in the IP of Linux box or other SSH server you have access to and make sure the port is correct too
Under the tab “Connection –> SSH –> Tunnel” set a local source port *preferrably random number above 1024*
Under destination choose “Dynamic” and “Auto“
Then click open
Open IE or Firefox and find the proxy configuartion
Set your localhost as the SOCKS proxy server and the port is the local source port you choose on Step 3
NOTE: On Firefox choose SOCKS v5, and on IE include “localhost, 127.0.0.1? as the addresses exempted by the proxy