PART 1: INTERNET CONTROL MESSAGE PROTOCOL (ICMP) TOOLS

1. Find the number of intermediate routers in the path between the Linux computer and the
host you selected at each of the three run tests (at different times of the day). Did the paths
change between run tests or even during a single run test? (5 points)
Answer: I Conducted for 3 different times to google.com, traceroutes consitstently showed
23 hops, including the destination. Although total numbers of hops remained consistent,
the paths did change between run tests, in this traffic for example, 72.14.213.79 in the
second and third tests but not in the first, additionally, minor fluctuations were observed in
the response times and the presence of non-responsive hops marked by asterisks, such
variability in the paths suggests dynamic routing practices, which ISPs might adjust based on
network traffic, maintenance, or optimization strategies to ensure efficient data delivery.
Since the dynamic nature of internet routing, where paths can change based on network
congestion, routing policies, and changes in the network topology, ISPs might reroute traffic
to optimize performance or avoid overloaded or malfunctioning network segments.
2. Try to roughly identify the number of ISP networks that the traceroute packets pass
through from source to destination. For this you can manually group routers into ISPs:
Routers with similar names and/or similar IP addresses could be considered as part of the
same ISP. (2 points)
Answer: 3 different ISP networks: first is Carnegie Mellon University’s own network
infrastructure (evident from router names like POD-D-CYH.GW.CMU.NET), subsequent
is transition to ISPs possibly including Level 3 Communications or a similar backbone
provider (as suggested by IPs resembling 72.14.x.x and 192.178.x.x, which are characteristic
of Google's infrastructure, indicating the final segments of the route), subsequent is
Google's internal network (distinctly identified towards the end of the path with routers
named under domains like 1e100.net).

3. Approximately how long did it take to run the entire traceroute test? Why so much longer
than the round-trip time (RTT) indicated by ping? (2 points)
Answers: Few seconds, much longer than RRT time 15milliseconds. Since its
operational method, where each hop along the path to the destination must be individually
identified and timed, traceroute sends multiple packets per hop, incrementing the Time-to-
Live (TTL) for each set, and waits for a response (or timeout) before proceeding to the next
hop, such systematic increase in TTL, combined with the wait for potential timeouts at each
hop, significantly extends the overall duration of the traceroute compared to ping, which
simply measures the round-trip time of packets directly to the destination without pausing at
intermediate routers.

4. Find &explain similarities and differences between ping &traceroute. (3 points)

Answer: (Similarity) Both tools measure the round-trip time (RTT) for packets sent to a
target host; however, (differences) ping is primarily used to determine the connectivity and
measure the latency between the source and the destination by sending ICMP echo requests
and waiting for echo replies, in constrast, traceroute is designed to map the route that packets
take from the source to the destination by sending sequences of ICMP packets with
incrementally increasing TTL (Time to Live) values, which causes routers along the path to
drop the packets and send back ICMP "time exceeded" messages, thus revealing the identity
of each intermediate hop until the packets reach the target. While ping provides a summary
of the network performance between two points, traceroute offers a detailed path analysis
and identifies where potential bottlenecks or failures occur in the network path.
5. Simulate the first 5 steps of a traceroute query to your chosen domain (host), but only
using ping (show your work). You will not have timing information, but do you get the same
5 intermediate routers as your previous traceroute tests? Just to be extra clear, for this
question I am asking you to use ping (perhaps with some command line options) such that
the packets getting sent are substantially similar to those that traceroute would have sent for
each of the first five (5) steps/nodes in the traceroute8. (5 points)

For compare, see this from previous steps:

Answer: Yes, I received the exact same responses manually that matched the intermediate
routers seen in traceroute results, indicating that using ping with specified TTL values can
replicate the initial segment of a traceroute path. Detailed analysis is attached:
- TTL = 1: The first hop returned by the ping was POD-D-CYH-VL141.GW.CMU.NET
(128.2.13.130), which corresponds exactly to the first hop reported by traceroute.
- TTL = 2: The second hop showed CORE2-POD-D-CYH.GW.CMU.NET
(128.2.255.201), aligning with the second hop in the traceroute output. This suggests the
packets traverse the same route at least up to this point.
- TTL = 3: At this TTL, you received no response, which was also observed in the third
hop of the traceroute (* * *), indicating a router that does not respond to ping probe.
- TTL = 4: The ping response was from INET-DCNS-8500-VLAN27.GW.CMU.NET
(192.12.32.19), identical to the fourth hop in the traceroute.

- TTL = 5: The ping response was from 128.2.5.206, matching the fifth hop in your
traceroute results.
PART2: DOMAIN INFORMATION GROPER (DIG)
6. For a given DNS query (e.g., dig google.com), a DNS response message (usually)
comprises four different sections: question, answer, authority, and additional. Explain briefly
the information each of the sections contains. (4 points)
Answer: typically 4 sections,
(1) Question Section: contains the request made to the DNS server, which includes the
domain name being queried and the type of record sought (e.g., A, MX, CNAME);
(2) Answer Section: provides the records that answer the query. For example, if the query
was for an A record of google.com, this section would list the IP addresses associated with
google.com;
(3) Authority Section: lists DNS servers that are authoritative for the domain being queried,
indicates which DNS servers have authority to answer questions about domain’s records.
(4) Additional Section: contains extra information about the answer section, such as the
resolved IP addresses of the DNS servers listed in the authority section, which helps in
reaching those servers directly.

