Part1

1. Report on the DNS traffic seen. You should describe what happened and illustrate
the zonal hierarchy involved with the DNS request as a diagram showing all the
computers (“Name Servers”) involved. Show and describe a sequence diagram of all
messages sent between the client, resolver, and DNS servers along with their IP
addresses. (6 points)
Answer: as followed is the sequence diagram illustrating the DNS query process for
the domain 'cool.com', showing the interactions between the client, resolver, and
various DNS servers, with each step clearly marked and with different colors
distinguishing between query and response arrows.
Part1

2. How is a DNS request matched with a DNS response (Choose any pair of DNS
requests/responses that you want and indicate the fields that allow for this matching)?
Speculate on why such a mechanism is necessary. (4 points)
Answer:
DNS Request: Packet No. 14, source IP: 192.168.0.10, destination IP: 192.168.1.101,
query: standard query for cool.com with transaction ID 0x8ee2
DNS Respons: Packet No. 23, source IP: 192.168.1.101, destination IP: 192.168.0.10,
response: standard query response for cool.com with transaction ID 0x8ee2
Fields used for matching:
(1) Transaction ID: each DNS request and its corresponding response share the same
transaction ID (0x8ee2 in this case). This is the primary identifier used to match
responses to their respective requests.
(2) Query/Response Type: the request is a query, and the corresponding packet is a
response.
(3) Queried Domain Name: both the request and the response contain the same
domain name that is being queried (cool.com).
Why necessary of such a mechanism:
DNS servers and clients handle multiple queries concurrently, and without a unique
identifier, it would be challenging to determine which response corresponds to which
request, especially when multiple requests may involve the same domain. This ensures
the integrity and accuracy of the DNS system, as clients receive correct information
for the domains they queried. Additionally, these matching fields are vital for security,
helping to prevent DNS spoofing attacks by ensuring that responses with mismatched
transaction IDs or domain names are discarded, thus maintaining reliable and secure
domain resolution.
Part1

3. What are ALL the different kinds of DNS Resource Records (RR) you saw in the
different DNS queries and answers? What do they represent and why were they
included in this traffic? (5 points)
Answer: ALL RR: A Record (Address Record), NS Record (Name Server Record),
OPT Record (Option Record)
(1) A Record maps a domain to its corresponding IPv4 address, fundamental for
connecting domain names with web servers, crucial for translating human-readable
domain names into machine-readable IP addresses that are necessary for networking
and routing purposes. In this traffic, an example is the response packets that resolve the
domain cool.com to an IPv4 address, such as 192.168.1.102 (Packet No. 22, 23).
(2) NS Record indicates authoritative DNS servers for the domain, which can provide
definitive responses to queries about the domain, facilitating the delegation and
distribution of DNS responsibilities, directing further DNS queries to the appropriate
authoritative name servers for subsequent DNS resolution steps. In this traffic, an
example is the responses that include NS records, pointing to name servers like
ns.tld.com and ns.cool.com (Packet No. 17, 20).
(3) OPT Record extends DNS protocol capabilities without requiring protocol
redesign. It is used in DNSSEC (DNS Security Extensions) to provide additional
options like increased DNS packet size and signaling, enhancing the functionality and
security of DNS transactions, supporting features such as extended response sizes
beyond traditional DNS size limits and to carry out DNSSEC-related data. In this
traffic, an example is the several packets of OPT records (Packets No. 15,16,20,21,22).
Part1

4. Report on the HTTP traffic seen. What is the IP address of the HTTP Server?
Indicate the headers seen in the first HTTP request and response and describe in
brief at least four 4 differences that you notice between a request and a response
header. Consider the first HTTP response (from the Server to the Client) and
calculate the percentage overhead of the size of the HTTP header compared to the
size of the HTTP content (content length). (Hint: Calculate the percentage overhead
as a simple relationship (value 1/value 2)*100). (6 points)
Answer: IP Address of the HTTP Server: 192.168.1.102
Headers in the first HTTP request and response: request is Packet No.27, a GET
request for the root document (/); esponse is Packet No. 29, a 200 OK response.
4 Differences between request and response headers:
(1) Purpose: request headers control the behavior of the fetch (like Accept types),
while response headers provide information about the server and fetched
resource (like Content-Type and Content-Length).
(2) Connection Handling: requests often use Connection: keep-alive to maintain the
connection, whereas responses confirm this behavior or instruct the client to
close the connection.
(3) Server Information: response headers typically include server details (Server),
which are absent in request headers.
(4) Content Details: response headers detail the content (Content-Length, Content-
Type), absent in the request unless it's a POST with body data.
Overhead% = (54/593)*100 = 9.11%
given payload = total packet size - header size,
where header size (overhead) = packet (647) - payload (593) = 54 bytes,
however, we know that the Ethernet header minimum size is 18 bytes,
so header size will be 54+4 = 58 bytes, overhead % = (58/593)*100 = 9.11%,
so in every packet, we are using 9.11% as headers, and 90.89% is used for data, the
higher the overhead the less data we are able to transfer.
Part1

