26 research outputs found

    Poster:Observable KINDNS: Validating DNS Hygiene

    Get PDF
    The Internet's naming system (DNS) is a hierarchically structured database, with hundreds of millions of domains in a radically distributed management architecture. The distributed nature of the DNS is the primary factor that allowed it to scale to its current size, but it also brings security and stability risks. The Internet standards community (IETF) has published several operational best practices to improve DNS resilience, but operators must make their own decisions that tradeoff security, cost, and complexity. Since these decisions can impact the security of billions of Internet users, recently ICANN has proposed an initiative to codify best practices into a set of global norms to improve security: the Knowledge-Sharing and Instantiating Norms for DNS and Naming Security (KINDNS) [4]. A similar effort for routing security - Mutually Agreed Norms for Routing Security - provided inspiration for this effort. The MANRS program encourages operators to voluntarily commit to a set of practices that will improve collective routing security - a challenge when incentives to conform with these practices does not generate a clear return on investment for operators. One challenge for both initiatives is independent verification of conformance with the practices. The KINDNS conversation has just started, and stakeholders are still debating what should be in the set of practices. At this early stage, we analyze possible best practices in terms of their measurability by third parties, including a review of DNS measurement studies and available data sets (Table 1)

    This Is a Local Domain: On Amassing Country-Code Top-Level Domains from Public Data

    Full text link
    Domain lists are a key ingredient for representative censuses of the Web. Unfortunately, such censuses typically lack a view on domains under country-code top-level domains (ccTLDs). This introduces unwanted bias: many countries have a rich local Web that remains hidden if their ccTLDs are not considered. The reason ccTLDs are rarely considered is that gaining access -- if possible at all -- is often laborious. To tackle this, we ask: what can we learn about ccTLDs from public sources? We extract domain names under ccTLDs from 6 years of public data from Certificate Transparency logs and Common Crawl. We compare this against ground truth for 19 ccTLDs for which we have the full DNS zone. We find that public data covers 43%-80% of these ccTLDs, and that coverage grows over time. By also comparing port scan data we then show that these public sources reveal a significant part of the Web presence under a ccTLD. We conclude that in the absence of full access to ccTLDs, domain names learned from public sources can be a good proxy when performing Web censuses.Comment: 6 pages double-column, 4 figures; submitted to ACM SIGCOMM CC

    Assessing Network Operator Actions to Enhance Digital Sovereignty and Strengthen Network Resilience:A Longitudinal Analysis during the Russia-Ukraine Conflict

    Get PDF
    We conduct longitudinal and temporal analyses on active DNS measurement data to investigate how the Russia-Ukraine conflict impacted the network infrastructures supporting domain names under ICANN’s CZDS new gTLDs. Our findings revealed changes in the physical locations of network infrastructures, utilization of managed DNS services, infrastructure redundancy, and distribution, which started right after the first reported Russian military movements in February 2022. We also found that domains from different countries had varying location preferences when moving their hosting infrastructure. These observed changes suggest that network operators took proactive measures in anticipation of an armed conflict to promote resilience and protect the sovereignty of their networks in response to the conflict

    Hosting Industry Centralization and Consolidation

    Get PDF
    There have been growing concerns about the concentration and centralization of Internet infrastructure. In this work, we scrutinize the hosting industry on the Internet by using active measurements, covering 19 Top-Level Domains (TLDs). We show how the market is heavily concentrated: 1/3 of the domains are hosted by only 5 hosting providers, all US-based companies. For the country-code TLDs (ccTLDs), however, hosting is primarily done by local, national hosting providers and not by the large American cloud and content providers. We show how shared languages (and borders) shape the hosting market -- German hosting companies have a notable presence in Austrian and Swiss markets, given they all share German as official language. While hosting concentration has been relatively high and stable over the past four years, we see that American hosting companies have been continuously increasing their presence in the market related to high traffic, popular domains within ccTLDs -- except for Russia, notably.Comment: to appear in IEEE/IFIP Network Operations and Management Symposium https://noms2022.ieee-noms.org

    Assessing Network Operator Actions to Enhance Digital Sovereignty and Strengthen Network Resilience: A Longitudinal Analysis during the Russia-Ukraine Conflict

    Full text link
    We conduct longitudinal and temporal analyses on active DNS measurement data to investigate how the Russia-Ukraine conflict impacted the network infrastructures supporting domain names under ICANN's CZDS new gTLDs. Our findings revealed changes in the physical locations of network infrastructures, utilization of managed DNS services, infrastructure redundancy, and distribution, which started right after the first reported Russian military movements in February 2022. We also found that domains from different countries had varying location preferences when moving their hosting infrastructure. These observed changes suggest that network operators took proactive measures in anticipation of an armed conflict to promote resilience and protect the sovereignty of their networks in response to the conflict

    Saving Brian's Privacy: the Perils of Privacy Exposure through Reverse DNS

    Get PDF
    Given the importance of privacy, many Internet protocols are nowadays designed with privacy in mind (e.g., using TLS for confidentiality). Foreseeing all privacy issues at the time of protocol design is, however, challenging and may become near impossible when interaction out of protocol bounds occurs. One demonstrably not well understood interaction occurs when DHCP exchanges are accompanied by automated changes to the global DNS (e.g., to dynamically add hostnames for allocated IP addresses). As we will substantiate, this is a privacy risk: one may be able to infer device presence and network dynamics from virtually anywhere on the Internet -- and even identify and track individuals -- even if other mechanisms to limit tracking by outsiders (e.g., blocking pings) are in place. We present a first of its kind study into this risk. We identify networks that expose client identifiers in reverse DNS records and study the relation between the presence of clients and said records. Our results show a strong link: in 9 out of 10 cases, records linger for at most an hour, for a selection of academic, enterprise and ISP networks alike. We also demonstrate how client patterns and network dynamics can be learned, by tracking devices owned by persons named Brian over time, revealing shifts in work patterns caused by COVID-19 related work-from-home measures, and by determining a good time to stage a heist

    When Parents and Children Disagree:Diving into DNS Delegation Inconsistency

    Get PDF
    The Domain Name System (DNS) is a hierarchical, decentralized, and distributed database. A key mechanism that enables the DNS to be hierarchical and distributed is delegation [7] of responsibility from parent to child zones—typically managed by different entities. RFC1034 [12] states that authoritative nameserver (NS) records at both parent and child should be “consistent and remain so”, but we find inconsistencies for over 13M second-level domains. We classify the type of inconsistencies we observe, and the behavior of resolvers in the face of such inconsistencies, using RIPE Atlas to probe our experimental domain configured for different scenarios. Our results underline the risk such inconsistencies pose to the availability of misconfigured domains
    corecore