7. What is the command-line option in dig to directly specify the name server to query? (2
points)
Answer: dig @8.8.8.8 google.com
8. What does the -x command-line option in dig do? If you do not use the -x option, how
would you achieve the same query? Use an example to illustrate. Why does this work? Will it
work for EVERY IP address? Why or why not? (4 points)

Answer: The -x command-line option in dig is used for reverse DNS lookups, which resolve
IP addresses back to their associated domain names:
dig -x 8.8.8.8
Without the -x option, achieve the same by querying the in-addr.arpa domain:
dig 8.8.4.4.in-addr.arpa PTR
Since the in-addr.arpa domain is specifically used for mapping IP addresses to domain names
in the reverse DNS system; however, it will not work for every IP address as not all IP
addresses have PTR records set up in their DNS settings, the presence of these records
depends on the IP address’s administrator.
9. Use the +trace option to query the CNAME record for www.cmu.edu. Also, make sure
the "Additional Information" is not displayed in your results. Copy the output into your
report (or take a screenshot). Then, write several sentences interpreting the various parts of
the output, commenting on why each line was included and what it means10. (4 points)

Answer: dig +trace +noadditional www.cmu.edu CNAME

(1) Root DNS Servers Response: the query begins at the root level with responses from the
root DNS servers (e.g., a.root-servers.net, b.root-servers.net, etc.). These servers do not
know the answer but direct the query to the next level by returning NS records for the .edu
TLD (Top-Level Domain).
(2) TLD DNS Servers for .edu: the .edu TLD servers (like a.edu-servers.net) then respond
with NS records pointing to the DNS servers responsible for the cmu.edu domain. This
includes additional RRSIG records which provide DNSSEC authentication of the response,
ensuring the integrity and authenticity of the data.
(3) Authority DNS Servers for cmu.edu: the DNS servers for cmu.edu are queried next.
They provide authoritative answers including: first, CNAME record indicating that
www.cmu.edu is an alias for WWW.R53.CMU.EDU., allowing for further resolution; second,
NS records for cmu.edu, indicating which servers can provide authoritative responses for this
domain.
(4) Interpretation of Output: first, each line of the output details specific DNS servers at
each hierarchy (root, TLD, and domain level) being queried and their responses; second, the
CNAME for www.cmu.edu resolving to WWW.R53.CMU.EDU. shows how DNS uses
aliases to point to the actual hostnames, which may be managed more dynamically; third, the
RRSIG records alongside NS and DS records underscore the DNSSEC's role in securing
DNS traffic by preventing spoofing attacks and ensuring responses are not tampered with.
(5) Comment on Reachability: there are notices of network unreachability (network
unreachable) for IPv6 queries (2001:...), indicating potential configuration issues with IPv6
networking on the querying server or along the path, not affecting the overall DNS
resolution due to fallback to IPv4.
10. Use dig to verify each one of the following claims. For each claim, answer whether
this information is true or false. Make sure to show the command(s) you used and the output
produced for each. Then, write a description or annotate the output to show how you know
the answer supports or refutes each claim (true or false). (9 points)
Cliam1: www-cmu-prod-vip.andrew.cmu.edu is our campus web server (domain name)
Claim2: you@andrew.cmu.edu email gets sent to andrew- mx-0[1-6].andrew.cmu.edu
Claim3: Email to you@cmu.edu gets handled by cmu-mx-0[1-4].cmu.edu

Answer: For claim1, true

By commanding dig www-cmu-prod-vip.andrew.cmu.edu A +noall +answer

the output indicates that the domain www-cmu-prod-vip.andrew.cmu.edu directly resolves to
the IP address 128.2.42.52, suggesting it is configured as a host.
By commanding dig www-cmu-prod-vip.andrew.cmu.edu CNAME +noall +answer
the absence of a CNAME record supports that this domain is not an alias and directly
corresponds to a primary host.
By commanding curl -I www-cmu-prod-vip.andrew.cmu.edu
The HTTP response shows a 301 redirect to the HTTPS version of the same URL, a
common security practice, and indicates the server is active.
Therefore, the evidence supports the claim that www-cmu-prod-vip.andrew.cmu.edu is the
campus web server for Carnegie Mellon University. The DNS configuration directly pointing
to an IP address suitable for web hosting and the HTTP server's response both validate that
this domain is actively used for the university's web hosting services, confirming its role as a
campus web server, the comprehensive verification through DNS resolution and HTTP
behavior confirms the server's operational and functional role within the campus's digital
infrastructure.
Answer: For claim2, false

By commanding dig andrew.cmu.edu MX +noall +answer