5. Report on the latency performance of both HTTP and DNS. Calculate the total
amount of time taken by DNS and also by HTTP to complete their respective
processes. Also, analyze and report what is the round-trip time (RTT) of all requests/
responses for both HTTP and DNS. Finally, use the first DNS request from the client
to the resolver as the time of reference and describe the timeline of the entire
experiment until the last HTTP response is seen by the HTTP client. (7 points)
Answer:
DNS Request (Packet No. 14) timestamp is 11.214624 seconds, DNS Response
(Packet No. 23) timestamp is 11.220949 seconds, therefore total time taken by DNS
is 11.220949-11.214624 = 6.325 milliseconds
Since the first response to the DNS request is in Packet No. 17, therefore DNS RTT
is 11.216575-11.214624 = 1.951 milliseconds
HTTP Request (Packet No. 27) timestamp is 11.223448 seconds, HTTP Response
(Packet No. 29) timestamp is 11.226969 seconds, hence total time taken by HTTP
is 11.226969-11.223448 = 3.521 milliseconds
Since a single request-response cycle without retransmissions or multiple transactions,
therefore same as the total time, HTTP RTT is 3.521 milliseconds
Timeline of the entire experiment:
Start of DNS Query: 11.214624 seconds
End of DNS Response: 11.220949 seconds
Initial HTTP Transaction: immediately follows DNS resolution, starts at 11.223448
seconds, ends at 11.226969 seconds
Additional HTTP Request for an image: starts at 11.256892 seconds, ends at
11.267721 seconds
Therefore, total duration from first DNS request to last HTTP response is 11.267721-
11.214624=53.097 milliseconds
Part2

6. Report on the HTTP request and HTTP response sent/received to/from

http://bill.com. What information does the browser (HTTP client) use to understand
what is wrong with the original HTTP request and move forward to get the desired
webpage? What is the new domain for the required webpage? Where in the HTTP
response did you get the necessary information about the new domain? What happens
after the client receives the first response from the server with the information you
previously reported? (4 points)
Answer: Browsers use HTTP status codes to understand server responses. Codes
in the 4xx range indicate client errors (e.g., 404 Not Found), and 5xx for server errors,
redirections are usually indicated by 3xx status codes. In this traffic, for example, if the
browser receives a 404 Not Found, as indicated in packet No. 271 at 21.033632
seconds, it understands that the requested resource isn't available at the specified
URL; in cases of errors like 404, the client might refer to alternative URLs provided
either in the body of the error page or via redirection mechanisms like a 301 Moved
Permanently or 302 Found, which includes a Location header pointing to the new
URL, here, redirections are handled automatically by most modern browsers, which
will send a new HTTP request to the URL specified in the Location header.
The new domain for the required webpage can be found in the Location header of
an HTTP response carrying a 3xx status code, which provides the new URL to which
the request should be redirected.
Upon the client receiving a response with a 3xx status code and a Location header,
the browser automatically sends a new HTTP request to the URL specified in the
Location header, and if the response is a 404 Not Found, the browser may display an
error page or attempt to load a pre-configured fallback URL, depending on the
browser's configuration or user actions.
Part2

