Cybercriminals have long depended on domain names for phishing, spam, malware distribution, and botnet operation. To facilitate the malicious activities, they continually register new domain names for exploitation. Previous work revealed an abnormally high concentration of malicious registrations in a handful of registrars and TLDs. However, no existing study systematically analyzed the factors driving abuse, leaving a critical gap in understanding how different variables influence malicious registrations. In this paper, we carefully distill the inclinations and aversions of malicious actors during the registration of new phishing domain names. Having compiled a list of 14.5 k malicious and 15.4 k benign domains, we collect a comprehensive set of 73 features for all the domains encompassing three main latent factors: registration attributes, proactive verification, and reactive security practices. With a GLM regression analysis, we found that each dollar reduction in registration fees corresponds to a 49% increase in malicious domain registrations. The availability of free bundled services, such as web hosting, drives an 88% surge in phishing activities. Conversely, stringent registration restrictions cut down abuse by 63%, while registrars providing API access for domain registration or account creation experience a staggering 401% rise in malicious domains. The results enable intermediaries involved in domain registration to develop tailored anti-abuse practices, yet aligning them with their economic interests.

Domain Name System Security Extensions (DNSSEC) enhanced the security of conventional DNS by providing data integrity and origin authentication, but enabled zone walking as a side effect. To address this issue, the Next Secure (NSEC3) resource record provides an authenticated denial of existence mechanism based on hashes of domain names. However, an improper selection of the NSEC3 parameters may significantly degrade the performance of resolvers and authoritative name servers alike. RFC 9276 (Guidance for NSEC3 Parameter Settings) imposes additional constraints on hash computation parameters, crucial in light of emerging security threats such as CPU resource exhaustion attacks. Despite this guideline, our analysis of over 302 M registered domain names reveals that 87.8 % of 15.5 % NSEC3-enabled domains fail to adhere to RFC 9276 with a dozen using 500 additional hash iterations. Furthermore, 78.3 % of 114 K open and closed validating resolvers impose the RFC's additional constraints on hash iterations with 18.4 % returning SERVFAIL, possibly rendering non-compliant domains unreachable.

The Domain Name System (DNS) relies on response codes to confirm successful transactions or indicate anomalies. Yet, the codes are not sufficiently fine-grained to pinpoint the root causes of resolution failures. RFC~8914 (Extended DNS Errors or EDE) addresses the problem by defining a new extensible registry of error codes to be served inside the OPT resource record. In this paper, we show that four major DNS resolver vendors and three large public DNS resolvers support this standard and correctly narrow down the cause of underlying problems. Yet, they do not agree in 94% of our test cases in terms of the returned EDE codes. We reveal that Cloudflare DNS is the most precise in indicating various DNS misconfigurations via the EDE mechanism, so we use it to perform a large-scale analysis of more than 303M registered domain names. We show that 17.7M of them trigger EDE codes. Lame delegations and DNSSEC validation failures are the most common problems encountered.

DNS Security Extensions (DNSSEC) provide the most effective way to fight DNS cache poisoning attacks. Yet, very few DNS resolvers perform DNSSEC validation. Identifying such systems is non-trivial and the existing methods are not suitable for Internet-scale measurements. In this paper, we propose a novel remote technique for identifying DNSSEC-validating resolvers. The proposed method consists of two steps. In the first step, we identify open resolvers by scanning 3.1 billion end hosts and request every non-forwarder to resolve one correct and seven deliberately misconfigured domains. We then build a classifier that discriminates validators from non-validators based on query patterns and DNS response codes. We find that while most open resolvers are DNSSEC-enabled, less than 18% in IPv4 (38% in IPv6) validate received responses. In the second step, we remotely identify closed non-forwarders in networks that do not have inbound Source Address Validation (SAV) in place. Using the classifier built in step one, we identify 37.4% IPv4 (42.9% IPv6) closed DNSSEC validators and cross-validate the results using RIPE Atlas probes. Finally, we show that the discovered (non)-validators actively send requests to DNS root servers, suggesting that we deal with operational recursive resolvers rather than misconfigured machines.

DNS dynamic updates represent an inherently vulnerable mechanism deliberately granting the potential for any host to dynamically modify DNS zone files. Consequently, this feature exposes domains to various security risks such as domain hijacking, compromise of domain control validation, and man-in-the-middle attacks. Originally devised without the implementation of authentication mechanisms, non-secure DNS updates were widely adopted in DNS software, subsequently leaving domains susceptible to a novel form of attack termed zone poisoning. In order to gauge the extent of this issue, our analysis encompassed over 353 million domain names, revealing the presence of 381,965 domains that openly accepted unsolicited DNS updates. We then undertook a comprehensive three-phase campaign involving the notification of Computer Security Incident Response Teams (CSIRTs). Following extensive discussions spanning six months, we observed substantial remediation, with nearly 54% of nameservers and 98% of vulnerable domains addressing the issue. This outcome serves as evidence that engaging with CSIRTs can prove to be an effective approach for reporting security vulnerabilities. Moreover, our notifications had a lasting impact, as evidenced by the sustained low prevalence of vulnerable domains.

Ingress filtering, commonly referred to as Source Address Validation (SAV), is a practice aimed at discarding packets with spoofed source IP addresses at the network periphery. Outbound SAV, i.e., dropping traffic with spoofed source IP addresses as it leaves its source network, has received widespread attention in operational and research communities. It is one of the most effective ways to prevent Reflection-based Distributed Denial-of-Service (DDoS) attacks. Contrariwise, inbound SAV, i.e., dropping incoming spoofed traffic at the destination network edge, has received less attention, even though it provides protection for the deploying network. In this paper, we present the results of the Closed Resolver Project, our initiative aimed at finding networks without inbound SAV and raising awareness of the issue. We perform the first Internet-wide active measurement study to enumerate networks that enforce (or not) inbound SAV. We reach open and closed Domain Name System (DNS) resolvers in tested networks and determine whether they resolve requests with spoofed source IP addresses. Our method provides unprecedented insight into inbound SAV deployment by network operators, revealing 49% IPv4 and 26% IPv6 Autonomous Systems (AS) that suffer from a consistent or partial absence of inbound filtering. By identifying dual-stack DNS resolvers and ASes, we further show that inbound filtering is generally deployed consistently across IPv4 and IPv6. Finally, the lack of inbound SAV exposes 2.5M IPv4 and 100K IPv6 purportedly closed DNS resolvers to many types of external attacks, including NXNSAttack, zone poisoning, or zero-day vulnerabilities in DNS software.