A university course-site waterfall shows DNS as a small slice of load time, while one course image accounts for most of the bytes and the wait. What should be fixed first?
Select an answer to reveal the explanation.
Short Explanation
A tiny address on the envelope did not make the parcel heavy, and you deal with the parcel. The course image that accounts for most of the bytes and the wait is the object to fix, while DNS is only a small slice of the waterfall. A WAN loss alarm, a hijack conclusion from that small lookup, or a QoS change aimed at the site blames the wrong layer.
Full Explanation
The waterfall already separates a short DNS slice from a course image that accounts for most of the bytes and most of the wait. The fix that matches that evidence is the oversized course image, not the lookup that contributes little of the load time. A WAN loss alarm on the path into the university data center would be the lead if the path showed loss and the object bars were not the dominant time, and the waterfall points at the image instead. A DNS hijack conclusion based only on that small lookup slice treats a short, ordinary lookup as an attack, and a hijack needs evidence that the name resolves to an unintended place, which a small slice does not provide. A QoS policy change for the course site because the image is large assumes the network must be reprioritized to carry a heavy object, when the waterfall says the object itself is the cost and the path has not been shown as congested. Exam caveat: object size and lookup time are different bars, and the longer bar is the one to act on. Operational check: confirm in the waterfall that the course image dominates bytes and time and that the DNS bar stays small, then resize or relocate that image before opening a WAN loss ticket or a QoS change.