the MX records for andrew.cmu.edu show that the email handling is directed towards
Google's email servers (ASPMX.L.GOOGLE.COM and its alternatives ALT1, ALT2, ALT3,
and ALT4), this setup is typical for domains utilizing Google Workspace (formerly G Suite)
for email services.
Therefore, The claim that emails sent to you@andrew.cmu.edu are handled by servers named
andrew-mx-0[1-6].andrew.cmu.edu is not supported by the DNS records. Instead, the
domain utilizes Google's email servers for managing its email services, as indicated by the
MX records pointing to ASPMX.L.GOOGLE.COM and its alternatives, which refutes the
claim, demonstrating that the email infrastructure for andrew.cmu.edu is outsourced to
Google, not managed internally under the specified server names.

Answer: For claim3, false

By commanding dig cmu.edu MX +noall +answer

the MX records for cmu.edu indicate that the email services are managed by Google's
servers, similar to the setup for andrew.cmu.edu, such records specifically list Google's
standard mail servers: ASPMX.L.GOOGLE.COM and its alternatives (ALT1, ALT2, ALT3,
ALT4), servers are designed to handle incoming mail and ensure reliability and redundancy.
Therefore, The claim that emails to you@cmu.edu are handled by cmu-mx-0[1-4].cmu.edu is
not supported by the current DNS records. The actual email infrastructure for cmu.edu is
handled by Google's email servers, as shown by the MX records pointing to
ASPMX.L.GOOGLE.COM and its alternates, which indicates an external email
management system rather than internal servers specified by the claim, refuting the assertion
that cmu-mx-0[1-4].cmu.edu are the mail servers for cmu.edu.
PART 3: WHOIS
11.List the 5 Regional Internet Registries (RIRs) along with the general geographic locations
they are associated with. Also, state the full domain name of the whois for each RIR11. (2
points)
Answer: 5 RIRs along with their geographic locations &domain names of WHOIS servers:
(1) American Registry for Internet Numbers (ARIN):
- Location: Serves the United States, Canada, and several parts of the Caribbean.
- WHOIS Server: whois.arin.net
(2) Réseaux IP Européens Network Coordination Centre (RIPE NCC):
- Location: Serves Europe, the Middle East, and parts of Central Asia.
- WHOIS Server: whois.ripe.net
(3) Asia-Pacific Network Information Centre (APNIC):
- Location: Serves the Asia-Pacific region including Australia, New Zealand, and parts of
Oceania.
- WHOIS Server: whois.apnic.net
(4) Latin American and Caribbean Internet Addresses Registry (LACNIC):
- Location: Serves Latin America and parts of the Caribbean.
- WHOIS Server: whois.lacnic.net
(5) African Network Information Centre (AFRINIC):
- Location: Serves Africa.
- WHOIS Server: whois.afrinic.net

12. What is the command-line option in whois to directly specify the server to query? (2
points)
Answer: whois -h whois.arin.net "Type IP or AS number here"
This command specifies querying the ARIN WHOIS server directly, which is particularly
useful when you need information specific to a region or registry that may not be readily
available through the default WHOIS server.
Using the -h option ensures that queries are directed to the appropriate RIR's WHOIS
database, allowing for more accurate and region-specific information retrieval, especially
when researching IP address allocations and ownership details.
PART 4: NETWORK MAPPER (NMAP)
13. Using nmap check if www.cmu.edu is running an HTTP, HTTPS, and DNS servers
associated with their domain name. How did you do this? Use the IP address of the domain
name to answer this question (not the domain name directly). Make sure to explain the
process that you followed, the command options you used, and whether the services are
running or not (4 points).

Answer: Step1, obtain the IP address by dig www.cmu.edu A +noall +answer

this dig command queries the DNS A records for www.cmu.edu and displays the IP address
where the domain points 128.2.42.52
Step2, preparer the Nmap command by nmap -p 80,443,53 128.2.42.52

- 53/tcp closed domain: indicates that the DNS service is not active on this IP. The
closed state means the port is accessible but there is no service listening on it.
- 80/tcp open http: indicates that the server is actively listening for incoming connections
on port 80, typical for servers serving HTTP content.
- 443/tcp open https: shows that the server is also listening on port 443, supporting
HTTPS for secure communications.
Therefore, based on the nmap results, the IP address 128.2.42.52 is actively running HTTP
and HTTPS services, but not DNS services, which means that the server is configured to
serve web content (both secure and non-secure), but any DNS queries would need to be
handled by a different server or setup, as this server does not respond to DNS requests on
port 53.
14. Using nmap, scan the hosts and their open ports for the set of IP addresses 8.8.4.0/28.
How did you do this? How many IP addresses are scanned (can you deduct why this number
from the network information)? How many hosts are active in this range? What host is
active? For the active hosts, based on the port analysis12, what kind of services are being
provided in the host? What is the domain name of the active host? (3 points)

Answer: nmap -sn 8.8.4.0/28

