Time is one of the Internet’s least visible yet most fundamental assets. Several time-sensitive applications, such as authentication systems, financial transactions, monitoring platforms, and network troubleshooting, rely on synchronisation across different systems. Across the Internet, the Network Time Protocol (NTP) is widely deployed to provide synchronisation. It is the mechanism through which most Internet-connected systems obtain and maintain synchronisation.

The Dominican Republic is an interesting case study because there is a formal institutional framework for allocating official time, yet the observable Internet infrastructure tells a much more fragmented story.

Who Provides the Time in the Dominican Republic?

The Dominican telecommunications regulator, INDOTEL, adopted Resolution No. 026-06, which sets out rules for determining and distributing the official time in electronic media and on the Internet. The regulation requires the electronic distribution of the reference time signal via NTP and obligates regulated entities, public bodies, and Internet service providers to synchronise their systems with that reference.

In recent years, the Dominican Institute for Quality, INDOCAL, has documented a national time and frequency standard based on a rubidium atomic clock traceable to UTC via the Inter-American Metrology System. Its documentation explicitly instructs users to configure horadominicana.indocal.gob.do as an NTP server; see Indocal. Unfortunately, during our tests, we could not resolve that hostname.

At the time of our measurements, we could not verify the presence of an official NTP service in the Dominican Republic. We contacted the local regulator about this issue, but we haven’t received a response yet.

Because no official local NTP server is available, we looked for public NTP servers in the country’s time zone. At the time of this analysis, we found zero active servers for do.pool.ntp.org. Thus, the country lacks an easily identifiable domestic public NTP presence that users would normally consult. However, scanning IP prefixes belonging to Dominican Autonomous Systems (ASes) reveals at least 225 public IPs that respond to NTP requests.

Beyond inventories such as Censys, this study examines NTP exposure across Dominican BGP prefixes and ASNs, investigates synchronisation characteristics and time-reference dependencies, and documents the observed unavailability of the country’s official NTP service.

Looking Across the Dominican Address Space

We analysed 1,475 announced IPv4 prefixes across 190 Dominican ASNs using Python’s ntplib library. Instead of scanning every address, we stopped at the first IP in each prefix that responded to an NTP query. We accepted only responses with mode 4 (server mode). Scans used a 1-second timeout and tested NTP versions 4, 3, and 2.

This distinction is important. The experiment measures NTP availability by prefix (via Mode 3 requests), not the absolute number of exposed NTP devices. We identified 225 distinct prefixes containing at least one public IPv4 address that responded to NTP, distributed across 73 Dominican ASNs.

Thus, approximately 15.3% of the analysed prefixes contained at least one observable NTP responder, whereas responders appeared in about 38.4% of the ASNs examined. Because only the first responder in each positive prefix was retained, 225 is a lower bound. The actual number of Internet-accessible NTP-capable devices within these networks may be considerably higher.

The distribution also argues against interpreting the result as a configuration problem isolated to one provider. Altice Dominicana, AS28118, accounted for 37 responders, or 16.44%; Trilogy Dominicana, AS46198, accounted for 22, or 9.78%; and Compañía Dominicana de Teléfonos, AS6400, accounted for 15, or 6.67%; see Figure 1. These ASes are not surprising, as they are the three largest. However, together, these three networks represented only 32.89% of the observations. The remaining 67.11% was distributed among other ASNs.

Public NTP responsiveness therefore appears to be a general characteristic of the observed ecosystem rather than an anomaly confined to one AS.

Public Time Servers or Network Devices Answering NTP?

A response on UDP port 123 does not necessarily indicate that the responding address was deliberately deployed as a public NTP server. However, the dataset suggests that at least some responders may be network devices not intended to provide public time synchronisation.

First, 57 of the 225 responders—25.33%—used an address ending in .1. This kind of IP address is frequently assigned to routers, gateways, or CPE interfaces. The suffix alone is not sufficient to identify device type; its prevalence is consistent with the hypothesis that many NTP responders are network equipment rather than dedicated public time servers.

