Answer to CSE Handson 1

Handson 1

Question 1

It’s primary use is to associate user-friendly character-string names(domain names) with machine-oriented birary identifiers for network attachment points(Internet address). In other words, domain names are easier to remember than IP addresses for humans.

Another use is many to many association. One IP can have multiple domain names while one domain name can have multiple IPs. Thanks to it, we can use many services today such as CDN.

Question 2

  • A: Specifies IP addresses corresponding to your domain and its subdomains;
  • NS: Specifies the authoritative nameservers for your domain name.
  • CNAME: Specify that a domain name is an alias for another domain

Question 3

Use command:

%dig somewebsite @server

For example,

%dig www.baidu.com @8.8.8.8

Question 4

  • Find roots

root@DESKTOP-KG830DE:~# dig . ns

; <<>> DiG 9.10.3-P4-Ubuntu <<>> . ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62351
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONA

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       2937    IN      NS      d.root-servers.net.
.                       2937    IN      NS      h.root-servers.net.
.                       2937    IN      NS      f.root-servers.net.
.                       2937    IN      NS      m.root-servers.net.
.                       2937    IN      NS      j.root-servers.net.
.                       2937    IN      NS      k.root-servers.net.
.                       2937    IN      NS      e.root-servers.net.
.                       2937    IN      NS      a.root-servers.net.
.                       2937    IN      NS      g.root-servers.net.
.                       2937    IN      NS      l.root-servers.net.
.                       2937    IN      NS      b.root-servers.net.
.                       2937    IN      NS      c.root-servers.net.
.                       2937    IN      NS      i.root-servers.net.

;; Query time: 1 msec
;; SERVER: 202.120.2.101#53(202.120.2.101)
;; WHEN: Sun Oct 08 21:50:12 DST 2017
;; MSG SIZE  rcvd: 239
  • a.root-servers.net.

root@DESKTOP-KG830DE:~# dig lirone.csail.mit.edu +norecurs @a.root-servers.net.

; <<>> DiG 9.10.3-P4-Ubuntu <<>> lirone.csail.mit.edu +norecurs @a.root-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16827
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 8

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;lirone.csail.mit.edu.          IN      A

;; AUTHORITY SECTION:
edu.                    172800  IN      NS      f.edu-servers.net.
edu.                    172800  IN      NS      a.edu-servers.net.
edu.                    172800  IN      NS      g.edu-servers.net.
edu.                    172800  IN      NS      l.edu-servers.net.
edu.                    172800  IN      NS      c.edu-servers.net.
edu.                    172800  IN      NS      d.edu-servers.net.

;; ADDITIONAL SECTION:
f.edu-servers.net.      172800  IN      A       192.35.51.30
a.edu-servers.net.      172800  IN      A       192.5.6.30
g.edu-servers.net.      172800  IN      A       192.42.93.30
g.edu-servers.net.      172800  IN      AAAA    2001:503:cc2c::2:36
l.edu-servers.net.      172800  IN      A       192.41.162.30
c.edu-servers.net.      172800  IN      A       192.26.92.30
d.edu-servers.net.      172800  IN      A       192.31.80.30

;; Query time: 222 msec
;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30)
;; WHEN: Sun Oct 08 21:55:11 DST 2017
;; MSG SIZE  rcvd: 284
  • a.edu-servers.net.

root@DESKTOP-KG830DE:~# dig lirone.csail.mit.edu +norecurs @a.edu-servers.net.

; <<>> DiG 9.10.3-P4-Ubuntu <<>> lirone.csail.mit.edu +norecurs @a.edu-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12802
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 12

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;lirone.csail.mit.edu.          IN      A