7. Once again analyze the DNS interactions for the loaded webpage. You may notice
something strange with the resolver and the lack of communication with the root
DNS server for the new location/domain of the webpage during their initial
interaction. Why do you think the resolver forwards the DNS request straight to the
TLD? What information in the messages sent to and received from the TLD makes it
behave differently? Why do more TLDs not behave the way the second one did?
What other navigation difference did you notice between the two domain names in
this question? (8 points)
Answer:
Resolver forwards DNS request straight to TLD, skipping Root DNS Servers,
because: the resolver already has the address of the TLD server cached, so it skips
querying the root and go directly to the TLD server, further reducing the time and
network overhead required to resolve the domain name. In this traffic, to be specific, the
resolver has previously cached the TLD server information needed to resolve the
domain names; this can happen if the resolver recently resolved another domain from
the same TLD or if the cache has not yet expired.
The TLD servers' behavior is largely uniform in that they direct the resolver to the
authoritative name servers for the second-level domains requested, and differences in
behavior among TLD servers typically don't occur unless there's a misconfiguration
or a policy difference enforced by the registry operating the TLD, for example, some
TLD registries might have specific rules regarding the availability of zone information
or how frequently their servers should be queried.
The DNS messages sent to and received from TLD servers include queries for
specific domain names and responses that contain the NS (Name Server) records;
such NS records tell the resolver which servers are authoritative for the requested
domain, thus enabling it to query these servers directly for the A (Address) or AAAA
(IPv6 Address) records. In this traffic, to be specific, responses from the TLD server (e.g.,
response from 192.168.1.105 to 192.168.1.107 about cmu.edu) directly include NS
records pointing to the authoritative servers, enabling the resolver to bypass further
unnecessary queries to the root.
More TLDs did not behave the way the second one did, because: the behavior
of TLD servers is generally consistent in terms of responding with NS records. But,
differences can arise due to specific configurations or policies set by TLD registries, as
some TLDs might implement rate limiting, geo-based responses, or other
differentiated services that could alter how they respond to DNS queries; moreover,
variations in caching duration and the freshness of cached data can affect whether a
TLD is queried directly after the root or if the resolver bypasses the root due to valid
cached TLD server information.
The other navigation differences can be seen from that:
(1) there are different domains being queried (cmu.edu and bill.cmu.edu), and the
navigation difference could relate to how DNS caching affects the resolution process;
for 'cmu.edu', if cached recently, the resolver could use that cache to resolve related
subdomains like bill.cmu.edu more quickly.
(2) additionally, the presence of ICMP messages such as Destination unreachable
(Port unreachable) in packet 127 suggests network or communication issues, possibly
indicating that a server expected to respond is not reachable or not responding as
expected.
Part2

8. Indicate the old zone and new zone DNS hierarchy for the old and new webpage
domains (We advise you to create a simple diagram to illustrate the differences
between DNS zone hierarchies (including their IP addresses) between the new and
old locations/domains of the webpage). Where is the Authoritative name server (IP
address) for the final webpage that is loaded? (5 points)
Answer: bill.cmu.edu (old domain), cmu.edu (new domain)

Authoritative name server for the final webpage is: IP Address 192.168.1.110
This IP address served authoritative DNS responses for queries related to cmu.edu,
which includes handling for any subdomains of bill.cmu.edu.
Part3

9. eport on the interactions (use the first and second iterations for this question).
What is the IP address of the proxy? Did the HTTP requests/responses change for
each iteration between the proxy and the Web Server? What header(s) in the requests
caused these changes? Indicate the two main status codes being returned in each
iteration and why they are different. Did you see anything else of interest? (6 points)
Answer: Proxy IP Address 192.168.1.104 (destination IP in the HTTP requests)
HTTP requests/responses do not change for the first iteration, as it fetches the
data directly from the server due to that the cache is cleared, returning 200 OK.
HTTP requests/responses do change for the second iteration, as the proxy now
stores the response and affects what gets cached, there emerges 304 Not Modified
indicating caching behavior.
Headers like ETag, Cache Control can cause caching and the returned status.
Part10

10. Report on the performance of the proxy during the first and second iterations.
How many bytes were transmitted for each of the two iterations and how long did
each iteration take (first and second iterations)? What is the percentage difference in
performance of the second request compared to the first (in transmitted bytes and
total time)? Does the proxy perform better than a normal browser? (6 points)
Answer: first iteration 21052 bytes, duration time=5.358364-4.436677= 0.921687 sec
second iteration 33070 bytes, duration time=46.585012-42.001705=4.583307 sec
bytes% = (33070-21052)/21052 = 57.09%,
time% = (4.583307-0.921687)/0.921687 = 397.27%
a. In the lab scenario, Yes, the proxy performs better than a normal browser.
b. Not always, it also depends on the cache hit rate and the efficiency of the proxy's
caching mechanism.
Part3

