Spam Wars: The Battle History
Appendix A: Tracing Evasion Techniques
Using an HTTP redirection to load hidden nameservers.
During a basic HTTP redirection the DNS resolver looks up the domain name and requests a page. It receives back a 'try other there' response, and repeats the procedure.
A Standard HTTP redirection: Resolver queries root DNS server for the NS for that domain
This exploit discovered in use by spammers late 2004 exploits the DNS cache architecture to change the nameservers (NS) of the domain to different names during the process of a domain request. These secondary names may not be registered in the DNS system and when looked up may appear not to exist. Requires knowledge of the Domain Name System and Caching Techniques.
When a domain name is looked up in DNS, the resolver checks its local cache first and then asks its 'parent' where the domain is. If none of the chain of servers have a copy of the domain location they eventually ask the DNS Root Servers. The Root Servers respond with the final Domain Exists or Not and who to contact if they do. After the contact NS is found the resolver requests the domain location from it.
Can a redirection switch the nameservers used?
Example:
Domain: domain.com
Spamvertized host: H1.domain.com
The root servers list NS.server1.com
as the nameserver for domain.com and
provide an address record ADDRESS1
(the glue record).
Resolving the spamvertized hostname,
H1.domain.com, one goes to the root servers,
finds the nameserver record (non-authoritative)
and its address (the "glue" record) and queries
QUERY: ADDRESS1 <-- used for first lookup
FOR: address of H1.domain.com
Back comes:
H1.ADDRESS with a TTL of 10 minutes
plus authority and addition section.
The authority section lists:
domain.com NS NS.server2.com (with a TTL of 10 minutes)
The additional section lists:
NS.server2.com A ADDRESS2 (with a TTL of an hour)
The spamvertized URL is returns a redirection,
HTTP 302
Location: H2.domain.com
What happens now?
One has gotten the address of H1.domain.com and the
new NS record from the nameserver which was listed
in the root server - and its address.
The redirection is to H2.domain.com.
That is not cached. It has to be looked up at ...
well, one has the cached NS record for domain.com
as NS.server2.com at ADDRESS2 so does not one
then query
QUERY: ADDRESS2 <-- used for second lookup
FOR: adress of H2.domain.com
?
One should never see ADDRESS2 originally (if someone else
tries to resolve H1.domain.com) for when the cached address
of H1.domain.com expires, so does the cached NS record
for domain.com.
Am I going to have to check the root servers for nameservers
for a spamvertized URL and then, if there is redirection to
another host in the domain, the full data they return?
Even if there is no redirection, suppose the A record returned
for H1.domain.com has TTL of zero and the NS record returned
from the nameserver found in the root servers has a longer TTL.
It may be that the nameserver listed in the ROOT server for
domain.com has NO address record for H2.domain.com.
If one queries, originally, just for H2.domain.com (or by
specifically using the nameservers listed in the root servers
assuming there was no cached values) one finds the site inaccessible.
Going through H1.domain.com first, however, gets a cached NS record
for the new nameserver which *does* resolve H2.domain.com.
Keeping the TTLs short (on the order of seconds) can this be used
to introduces an analogy to checking the referrer when going from
one web page to the next, but checking the prior lookup (the
second lookup may only work if one does go through the "proper"
first resolution) instead to block access?
Can one use one redirection to a host, using a front nameserver
which is expendable, to switch over to other nameservers one
wants to protect?
Credits to Spamless of news.admin.net-abuse.email