;; AUTHORITY SECTION:
mit.edu.                172800  IN      NS      usw2.akam.net.
mit.edu.                172800  IN      NS      asia1.akam.net.
mit.edu.                172800  IN      NS      asia2.akam.net.
mit.edu.                172800  IN      NS      use2.akam.net.
mit.edu.                172800  IN      NS      ns1-37.akam.net.
mit.edu.                172800  IN      NS      ns1-173.akam.net.
mit.edu.                172800  IN      NS      eur5.akam.net.
mit.edu.                172800  IN      NS      use5.akam.net.

;; ADDITIONAL SECTION:
usw2.akam.net.          172800  IN      A       184.26.161.64
asia1.akam.net.         172800  IN      A       95.100.175.64
asia2.akam.net.         172800  IN      A       95.101.36.64
use2.akam.net.          172800  IN      A       96.7.49.64
ns1-37.akam.net.        172800  IN      A       193.108.91.37
ns1-37.akam.net.        172800  IN      AAAA    2600:1401:2::25
ns1-173.akam.net.       172800  IN      A       193.108.91.173
ns1-173.akam.net.       172800  IN      AAAA    2600:1401:2::ad
eur5.akam.net.          172800  IN      A       23.74.25.64
use5.akam.net.          172800  IN      A       2.16.40.64
use5.akam.net.          172800  IN      AAAA    2600:1401:1::40

;; Query time: 193 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Sun Oct 08 21:55:59 DST 2017
;; MSG SIZE  rcvd: 428
  • usw2.akam.net.

root@DESKTOP-KG830DE:~# dig lirone.csail.mit.edu +norecurs @usw2.akam.net.

; <<>> DiG 9.10.3-P4-Ubuntu <<>> lirone.csail.mit.edu +norecurs @usw2.akam.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36218
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;lirone.csail.mit.edu.          IN      A

;; AUTHORITY SECTION:
csail.mit.edu.          1800    IN      NS      auth-ns0.csail.mit.edu.
csail.mit.edu.          1800    IN      NS      auth-ns2.csail.mit.edu.
csail.mit.edu.          1800    IN      NS      auth-ns1.csail.mit.edu.
csail.mit.edu.          1800    IN      NS      auth-ns3.csail.mit.edu.

;; ADDITIONAL SECTION:
auth-ns2.csail.mit.edu. 1800    IN      A       128.52.32.80
auth-ns1.csail.mit.edu. 1800    IN      A       18.24.0.120
auth-ns3.csail.mit.edu. 1800    IN      A       128.52.32.80
auth-ns0.csail.mit.edu. 1800    IN      A       128.30.2.123

;; Query time: 342 msec
;; SERVER: 184.26.161.64#53(184.26.161.64)
;; WHEN: Sun Oct 08 21:59:02 DST 2017
;; MSG SIZE  rcvd: 205
  • auth-ns0.csail.mit.edu.

root@DESKTOP-KG830DE:~# dig lirone.csail.mit.edu +norecurs @auth-ns0.csail.mit.edu.

; <<>> DiG 9.10.3-P4-Ubuntu <<>> lirone.csail.mit.edu +norecurs @auth-ns0.csail.mit.edu.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53083
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;lirone.csail.mit.edu.          IN      A

;; ANSWER SECTION:
lirone.csail.mit.edu.   1800    IN      A       128.52.129.186

;; Query time: 252 msec
;; SERVER: 128.30.2.123#53(128.30.2.123)
;; WHEN: Sun Oct 08 21:59:33 DST 2017
;; MSG SIZE  rcvd: 65
  • Got it

Question 5

Note: These commands were tested under the network of SJTU.

  • The first phenomenon
root@DESKTOP-KG830DE:~# dig www.twitter.com +trace

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.twitter.com +trace
;; global options: +cmd
;; Received 12 bytes from 202.120.2.101#53(202.120.2.101) in 1 ms

root@DESKTOP-KG830DE:~# dig www.baidu.com +trace

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.baidu.com +trace
;; global options: +cmd
;; Received 12 bytes from 202.120.2.101#53(202.120.2.101) in 1 ms