nmap -p 53,80,443 8.8.4.4
Step1, specifying the IP range:
The target for the Nmap scan was specified as 8.8.4.0/28. This range encompasses 16 IP
addresses (from 8.8.4.0 to 8.8.4.15), as indicated by the /28 subnet mask (255.255.255.240),
the small subnet includes the network address (8.8.4.0) and the broadcast address (8.8.4.15),
with 14 usable addresses for hosts.
Step2, performing the scan:
by commanding nmap -sn 8.8.4.0/28 to perform a network sweep (host discovery) without
port scanning, output quickly identifies which IP addresses are responsive; following the host
discovery, the by commanding nmap -p 53,80,443 8.8.4.4 to specifically scan for open ports
associated with common services (DNS, HTTP, HTTPS) on the active IP address found,
which is 8.8.4.4.
Step3, analysis of the result:
(1) Number of IP Addresses Scanned: 16 IP addresses were scanned in the 8.8.4.0/28
subnet, the choice of 16 addresses corresponds directly to the subnet mask /28, which
defines the range.
(2) Active Hosts: from the initial host discovery scan, only one host, 8.8.4.4, was found to be
active, which matches expectations for a subnet that may be primarily reserved for specific
services, with most addresses either unused or configured not to respond to pings, which is
to say, 8.8.4.4 is the only active host in the range, the domain associated with this IP is
dns.google.
(3) Services Provided by the Active Host:
DNS Service, port 53 is open, indicating that the server is actively listening for DNS queries.
HTTP Service, port 80 is filtered, suggesting it is blocked or selectively accessible, perhaps
restricted by a firewall.
HTTPS Service, port 443 is open, allowing secure web communication, which might be used
for secure API access or administrative interfaces.

Therefore, the domain dns.google suggests that 8.8.4.4 is being used as one of Google's
public DNS servers, the combination of open, filtered, and closed ports reflects a strategic
configuration aimed at maximizing functionality while ensuring security, the open DNS port
supports its primary role, the filtered HTTP port indicates security measures against
unencrypted web traffic, and the open HTTPS port facilitates secure transmissions.
PART 5: PUTTING IT ALL TOGETHER (USING ALL THE TOOLS)
15.What is the IP address of the default Local DNS server (or resolver) for CMU from the
viewpoint of the Linux (Time Share) machine that you have been using? (3 points)
Command: cat /etc/resolv.conf
Output:
nameserver 128.2.1.10
nameserver 128.2.1.11
search andrew.cmu.edu

therefore, the default local DNS servers (resolvers) for the CMU Linux Timeshare machine
are: Primary DNS Server: 128.2.1.10, Secondary DNS Server: 128.2.1.11
16. Find the names and IP addresses of all root name servers. (3 points)
Command: dig +nocmd +noall +answer NS . | awk '{print $5}' | xargs -I{} sh -c 'echo {};
dig +short {} A; dig +short {} AAAA'
Output:
j.root-servers.net.
192.58.128.30
2001:503:c27::2:30
h.root-servers.net.
198.97.190.53
2001:500:1::53
k.root-servers.net.
193.0.14.129
2001:7fd::1
c.root-servers.net.
192.33.4.12
2001:500:2::c
b.root-servers.net.
170.247.170.2
2801:1b8:10::b
a.root-servers.net.
198.41.0.4
2001:503:ba3e::2:30
m.root-servers.net.
202.12.27.33
2001:dc3::35
e.root-servers.net.
192.203.230.10
2001:500:a8::e
f.root-servers.net.
192.5.5.241
2001:500:2f::f
d.root-servers.net.
199.7.91.13
2001:500:2d::d
i.root-servers.net.
192.36.148.17
2001:7fe::53
l.root-servers.net.
199.7.83.42
2001:500:9f::42
g.root-servers.net.
192.112.36.4
2001:500:12::d0d
17. Using dig, make an educated guess as to what service Google is running on the server(s)
with an IP address of 8.8.8.8. (3 points)
Command: dig @8.8.8.8 google.com
Output:
; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> @8.8.8.8 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63279
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 300 IN A 172.253.115.113
google.com. 300 IN A 172.253.115.101
google.com. 300 IN A 172.253.115.102
google.com. 300 IN A 172.253.115.138
google.com. 300 IN A 172.253.115.139
google.com. 300 IN A 172.253.115.100

;; Query time: 8 msec

;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Oct 18 18:54:09 EDT 2024
;; MSG SIZE rcvd: 135

therefore, Google is running a DNS resolution service on the server at 8.8.8.8. The IP
address 8.8.8.8 is one of Google's Public DNS servers, primarily running DNS resolution
services, meaning that it handles DNS queries from users around the world, resolving
domain names into IP addresses like it did for google.com.
18. What is the hostname of the Default (Local) Name Server from the viewpoint of the
Linux (Time Share) machine that you have been using? (3 points)
Command: dig -x 128.2.1.10 +noall +answer
Output:
10.1.2.128.in-addr.arpa. 6748 IN PTR NSCACHE1.NET.CMU.EDU.

therefore, hostname corresponds to 128.2.1.10, system's default local DNS resolver.

19. Prove that the root name servers do not support recursive requests. Explain why or why
not using one root server as an example. (3 points)
Command: dig @a.root-servers.net www.example.com +norecurse
Output:
; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> @a.root-servers.net
www.example.com +norecurse
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25866
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com. IN A

;; AUTHORITY SECTION:
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.

