DNS:

Examples of DNS in dig trace:

dig +trace www.bu.edu

client asks local BU server to find www.bu.edu
the BU server responds with a list of servers on the internet to ask for the ip (root servers)
these root server responds with a list of servers to ask about .edu addresses
the edu servers respond with address for bu.edu servers
the bu.edu servers give you the address for www.bu.edu

dig +trace www.nytimes.com

This time the root servers returned the list of gtld servers (global top level domain resolvers) since it’s on a .com domain.

dig +trace utoronto.ca

Note the CNAME record => utoronto.ca redirects to a cloudfront server on which it is hosted

dig +trace tsinhua.edu.cn

Client asks BU server, which responds with list of root servers
root servers respond with list of .cn servers
.cn servers return list of edu.cn servers
.edu.cn server returns tsinghua.edu.cn
this server returns www.tsinghua.edu.cn

Two kinds of DNS servers:

Nameservers: give you the ip for the server
Resolvers: help you find the ip for the server (queries a nameserver for the ip)

Who runs TLDs(Top Level Domains)?

The issue of who should run the TLDs is political: governments can censor by returning no info or incorrect info for domains that they want to censor.\ As of now, the US Department of Commerce decides who runs the TLDs

DNS threats:

DDoS amplification: DNS requests are very small and can return very large amounts of data. DNS is done over UDP so the source can forged for a DoS attack.As such, we want to keep DNS responses as short as possible to make attacks less powerful.
ISPs (or anyone else with access to your encrypted traffic) can see what DNS requests are made, and can thus see what websites are visited.
ISPs can lie about locations of servers by replying with false info. ISPs can then censor traffic, or (if the user simply clicks through certificate warnings, or is on a page without HTTPS) can man in the middle a user.
Content on pages (such as images) may require resources from other pages. These DNS queries to other pages may fingerprint which page a user is on, and allow an ISP to determine which specific pages you’ve visited on a site, even if your traffic is encrypted.
ISPs can also still monitor packet size to fingerprint pages.
DNS sends a request with the port number to respond to, and a request ID. After the port receives a DNS response with the correct request ID, it drops any further responses with that ID. If an on path or MITM attacker knows what domain you’re looking for, and when you’re going to be looking for it, they can send a fake response to you.
An attacker could have a website that serves a page containing hidden content from another site (eg. www.bu.edu)
When a victim visits the site, the attacker can send a fake DNS response to the victim for www.bu.edu.
The victim accepts the response for www.bu.edu and caches the fake location.
Everyone else using the same resolver that cached the location will also get the fake location when querying it.
(Next time it will be explained how an attacker can get the port number and request ID to actually accomplish this)

SOPA/PIPA:

Essentially an attempt by the government to censor copyright infringing material by exploiting DNS Justification: Trademark laws allow the government to confiscate trademark infringing things at the border, so pirated goods should also be “stopped at the border” under copyright law.

The case of rojadirecta:

ICE (Immigrations and Customs Enforcement) made DNS servers return the ICE web server IP when requests were made to find “rojadirecta.org”, which was hosting copyright infringing content (though it was deemed legal in Spain).

Another case:

An online travel agency in Canada was blocked by nameservers from being resolved by IPs in the US. The travel agency had been selling Cuba travel packages on its website. Even though this was the only content on its site that was illegal for users in the US, the website was still blocked entirely.