There are no differences bewteen these two results which means they are both cached in the name server 202.120.2.101. I tracked the NS and found that it is located in MinHang, Shanghai(闵行教育网). And actually it returned a real IP of twitter though it is blocked by GFW. It's really weird.

Then I did other tests with my aliyun VPS and cellular data. It seemed that looking up twitter.com was faster than looking up baidu.com. However, the answer was returned by h root server and the returned answer was fake. That means, my query was blocked by GFW and it return a fake ip to me.

  • The second phenomenon
root@DESKTOP-KG830DE:~# dig www.twitter.com @1.0.0.0

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.twitter.com @1.0.0.0
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62719
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.twitter.com.               IN      A

;; ANSWER SECTION:
www.twitter.com.        2899    IN      A       93.46.8.89

;; Query time: 27 msec
;; SERVER: 1.0.0.0#53(1.0.0.0)
;; WHEN: Sun Oct 08 20:33:31 DST 2017
;; MSG SIZE  rcvd: 64

root@DESKTOP-KG830DE:~# dig www.baidu.com @1.0.0.0

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.baidu.com @1.0.0.0
;; global options: +cmd
;; connection timed out; no servers could be reached

1.0.0.0 is not a real server. However, my query on twitter.com had a response. Actually, making queries on websites that are blocked by GFW to unexisting servers can always get the result but the result is fake.

The firewalls do this. Before my query did not arrive at the name server, the firewall intercepted it and returned a wrong IP to me.

The query on baidu.com was not intercepted by the firewall and IP 1.0.0.0 is not real, so the query timed out.

Here is a question: Why the connection to 202.120.2.101(闵行教育网) is not blocked by firewall when quering on twitter.com?

This is because 202.120.2.101 have cached the result of twitter.com and is able to return it immediately. And the firewall was deployed outside the 202.120.2.101.

Question 6

The connection will still be blocked by Greate Firewall of China.

I guess, the GFW uses the technologies blow:

  1. Route to the wrong destination and the fake server even never responses.
  2. Filtering keywords.

针对境外的IP地址封锁

相比起之前使用的访问控制列表(ACL)技术,现在防火长城采用了效率更高的路由扩散技术封锁特定IP地址。正常的情况下,静态路由是由管理员根据网络拓扑或是基于其它目的而给出的一条路由,所以这条路由最起码是要正确的,这样可以引导路由器把数据包转发到正确的目的地。而防火长城的路由扩散技术中使用的静态路由其实是一条错误的路由,而且是有意配置错误的,其目的就是为了把本来是发往某个IP地址的数据包统统引导到一个“黑洞服务器”上,而不是把它们转发到正确目的地。这个黑洞服务器上可以什么也不做,这样数据包就被无声无息地丢掉了。更多地,可以在服务器上对这些数据包进行分析和统计,获取更多的信息,甚至可以做一个虚假的回应。这些错误静态路由信息会把相应的IP数据包引导到黑洞服务器上,通过动态路由协议的路由重分发功能,这些错误的路由信息可以发布到整个网络。这样对于路由器来讲现在只是在根据这条路由条目做一个常规数据包转发动作,无需再进行ACL匹配,与以前的老方法相比,大大提高了数据包的转发效率。

针对HTTP协议的关键字阻断

2002年左右开始,中国大陆研发了一套关键字过滤系统。这个系统能够从出口网关收集分析信息,过滤、嗅探指定的关键字。普通的关键词如果出现在HTTP请求数据包的头部(如“Host: www.youtube.com”)时,则会马上伪装成对方向连接两端的计算机发送RST数据包(Reset)干扰两者间正常的TCP连接,进而使请求的内容无法继续查看。如果防火长城在数据流中发现了特殊的内文关键词(如“falun”等)时,其也会试图打断当前的连接,从而有时会出现网页开启一部分后突然停止的情况。在任何阻断发生后,一般在随后的90秒内同一IP地址均无法浏览对应IP地址相同端口上的内容。

你可能感兴趣的:(Answer to CSE Handson 1)