;; ADDITIONAL SECTION:
l.gtld-servers.net. 172800 IN A 192.41.162.30
l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30
j.gtld-servers.net. 172800 IN A 192.48.79.30
j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30
h.gtld-servers.net. 172800 IN A 192.54.112.30
h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30
d.gtld-servers.net. 172800 IN A 192.31.80.30
d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30
b.gtld-servers.net. 172800 IN A 192.33.14.30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
f.gtld-servers.net. 172800 IN A 192.35.51.30
f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30
k.gtld-servers.net. 172800 IN A 192.52.178.30
k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30
m.gtld-servers.net. 172800 IN A 192.55.83.30
m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30
i.gtld-servers.net. 172800 IN A 192.43.172.30
i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30
g.gtld-servers.net. 172800 IN A 192.42.93.30
g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
c.gtld-servers.net. 172800 IN A 192.26.92.30
c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30
e.gtld-servers.net. 172800 IN A 192.12.94.30
e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30

;; Query time: 8 msec

;; SERVER: 198.41.0.4#53(a.root-servers.net) (UDP)
;; WHEN: Fri Oct 18 18:54:20 EDT 2024
;; MSG SIZE rcvd: 840
therefore, the output from this query to a.root-servers.net provides evidence that root name
servers do not perform recursive DNS resolution, since:
(1) Query Result: the ANSWER SECTION in the output is empty, meaning the root
server did not resolve the IP address. (2) Authority Section: root server provided a referral
in the AUTHORITY SECTION to a set of authoritative servers for the .com domain (e.g.,
l.gtld-servers.net, j.gtld-servers.net, etc.), which indicates that the root server is directing us to
the next level of DNS resolution but is not resolving the query recursively itself. (3) Non-
Recursive Behavior: lack of an IP address in the answer section, coupled with the referral
to the next level (TLD servers), is a clear indication that the root server is only authoritative
for the root zone and not resolve queries further down the DNS hierarchy.
To conclude, root name servers do not support recursive requests because their role is
limited to providing authoritative information about the next level of DNS servers (TLD
servers), ensuring that the DNS resolution process is distributed and scalable.
20. Find the top-level name servers for the .beer domain. Which organization owns these
name servers? What is the technical point of contact? (4 points)
Command1: dig +nocmd +noall +answer NS beer.
Output:
beer. 59302 IN NS z.nic.beer.
beer. 59302 IN NS x.nic.beer.
beer. 59302 IN NS c.nic.beer.
beer. 59302 IN NS b.nic.beer.
beer. 59302 IN NS y.nic.beer.
beer. 59302 IN NS a.nic.beer.

Command2: whois beer

Output:
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

domain: BEER

organisation: Registry Services, LLC

address: 100 S. Mill Ave, Suite 1600
address: Tempe AZ 85281
address: United States of America (the)

contact: administrative
name: IANA Contact
organisation: GoDaddy Registry
address: 100 S. Mill Ave, Suite 1600
address: Tempe AZ 85281
address: United States of America (the)
phone: +1 480-505-8800
fax-no: +1 480-624-2546
e-mail: iana@registry.godaddy
contact: technical
name: IANA Contact
organisation: GoDaddy Registry
address: 100 S. Mill Ave, Suite 1600
address: Tempe AZ 85281
address: United States of America (the)
phone: +1 480-505-8800
fax-no: +1 480-624-2546
e-mail: iana@registry.godaddy

nserver: A.NIC.BEER 2001:dcd:1:0:0:0:0:10 37.209.192.10

nserver: B.NIC.BEER 2001:dcd:2:0:0:0:0:10 37.209.194.10
nserver: C.NIC.BEER 2001:dcd:3:0:0:0:0:10 37.209.196.10
nserver: X.NIC.BEER 156.154.172.82 2610:a1:1074:0:0:0:1:82
nserver: Y.NIC.BEER 156.154.173.82 2610:a1:1075:0:0:0:1:82
nserver: Z.NIC.BEER 156.154.174.82 2610:a1:1076:0:0:0:1:82
ds-rdata: 39367 8 2
32940ab06d3524457f9ddead6c3c0c76729eec27c5cc02244cea24e9fd9e47f4

whois: whois.nic.beer

status: ACTIVE
remarks: Registration information: http://nic.beer/

created: 2014-03-13
changed: 2024-04-16
source: IANA