Second, only two responders, 0.89%, reported Stratum 1. By contrast, 47 responders, 20.88%, returned Stratum 0. RFC 5905 explicitly defines Stratum 0 in received NTP packets as unspecified or invalid. It should therefore not be interpreted as a valid “Stratum-0 Internet time server.”

On the other hand, a notable finding was related to the Reference ID, encoded as decimal 1229867348. In hexadecimal, this is 0x494E4954, which decodes to the four ASCII characters INIT. RFC 5905 defines INIT to indicate that the association has not yet synchronised for the first time.

Moreover, RFC 8633 recommends implementations avoid exposing INIT in the REFID during initialisation, as doing so reveals information about daemon state and possible restarts to remote observers.

These observations are more consistent with routers, virtual machines, gateways, embedded systems, or NTP services intended for internal use that happen to be Internet-accessible than with a deliberately designed national public time-server infrastructure.

On the other hand, the NTP Reference ID field offers another perspective. For secondary NTP servers, the REFID can directly contain the IPv4 address of the upstream time source. Our measurements identified 90 REFID values corresponding to globally routable IPv4 addresses and 82 that resemble private IPv4 addresses, suggesting possible internal and external synchronisation dependencies. Private RFC1918 addresses are particularly interesting because they can expose elements of an operator’s internal synchronisation topology to an unauthenticated external observer.

Of the 90 global REFID occurrences, 30 distinct NTP server IPs were identifiable as public NTP infrastructure. These included Google, NIST, Microsoft, Apple, Cloudflare, Fortinet, TorIX, Yahoo, and several NTP Pool participants; see Figure 2.

In summary, the results indicate that many NTP responders are accessible over the public Internet. We cannot be certain whether network administrators are aware of this behaviour. We hypothesise that we are detecting NTP services exposed by default configurations, legacy settings, or permissive access controls on network devices such as routers, firewalls, access equipment, and servers.

Security Implications

It is worth highlighting that a device responding to a normal NTP timing query does not, by itself, demonstrate vulnerability to an amplification attack. Historically, NTP has been widely abused in reflected and amplified denial-of-service attacks because UDP permits source-address spoofing and because some NTP control commands can generate responses much larger than their requests. CISA has documented NTP as a UDP-based amplification vector, while the well-known monlist vulnerability, CVE-2013-5211, affected older ntpd versions with unrestricted monitoring functionality.

Our scan confirmed normal NTP availability; it did not establish that the 225 responders support vulnerable control commands. Therefore, they should not be automatically labelled “NTP amplifiers.”

Nevertheless, unnecessary public exposure increases the attack surface. RFC 8633 recommends that public-facing NTP servers block control-message queries originating outside their organisation, as such messages can be exploited for amplification. It also recommends ACLs that restrict sensitive queries to approved addresses.

In addition, RFC 8633 states that an NTP client that does not provide time to the network can drop Mode 3 timing queries from unexpected sources. Alternatively, operators should filter external Mode 3 queries or allow them only from trusted systems or networks. Leaf nodes are advised to accept only expected NTP responses from known sources.

Therefore, in the case that the devices observed in this study were not intentionally deployed as public NTP servers, their responses to unsolicited Internet-originated Mode 3 queries are inconsistent with best practices recommended by RFC 8633. The same RFC also recommends minimising information leakage via REFID and related fields. Our ability to observe private upstream addresses, synchronisation states, and externally referenced time providers shows that this leakage is not merely theoretical.

Final Thoughts on a Fragmented Clock

The central finding of this study is therefore not simply that “225 NTP responders exist in the Dominican Republic”. In particular, 225 of the 1,475 analysed prefixes contained at least one public IP address that responded to NTP, and those responders were distributed across 73 autonomous systems.

The evidence also suggests that many of these responders were not intentionally configured to provide public time synchronisation. Meanwhile, the country-level NTP Pool lists no Dominican servers, and the publicly documented institutional hostname horadominicana.indocal.gob.do did not resolve during our test, despite official documentation listing it as the national Internet time endpoint.