TCP and UDP are separate transport protocols even though the port number is the same. The result on one does not automatically indicate the status of the service on the other.

Basic approach

The TCP connection establishment process produces distinct responses. UDP is connectionless; An open service may remain silent if the appropriate application message is not sent. Therefore, in most cases, no response in UDP alone is not enough to distinguish open, closed and filtered possibilities.

Application steps

  1. Write the controlled protocol with the port number; Don't just say 53 is open.
  2. Select the service's documented transport method and check at the application level if possible.
  3. Record timeout as failed connection; Do not give definitive off label without sufficient evidence.

Practical example

While the TCP 53 connection for DNS may be successful, UDP queries may be filtered. In the opposite case, small UDP queries will work, transactions requiring TCP will fail. The same number can hide two different access policies.

Interpret the result correctly

Open port does not ensure device type or software version. Services can run on non-standard ports. Keeping the port observation separate in the inventory from the service response and device reported identity reduces misclassification.

Source and follow-up reading

Protocol or command details: RFC 768. The steps and example scenario are IPScans editorial narrative.