therefore,
(1) Top-Level Name Servers for the .beer Domain:
a.nic.beer
b.nic.beer
c.nic.beer
x.nic.beer
y.nic.beer
z.nic.beer
(2) Organization That Owns the Name Servers:
Registry Services, LLC (operated by GoDaddy Registry).
(3) Technical Point of Contact:
Name: IANA Contact
Organization: GoDaddy Registry
Email: iana@registry.godaddy
Phone: +1 480-505-8800
21. Use dig to find the IP address for www.ini.cmu.edu. Then, use the IP address in your
local machine browser (i.e., your computer not the Linux Timeshare) to load the web pages
(Type the IP address you find using dig in your browser's address bar.) Do you get what you
would expect to get? Explain what you see. Your explanation should, for instance, use your
knowledge of the HTTP protocol (Hint: Use your web browser inspector tools to analyze
the HTTP interaction). (5 points)
Command: dig www.ini.cmu.edu A +noall +answer
Output:
www.ini.cmu.edu. 600 IN CNAME WWW.R53.cmu.edu.
WWW.R53.cmu.edu. 13 IN A 128.2.42.52

therefore, by using the dig command to find the IP address for www.ini.cmu.edu, I found
that it resolves to 128.2.42.52. When I entered this IP address directly into my local
machine's browser, I did not get the expected website content (the INI webpage). This
occurs because modern web servers rely on the HTTP Host header to identify which specific
website to serve, especially when multiple websites are hosted on the same server. By
entering only the IP address, the browser sends a request without the correct Host header
(www.ini.cmu.edu), causing the server to either display a default page, show an error, or
redirect improperly. Additionally, if the website enforces HTTPS, a certificate mismatch may
result in a security warning, as the certificate is tied to the domain, not the IP address. Proper
access to the website requires entering the full domain name, not just the IP.
22. Find out details about Autonomous System Number 8. Include the OrgName, OrgID,
ASName, and the ASHandle in your answer. (4 points)
Command: whois -h whois.arin.net AS8
Output:
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2024, American Registry for Internet Numbers, Ltd.
#

ASNumber: 8
ASName: RICE-AS
ASHandle: AS8
RegDate: 1984-03-26
Updated: 1997-11-10
Ref: https://rdap.arin.net/registry/autnum/8

OrgName: Rice University

OrgId: RICEUN
Address: Networking MS 119
Address: 6100 Main Street
City: Houston
StateProv: TX
PostalCode: 77005
Country: US
RegDate: 1983-12-02
Updated: 2020-09-09
Ref: https://rdap.arin.net/registry/entity/RICEUN

OrgTechHandle: RUH-ORG-ARIN
OrgTechName: Rice University Networking
OrgTechPhone: +1-713-348-5244
OrgTechEmail: ipadmin@rice.edu
OrgTechRef: https://rdap.arin.net/registry/entity/RUH-ORG-ARIN

OrgAbuseHandle: RUH-ORG-ARIN
OrgAbuseName: Rice University Networking
OrgAbusePhone: +1-713-348-5244
OrgAbuseEmail: ipadmin@rice.edu
OrgAbuseRef: https://rdap.arin.net/registry/entity/RUH-ORG-ARIN

OrgTechHandle: HOCKE30-ARIN
OrgTechName: Hockett, Matt
OrgTechPhone: +1-713-348-2280
OrgTechEmail: mlh9@rice.edu
OrgTechRef: https://rdap.arin.net/registry/entity/HOCKE30-ARIN

RTechHandle: RUH-ORG-ARIN
RTechName: Rice University Networking
RTechPhone: +1-713-348-5244
RTechEmail: ipadmin@rice.edu
RTechRef: https://rdap.arin.net/registry/entity/RUH-ORG-ARIN

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2024, American Registry for Internet Numbers, Ltd.
#

therefore, OrgName: Rice University

OrgID: RICEUN
ASName: RICE-AS
ASHandle: AS8
RegDate: March 26, 1984
Address: 6100 Main Street, Networking MS 119, Houston, TX 77005, US
OrgTech Contact: Rice University Networking
Phone: +1-713-348-5244
Email: ipadmin@rice.edu
23. Find the IP address range assigned to CMU. (3 points)
Command: whois -h whois.arin.net 'Carnegie Mellon University'
Output:
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2024, American Registry for Internet Numbers, Ltd.
#

#
# Query terms are ambiguous. The query is assumed to be:
# "e / Carnegie Mellon university"
#
# Use "?" to get help.
#

Software Engineering Institute (CERT-1-Z)

Carnegie Mellon University (CARNEG)
Carnegie Mellon University (CARNEG-Z)
Software Engineering Institute (CERT-1)
Pittsburgh Supercomputing Center (PSC)
Pittsburgh Supercomputing Center (PSC-Z)

Carnegie Mellon University (C10393409) NET-CCF---69-64-222-32-28 (NET-69-64-222-32-

1) 69.64.222.32 - 69.64.222.47
Carnegie Mellon University (C10881599) ZAYO-IDIA-397525-209-249-178-188-31 (NET-
209-249-178-188-1) 209.249.178.188 - 209.249.178.189
CARNEGIE MELLON UNIVERSITY (C07622834) CARNEGIE-MELLON-
UNIVERSITY (NET-173-198-9-144-1) 173.198.9.144 - 173.198.9.151
CARNEGIE MELLON UNIVERSITY (C07622836) CARNEGIE-MELLON-
UNIVERSITY (NET6-2600-5C00-47A0-1) 2600:5C00:47A0:: -
2600:5C00:47A0:FFFF:FFFF:FFFF:FFFF:FFFF

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2024, American Registry for Internet Numbers, Ltd.
#

therefore, IP address ranges assigned to Carnegie Mellon University (CMU) are as followed:
69.64.222.32 - 69.64.222.47 (Carnegie Mellon University)
209.249.178.188 - 209.249.178.189 (Carnegie Mellon University)
173.198.9.144 - 173.198.9.151 (Carnegie Mellon University)
2600:5C00:47A0:: - 2600:5C00:47A0:FFFF:FFFF:FFFF:FFFF (IPv6 address block)
24. Find the IP address of linux.ece.cmu.edu by following these steps:
a. Ask the C root server for the linux.ece.cmu.edu address without recursion. (2 points)
b. Go through the hierarchy from the root without recursion and follow the referrals
manually until you have found the address of linux.ece.cmu.edu. Show all your work. (3
points) What is the address? (2 points) How many iterations did it take? (2 points)
Command1: dig @c.root-servers.net linux.ece.cmu.edu +norecurse
Output:
; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> @c.root-servers.net
linux.ece.cmu.edu +norecurse
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41488
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 7762a524cde10c1d010000006712e739c6d665362931e7d8 (good)
;; QUESTION SECTION:
;linux.ece.cmu.edu. IN A

;; AUTHORITY SECTION:
edu. 172800 IN NS m.edu-servers.net.
edu. 172800 IN NS f.edu-servers.net.
edu. 172800 IN NS c.edu-servers.net.
edu. 172800 IN NS l.edu-servers.net.
edu. 172800 IN NS b.edu-servers.net.
edu. 172800 IN NS e.edu-servers.net.
edu. 172800 IN NS g.edu-servers.net.
edu. 172800 IN NS d.edu-servers.net.
edu. 172800 IN NS h.edu-servers.net.
edu. 172800 IN NS j.edu-servers.net.
edu. 172800 IN NS i.edu-servers.net.
edu. 172800 IN NS k.edu-servers.net.
edu. 172800 IN NS a.edu-servers.net.

;; ADDITIONAL SECTION:
m.edu-servers.net. 172800 IN A 192.55.83.30
l.edu-servers.net. 172800 IN A 192.41.162.30
k.edu-servers.net. 172800 IN A 192.52.178.30
j.edu-servers.net. 172800 IN A 192.48.79.30
i.edu-servers.net. 172800 IN A 192.43.172.30
h.edu-servers.net. 172800 IN A 192.54.112.30
g.edu-servers.net. 172800 IN A 192.42.93.30
f.edu-servers.net. 172800 IN A 192.35.51.30
e.edu-servers.net. 172800 IN A 192.12.94.30
d.edu-servers.net. 172800 IN A 192.31.80.30
c.edu-servers.net. 172800 IN A 192.26.92.30
b.edu-servers.net. 172800 IN A 192.33.14.30
a.edu-servers.net. 172800 IN A 192.5.6.30
m.edu-servers.net. 172800 IN AAAA 2001:501:b1f9::30
l.edu-servers.net. 172800 IN AAAA 2001:500:d937::30
k.edu-servers.net. 172800 IN AAAA 2001:503:d2d::30
j.edu-servers.net. 172800 IN AAAA 2001:502:7094::30
i.edu-servers.net. 172800 IN AAAA 2001:503:39c1::30
h.edu-servers.net. 172800 IN AAAA 2001:502:8cc::30
g.edu-servers.net. 172800 IN AAAA 2001:503:eea3::30
f.edu-servers.net. 172800 IN AAAA 2001:503:d414::30
e.edu-servers.net. 172800 IN AAAA 2001:502:1ca1::30
d.edu-servers.net. 172800 IN AAAA 2001:500:856e::30
c.edu-servers.net. 172800 IN AAAA 2001:503:83eb::30
b.edu-servers.net. 172800 IN AAAA 2001:503:231d::2:30
a.edu-servers.net. 172800 IN AAAA 2001:503:a83e::2:30

;; Query time: 20 msec

;; SERVER: 192.33.4.12#53(c.root-servers.net) (UDP)
;; WHEN: Fri Oct 18 18:54:49 EDT 2024
;; MSG SIZE rcvd: 872
Command2: dig @a.edu-servers.net linux.ece.cmu.edu +norecurse
Output:
; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> @a.edu-servers.net
linux.ece.cmu.edu +norecurse
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52579
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linux.ece.cmu.edu. IN A

;; AUTHORITY SECTION:
cmu.edu. 172800 IN NS nsauth1.net.cmu.edu.
cmu.edu. 172800 IN NS nsauth2.net.cmu.edu.
cmu.edu. 172800 IN NS nsauth3.net.cmu.edu.

;; ADDITIONAL SECTION:
nsauth1.net.cmu.edu. 172800 IN A 128.2.1.8
nsauth2.net.cmu.edu. 172800 IN A 128.237.148.168
nsauth3.net.cmu.edu. 172800 IN A 23.20.155.125

;; Query time: 48 msec

;; SERVER: 192.5.6.30#53(a.edu-servers.net) (UDP)
;; WHEN: Fri Oct 18 19:25:47 EDT 2024
;; MSG SIZE rcvd: 164

Command3: dig @nsauth1.net.cmu.edu linux.ece.cmu.edu +norecurse

Output:
; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> @nsauth1.net.cmu.edu
linux.ece.cmu.edu +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54344
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e006e60388a297ddee7f9f9f6712eeb5a9b78df1391e5629 (good)
;; QUESTION SECTION:
;linux.ece.cmu.edu. IN A

;; AUTHORITY SECTION:
ECE.CMU.EDU. 86400 IN NS FS1.ECE.CMU.EDU.
ECE.CMU.EDU. 86400 IN NS FS3.ECE.CMU.EDU.
ECE.CMU.EDU. 86400 IN NS FS0.ECE.CMU.EDU.

;; ADDITIONAL SECTION:
FS0.ECE.CMU.EDU. 86400 IN A 128.2.129.20
FS1.ECE.CMU.EDU. 86400 IN A 128.2.129.22
FS3.ECE.CMU.EDU. 86400 IN A 128.2.129.21

;; Query time: 4 msec

;; SERVER: 128.2.1.8#53(nsauth1.net.cmu.edu) (UDP)
;; WHEN: Fri Oct 18 19:26:45 EDT 2024
;; MSG SIZE rcvd: 187
25.
yanhaob@linux-29:~$ dig @nsauth1.net.cmu.edu linux.ece.cmu.edu +norecurse

; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> @nsauth1.net.cmu.edu

linux.ece.cmu.edu +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54344
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e006e60388a297ddee7f9f9f6712eeb5a9b78df1391e5629 (good)
;; QUESTION SECTION:
;linux.ece.cmu.edu. IN A

;; AUTHORITY SECTION:
ECE.CMU.EDU. 86400 IN NS FS1.ECE.CMU.EDU.
ECE.CMU.EDU. 86400 IN NS FS3.ECE.CMU.EDU.
ECE.CMU.EDU. 86400 IN NS FS0.ECE.CMU.EDU.

;; ADDITIONAL SECTION:
FS0.ECE.CMU.EDU. 86400 IN A 128.2.129.20
FS1.ECE.CMU.EDU. 86400 IN A 128.2.129.22
FS3.ECE.CMU.EDU. 86400 IN A 128.2.129.21

;; Query time: 4 msec

;; SERVER: 128.2.1.8#53(nsauth1.net.cmu.edu) (UDP)
;; WHEN: Fri Oct 18 19:26:45 EDT 2024
;; MSG SIZE rcvd: 187

yanhaob@linux-29:~$ nmap -F cmu.edu

Starting Nmap 7.80 ( https://nmap.org ) at 2024-10-18 19:27 EDT
Stats: 0:00:00 elapsed; 0 hosts completed (0 up), 1 undergoing Ping Scan
Ping Scan Timing: About 100.00% done; ETC: 19:27 (0:00:00 remaining)
Nmap scan report for cmu.edu (128.2.42.10)
Host is up (0.0087s latency).
rDNS record for 128.2.42.10: CMU-VIP.ANDREW.CMU.EDU
Not shown: 97 closed ports
PORT STATE SERVICE
79/tcp open finger
80/tcp open http
443/tcp open https

Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds

26.
yanhaob@linux-29:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens161: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
group default qlen 1000
link/ether 00:50:56:af:ce:dc brd ff:ff:ff:ff:ff:ff
altname enp4s0
inet 128.2.13.174/26 metric 100 brd 128.2.13.191 scope global dynamic ens161
valid_lft 83896sec preferred_lft 83896sec
inet6 fe80::250:56ff:feaf:cedc/64 scope link
valid_lft forever preferred_lft forever
yanhaob@linux-29:~$ ip route
default via 128.2.13.129 dev ens161 proto dhcp src 128.2.13.174 metric 100
128.2.1.10 via 128.2.13.129 dev ens161 proto dhcp src 128.2.13.174 metric 100
128.2.1.11 via 128.2.13.129 dev ens161 proto dhcp src 128.2.13.174 metric 100
128.2.1.20 via 128.2.13.129 dev ens161 proto dhcp src 128.2.13.174 metric 100
128.2.1.21 via 128.2.13.129 dev ens161 proto dhcp src 128.2.13.174 metric 100
128.2.1.22 via 128.2.13.129 dev ens161 proto dhcp src 128.2.13.174 metric 100
128.2.1.23 via 128.2.13.129 dev ens161 proto dhcp src 128.2.13.174 metric 100
128.2.1.24 via 128.2.13.129 dev ens161 proto dhcp src 128.2.13.174 metric 100
128.2.1.25 via 128.2.13.129 dev ens161 proto dhcp src 128.2.13.174 metric 100
128.2.13.128/26 dev ens161 proto kernel scope link src 128.2.13.174 metric 100
128.2.13.129 dev ens161 proto dhcp scope link src 128.2.13.174 metric 100
27.
yanhaob@linux-29:~$ netstat -tuln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:904 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:4330 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:44323 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:44322 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:44321 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN
tcp6 0 0 :::80 :::* LISTEN
tcp6 0 0 :::111 :::* LISTEN
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 :::4330 :::* LISTEN
tcp6 0 0 :::44323 :::* LISTEN
tcp6 0 0 :::44322 :::* LISTEN
tcp6 0 0 :::44321 :::* LISTEN
tcp6 0 0 ::1:631 :::* LISTEN
udp 0 0 0.0.0.0:40092 0.0.0.0:*
udp 0 0 127.0.0.53:53 0.0.0.0:*
udp 0 0 128.2.13.174:68 0.0.0.0:*
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 0.0.0.0:161 0.0.0.0:*
udp 0 0 0.0.0.0:5353 0.0.0.0:*
udp 0 0 0.0.0.0:55316 0.0.0.0:*
udp 0 0 0.0.0.0:7001 0.0.0.0:*
udp6 0 0 :::44319 :::*
udp6 0 0 :::111 :::*
udp6 0 0 :::5353 :::*