519

Port 519/tcp carries utime, an IANA-registered but essentially undocumented Unix time-related service; it has no meaningful legitimate use on the modern public internet and should not be exposed. The IANA Service Name and Transport Protocol Port Number Registry lists 519/tcp and 519/udp with the service name utime and description "unixtime," but cites no RFC and gives no protocol specification (the IANA Service Name and Transport Protocol Port Number Registry utime 519/tcp).

The IANA registry lists utime with no assignee and a blank reference field — no RFC or other specification document is cited for this service; utime appears to be a legacy or informal Unix time exchange distinct from the well-documented Time Protocol (RFC 868, TCP/UDP port 37) and Network Time Protocol (RFC 5905, UDP port 123). The blank reference is a registry fact, not an omission on this entry's part.

Port 519 is sometimes confused with the Unix routed/RIP service, but RIP actually runs on UDP port 520 (RFC 1058), with RIPng on UDP 521 — not 519. An initial web search surfaced a stray "efs" (extended file name server) description for port 519, but the authoritative IANA XML registry lists only utime for both 519/tcp and 519/udp as of an August 2026 check, so "efs" is not used here.

Measured open-frequency in the repo's port-data corpus (built from nmap-services) is 0 for 519/tcp and 0.00056 for 519/udp — a real sampled reading of essentially no observed open instances on TCP, not an absence of data (this site's own tooling).

Exposure

Should stay internal-only/closed; there is no documented legitimate reason for 519/tcp to be reachable from the public internet.

Notable CVE

None found in the NVD as of an August 2026 search.

Malware/backdoor association

None found in trojan-port lists or malware writeups as of an August 2026 search.

Anomaly signal

An open port 519/tcp is statistically rare (measured open-frequency 0 in the repo's nmap-services-derived corpus) and should be treated as noteworthy if observed.

IANA assignment

utime — "unixtime"; reference (blank — no RFC cited in IANA registry); assignee (none listed); dual-registered 519/tcp + 519/udp [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry utime 519/tcp; the IANA Service Name and Transport Protocol Port Number Registry utime 519/udp

Range class

system/well-known (0–1023)

Prevalence

nmap-services open-frequency 519/tcp = 0 (sampled, not observed open); 519/udp ≈ 0.00056 [Confirmed] — this site's own tooling

Related ports

37/tcp,udp (Time Protocol, RFC 868); 123/udp (NTP, RFC 5905); 520/udp (RIP, RFC 1058 — commonly confused with 519); 521/udp (RIPng)

Primary use

undocumented legacy Unix time-related service; no RFC describes the protocol

Other/unofficial uses

none found

Security implications

no CVE or malware association found; essentially never observed open

Typically seen on

unknown / rare; treat as an anomaly if seen open

Analyst note

An open port 519 is exceedingly rare in scan telemetry and has no documented legitimate service behind it; treat as an anomaly warranting investigation.

Port 519/udp is IANA-registered as utime ("unixtime"), a legacy Unix time-synchronization service, and it should not be exposed to the public internet: no independent evidence of an actively deployed modern implementation surfaced in research, so a responsive port 519/udp is an anomaly worth investigating rather than a routine finding.

The IANA registry lists utime with description "unixtime," dual-registered on both 519/tcp and 519/udp, with no assignee and a blank reference field — no RFC or other specification document is cited for this service. The blank reference is a registry fact, not an omission on this entry's part.

Measured traffic frequency for this port is low but nonzero: the nmap-services open-frequency for 519/udp is approximately 0.00056 (~0.056%), while the corresponding 519/tcp reading is exactly 0 (sampled, not observed open). One forum thread ties port 519 to DHCP failover configuration, but that association is uncorroborated by IANA or any other registry, and vendor documentation for DHCP failover more commonly cites TCP 647/847 — so it is reported here as an unverified lead, not an established use.

Exposure

Anomalous — utime is a legacy, apparently unmaintained service with no confirmed active implementation; an open 519/udp is unusual and merits investigation rather than routine allowance.

Unverified lead

A single forum reference associates port 519 with DHCP failover, but this is not corroborated by IANA or independent registries and should not be treated as an established fact.

IANA assignment

utime — "unixtime"; reference (blank — no RFC cited in IANA registry); assignee (none listed); dual-registered 519/tcp + 519/udp [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry utime 519/udp

Range class

well-known (0–1023) [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry utime 519/udp

Prevalence

nmap-services open-frequency 519/udp ≈ 0.00056 (~0.056%); 519/tcp ≈ 0 (sampled, not observed open) [Confirmed] — this site's own tooling

Related ports

none specifically identified in this research pass [Unknown]

Primary use

legacy Unix time-synchronization protocol named utime; no RFC or independent technical documentation of an active implementation found

Other/unofficial uses

a forum thread (Netgate/pfSense) mentions port 519 in a DHCP failover context, but this is uncorroborated by any registry and DHCP failover more commonly uses TCP 647/847 in vendor docs

Security implications

no CVE, malware association, or scanning-campaign documentation specific to this port identified as of an August 2026 search; service is legacy/likely obsolete with no confirmed active deployment

Typically seen on

no confirmed hosts or platforms; not observed in current deployment research [Unknown]

Analyst note

An open port 519/udp is statistically rare (nmap-services frequency ~0.056%) and corresponds to a legacy, apparently unmaintained IANA registration with no confirmed modern implementation — treat a responsive instance as worth investigating rather than assuming routine service.