11. Explain the difference you saw between the second and third iterations in terms
of the different kinds of HTTP headers, requests, and responses being used between
the Client and the Proxy/Cache. In addition, report on the differences between the
second and third iterations in terms of the number of transmitted bytes, and the time
taken by each of the iterations (second and third).
Answer: for the second iteration, there is a successful retrieval of resources indicated
by status codes such as 200 OK and 304 Not Modified, which suggest that caching
and revalidation mechanisms are effectively in place, allowing for resource
optimization and minimized data transmission; whereas, for the third iteration, it is
marked by several 503 Service Unavailable responses, indicating temporary server or
proxy issues possibly due to maintenance or overload. This shift highlights a
disruption in normal proxy operations, affecting the usual caching behavior and
leading to failed requests instead of retrieving cached responses or contacting the
origin server as expected in typical proxy interactions, furthermore suggests a
breakdown in the proxy's capacity to manage requests efficiently, either due to
configuration issues or temporary operational setbacks.
second iteration 33070 bytes, duration time=46.585012-42.001705=4.583307 sec
third iteration 28825 bytes, duration time=8.757599-0.640625=8.116974 sec
bytes% = (28825-33070)/33070= -12.84%,
time% = (8.116974-4.583307)/4.583307= 77.10%
Part4
12. How does the value that you typed in the GET Range Field in the application get
translated into something in the HTTP request (Make sure to explain this in the
context of the GET method)? (2 points)
Answer: The value typed in the GET Range Field, such as "0-160", is sent in the
HTTP header as Range: bytes=0-160, which instructs the server to only send the
bytes within this specified range, so as server looks at this header, calculates which
part of the content corresponds to the range, prepares to send only that segment.

13. What is the range value you used to fetch the text? (2 points)
Answer: 0-160

14. How does the HTTP response, when using the Range field, differ from a normal
HTTP response (without the Range field)? (4 points)
Answer: instead of the usual 200 OK status code, the server responds with 206
Partial Content, indicating that only a specific portion of the data is being sent, and
this is specified in the Content-Range header, which delineates the exact bytes served
(e.g., bytes 0-115/total), showing only the portion of the total content included in the
response. Additionally, the body of the response contains just the requested byte
range rather than the entire resource, allowing for efficient data retrieval and reduced
bandwidth usage, especially beneficial for large files or media streaming.

15. What is the text displayed? How are Range GET requests used to skip the intro?
(3 points)
Answer: 14740{_RANGE_ROCKS_}
Range GET requests are used to skip parts of a video, such as an intro, by specifically
requesting a segment of the video's data from the server starting at a point after the
intro, by setting the Range header in the HTTP request to specify the exact bytes of
the video file to be delivered. The server then responds with the segment of the video
file starting from the requested point, allowing the video player to start playback from
there without having to download and process the entire file up to that point.

16. Try to request the same video range from your previous answer without the seek
bar, but use the GET Range input field instead. Were you able to skip the intro? Why
not? (4 points)
Answer: No, since the seek bar in a video player typically interacts with the video
streaming over an established connection, adjusting the range request dynamically. In
contrast, manually entering the range in a browser starts a new HTTP connection
each time, which does not preserve the state of the video player, which means the
entire context of the video, including buffer and playback position, is reset with each
new request, making it ineffective for skipping content as seamlessly as a seek bar
would.
Part5
Part6
19. Report on the results of what you saw. Did the first website load a page that you
did not expect? Why did that happen? (5 points)

The bill.cmu.edu appears as above, whereas, the cool.com remains normal, due to
DNS Spoofing.

20. Explain how the attack was possible. Be specific, using your knowledge of
networks and proper network terminology. (5 points)
DNS Spoofing was possible by exploiting vulnerabilities in the DNS resolution
process, where an attacker intercepts DNS queries and responds with falsified DNS
data before the legitimate DNS server can reply. To be more specific,
(1) At start, the malicious computer on the network was configured to monitor DNS
requests, by being on the same local network or by employing techniques like ARP
poisoning, it could intercept DNS queries sent from your computer to the resolver.
(2) Once it detected a DNS query (e.g., for bill.cmu.edu), the malicious computer
quickly sent a fraudulent DNS response, such spoofed response had to arrive at the
computer before the legitimate response from the actual DNS server to be effective.
(3) Then, the spoofed DNS response contained incorrect IP address mappings.
Instead of directing your browser to the legitimate IP address of the requested
domain, it directed the browser to an IP address controlled by the attacker, causing
the browser to connect to a server under the attacker's control, which could then
display malicious content or engage in further deceptive actions.
21. Explain why the attack worked for the first website, not the second one. (4 points)
Because specific security measures like DNSSEC (DNS Security Extensions) may not
have been implemented uniformly across all domains, or the browser's DNS cache
had stored the correct DNS information for 'cool.com' prior to the spoofing attack
being initiated; such discrepancy in the effectiveness of the DNS spoofing attack
across different domains highlights the importance of consistent security practices
across all networked resources.