DOCSLIB.ORG

Minds!+!Machines! DNSSEC!Practice!Statement!!

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Minds!+!Machines! DNSSEC!Practice!Statement!! ! ! ! ! ! ! ! ! Minds!+!Machines! DNSSEC!Practice!Statement!! ! Version(1.1! !! October(5,(2013!! !!! !!! !!! !! !! !! !! !! !! !! !!! !!! Abstract!!! !!! This!document!is!the!DNSSEC!Practice!Statement,!it!states!the!practices!and!provisions!that!are!employed!in! providing!Zone!Signing!and!Zone!distribution!services!that!include,!but!are!not!limited!to,!issuing,!managing,! changing,!and!distributing!DNS!keys.!Minds!+!Machines!is!the!delegated!registry!operator!for!the!zone!under! contract!with!the!Internet!Corporation!for!Assigned!Names!and!Numbers.!!! !!! Copyright!Notice!!! !!! Copyright!(c)!2013!Minds!+!Machines.!All!rights!reserved.!!! ! ! !!! !(!! Minds!+!Machines!! 32!Nassau!St.! Dublin!2! Ireland! ! www.mindsandmachines.com!!! ! Table(of(Contents! 1.# INTRODUCTION#.....................................................................................................................................#6# 1.1.# Overview#........................................................................................................................................#6# 1.2.# Document#Name#and#Identification#...............................................................................................#7# 1.3.# Community#and#Applicability#.........................................................................................................#7# 1.3.1.# Zone#Manager#.........................................................................................................................#7# 1.3.2.# Zone#Administrator#.................................................................................................................#7# 1.3.3.# Zone#Maintainer#......................................................................................................................#7# 1.3.4.# Server#Operators#.....................................................................................................................#7# 1.3.5.# Zone#Key#Signing#Key#Operator#...............................................................................................#7# 1.3.6.# Zone#Signing#Key#Operator#......................................................................................................#7# 1.3.7.# Child#zone#manager#.................................................................................................................#8# 1.4.# Specification#Administration#..........................................................................................................#8# 1.4.1.# Specification#administration#organization#..............................................................................#8# 1.4.2.# Contact#Information#................................................................................................................#8# 1.4.3.# Specification#change#procedures#............................................................................................#8# 2.# PUBLICATION#AND#REPOSITORIES#........................................................................................................#9# 2.1.# Repositories#...................................................................................................................................#9# 2.2.# Publication#of#key#signing#keys#.......................................................................................................#9# 2.3.# Access#controls#on#repositories#......................................................................................................#9# 3.# OPERATIONAL#REQUIREMENTS#............................................................................................................#9# 3.1.# Meaning#of#domain#names#............................................................................................................#9# 3.2.# Activation#of#DNSSEC#for#child#zone#...............................................................................................#9# 3.3.# Identification#and#authentication#of#child#zone#manager#............................................................#10# 3.4.# Registration#of#delegation#signer#(DS)#records#.............................................................................#10# 3.5.# Removal#of#DS#record#...................................................................................................................#10# 3.5.1.# Who#can#request#removal#.....................................................................................................#10# 4.# FACILITY,#MANAGEMENT#AND#OPERATIONAL#CONTROLS#.................................................................#10# 4.1.# Physical#Controls#..........................................................................................................................#10# 4.1.1.# Site#location#and#construction#..............................................................................................#10# 4.1.2.# Physical#access#......................................................................................................................#10# 4.1.3.# Power#and#air#conditioning#...................................................................................................#11# 4.1.4.# Water#exposures#...................................................................................................................#11# 4.1.5.# Fire#prevention#and#protection#.............................................................................................#11# 4.1.6.# Media#storage#.......................................................................................................................#11# 4.1.7.# Waste#disposal#......................................................................................................................#11# 4.1.8.# Off_site#backup#......................................................................................................................#11# 4.2.# Procedural#Controls#.....................................................................................................................#11# 4.2.1.# Trusted#roles#.........................................................................................................................#11# 4.2.2.# Number#of#persons#required#per#task#...................................................................................#12# 4.2.3.# Identification#and#authentication#for#each#role#....................................................................#12# 4.2.4.# Tasks#requiring#separation#of#duties#.....................................................................................#12# 4.3.# Personnel#Controls#.......................................................................................................................#12# 4.3.1.# Qualifications,#experience,#and#clearance#requirements#......................................................#12# 4.3.2.# Background#check#procedures#..............................................................................................#13# 4.3.3.# Training#requirements#...........................................................................................................#13# 4.3.4.# Retraining#frequency#and#requirements#...............................................................................#13# 4.3.5.# Job#rotation#frequency#and#sequence#...................................................................................#14# 4.3.6.# Sanctions#for#unauthorized#actions#.......................................................................................#14# 4.3.7.# Contracting#personnel#requirements#....................................................................................#14# 4.3.8.# Documentation#supplied#to#personnel#.................................................................................#14# 4.4.# Audit#Logging#Procedures#............................................................................................................#14# 4.4.1.# Types#of#events#recorded#......................................................................................................#14# 4.4.2.# Frequency#of#processing#log###................................................................................................#15# 4.4.3.# Retention#period#for#audit#log#...............................................................................................#15# 4.4.4.# Protection#of#audit#log#..........................................................................................................#15# 4.4.5.# Audit#log#backup#procedures#................................................................................................#15# 4.4.6.# Audit#collection#system#.........................................................................................................#15# 4.4.7.# Notification#to#event_causing#subject#...................................................................................#15# 4.4.8.# Vulnerability#assessments#.....................................................................................................#16# 4.5.# Compromise#and#Disaster#Recovery#............................................................................................#16# 4.5.1.# Incident#and#compromise#handling#procedures#...................................................................#16# 4.5.2.# Corrupted#computing#resources,#software,#and/or#data#......................................................#16# 4.5.3.# Entity#private#key#compromise#procedures#..........................................................................#16# 4.5.4.# Business#Continuity#and#IT#Disaster#Recovery#Capabilities#...................................................#16#
Load more

Recommended publications
  • Increasing Internet Connectivity Through the Development of Local Networks
    Increasing Internet Connectivity through the Development of Local Networks Written for the Office of the Secretary-General of the International Telecommunications Union in reference to Administrative Region E Keertan Kini, WeiHua Li, Daniela Miao, Lauren Stephens {krkini16, wli17, dmiao, lhs} @mit.edu 1 Acknowledgements The authors would like to express their gratitude towards Danny Weitzner, Peter Lord, Hal Abelson, and Alan Davidson for their valuable guidance, mentorship and feedback on this paper. This work could have not been completed without their arduous support. This paper also benefits significantly from the expertise of Jessie Stickgold-Sarah, Michael Trice and Anna Wexler. Their advice on general argument formation was crucial to the success of this work. 2 Table of Contents Executive Summary 1. Historical Background 1.1 Scale and Inefficient Routing Problems 1.2 Inefficient Routing Phenomenon 1.3 Background on Internet eXchange Points (IXPs) 1.4 IXPs Current State 2. Problem 2.1 Internet Connectivity 2.2 Past Cable Faults Case Studies 2.3 Cost of Latency and Loss of Connectivity 2.4 IXPs as More Secure Alternative for Local Traffic Exchange 3. Policy Recommendations 3.1 Relevance to ITU 3.2 Benefits of IXPs 3.3 Past Policies Regarding IXPs 3.4 Specific Policy Recommendations: India and Bangladesh 4. Support for Policy Recommendations 4.1 Case study: Kenya 4.2 Case study: Singapore 4.3 Case Study: Brazil 5. Analysis of Policy Recommendations 5.1 Avoiding Balkanization of the Internet 5.2 Political Challenges for Implementation 5.3 Scalability of Local Replication 5.4 Effectiveness of the Local Replication 5.5 Privacy Issues 6.
    [Show full text]
  • Internet Traffic Exchange: Market Developments and Policy Challenges”, OECD Digital Economy Papers, No
    Please cite this paper as: Weller, D. and B. Woodcock (2013-01-29), “Internet Traffic Exchange: Market Developments and Policy Challenges”, OECD Digital Economy Papers, No. 207, OECD Publishing, Paris. http://dx.doi.org/10.1787/5k918gpt130q-en OECD Digital Economy Papers No. 207 Internet Traffic Exchange MARKET DEVELOPMENTS AND POLICY CHALLENGES Dennis Weller, Bill Woodcock Unclassified DSTI/ICCP/CISP(2011)2/FINAL Organisation de Coopération et de Développement Économiques Organisation for Economic Co-operation and Development 29-Jan-2013 ___________________________________________________________________________________________ English - Or. English DIRECTORATE FOR SCIENCE, TECHNOLOGY AND INDUSTRY COMMITTEE FOR INFORMATION, COMPUTER AND COMMUNICATIONS POLICY Unclassified DSTI/ICCP/CISP(2011)2/FINAL Cancels & replaces the same document of 17 October 2012 Working Party on Communication Infrastructures and Services Policy INTERNET TRAFFIC EXCHANGE MARKET DEVELOPMENTS AND POLICY CHALLENGES English - Or. English JT03333716 Complete document available on OLIS in its original format This document and any map included herein are without prejudice to the status of or sovereignty over any territory, to the delimitation of international frontiers and boundaries and to the name of any territory, city or area. DSTI/ICCP/CISP(2011)2/FINAL FOREWORD In June 2011, this report was presented to the Working Party on Communication Infrastructures and Services Policy (CISP) and was recommended to be made public by the Committee for Information, Computer and Communications Policy (ICCP) at its meeting in October 2011. The report was prepared by Dennis Weller of Navigant Economics and Bill Woodcock of Packet Clearing House. It is published on the responsibility of the Secretary General of the OECD. The statistical data for Israel are supplied by and under the responsibility of the relevant Israeli authorities.
    [Show full text]
  • 2016 Survey of Internet Carrier Interconnection Agreements
    P a c k e t C l e a r i n g H o u s e 5 7 2 B R u g e r S t r e e t , B o x 2 9 9 2 0 T h e P r e s i d i o o f S a n F r a n c i s c o S a n F r a n c i s c o , C a l i f o r n i a 9 4 1 2 9 - 0 9 2 0 U S A + 1 4 1 5 8 3 1 3 1 0 0 m a i n + 1 4 1 5 8 3 1 3 1 0 1 f a x 2016 Survey of Internet Carrier Interconnection Agreements Bill Woodcock Marco Frigino Packet Clearing House November 21, 2016 Introduction The Internet, or network of networks, consists of 7,557 Internet Service Provider (ISP) or carrier networks, which are interconnected in a sparse mesh.1 Each of the interconnecting links takes one of two forms: transit or peering. Transit agreements are commercial contracts in which, typically, a customer pays a service provider for access to the Internet; these agreements are most prevalent at the edges of the Internet, where the topology consists primarily of singly connected “leaf” networks that are principally concerned with the delivery of their own traffic. Transit agreements have been widely studied and are not the subject of this report. Peering agreements – the value-creation engine of the Internet – are the carrier interconnection agreements that allow carriers to exchange traffic bound for one another’s customers; they are most common in the core of the Internet, where the topology consists of densely interconnected networks that are principally concerned with the carriage of traffic on behalf of the networks which are their customers.
    [Show full text]
  • Computer Network and Security
    Internet and Intranet Lecture by: Jalauddin Mansur August 2015 1 Chapter 7: Internet and Intranet Applications Topics : • General Applications: Email, WWW, Gopher, Online Systems • Multimedia and Digital Video/Audio Broadcasting: Video/Audio Conferencing, Internet Relay Chat (IRC) • Broadband Communications, Policy, xDSL and Cable Internet • VoIP, FoIP and IP Interconnection • Data Centers and Data Warehousing, Packet Clearing House • Unified Messaging Systems • Fundamental e-commerce • Concept of Grid and Cloud Computing 2 Gopher • The Gopher protocol is a TCP/IP application layer protocol designed for distributing, searching, and retrieving documents over the Internet. • Strongly oriented towards a menu-document design, the Gopher protocol presented an attractive alternative to the World Wide Web in its early stages, but ultimately failed to achieve popularity. • The protocol offers some features not natively supported by the Web and imposes a much stronger hierarchy on information stored on it. • More recent Gopher revisions and graphical clients added support for multimedia. 3 • Gopher was preferred by many network administrators for using fewer network resources than Web services. • With its hierarchical structure, Gopher provided a useful platform for the first large-scale electronic library connections. • Gopher users remember the system as being faster and more efficient and so much more organized than today's Web services. • Example: . Veronica is a search engine system for the Gopher protocol, developed in 1992 by Steven Foster and Fred Barrie at the University of Nevada, Reno. Veronica is a constantly updated database of the names of almost every menu item on thousands of Gopher servers. The Veronica database can be searched from most major Gopher menus.
    [Show full text]
  • Localizing Internet Infrastructure: Cooperative Peering in Latin America
    Telematics and Informatics 33 (2016) 631–640 Contents lists available at ScienceDirect Telematics and Informatics journal homepage: www.elsevier.com/locate/tele Localizing Internet infrastructure: Cooperative peering in Latin America Hernán Galperín University of Southern California, 3502 Watt Way, Los Angeles, CA 90089, United States article info abstract Article history: This paper offers an overview of the changes in the Internet interconnection regime in the Received 7 March 2014 past decade and their key implications for the development of Internet infrastructure in Received in revised form 26 May 2015 developing regions based on the Latin American experience. The main argument presented Accepted 19 August 2015 is that changes in market conditions and Internet traffic patterns over the past decade have Available online 28 August 2015 favored the search for new interconnection arrangements between actors located at the outer edges of the traditional Internet topology. Driven by the need to control operating Keywords: costs and optimize content delivery to end-users, network operators in Latin America Internet interconnection (and elsewhere in developing regions) are increasingly experimenting with cooperative Development Latin America peering arrangements to meet interconnection needs. The evidence suggests that these Cooperative models new arrangements are resulting in multiple benefits to local Internet ecosystems, among them reduced transit costs, greater network redundancy, improved service quality, new infrastructure investments and better technical coordination among operators. Ó 2015 Elsevier Ltd. All rights reserved. 1. Introduction As a network of networks, the Internet critically depends on adequate arrangements for traffic exchange between the different participants in the Internet ecosystem. These interconnection contracts have changed significantly over the past decades, driven by changes in policy frameworks, in the scale of Internet traffic and its patterns, and in the goals and incentives of participating actors.
    [Show full text]
  • Infrastructure, Innovation, and the Digital Divide in Asia: Lessons from Internet Production History
    Infrastructure, Innovation, and the Digital Divide in Asia: Lessons from Internet Production History Version 1.0 September, 2005 Tom Vest Packet Clearing House Rising official, public Interest in the Internet and Internet policy Some interest predicated on sovereignty issues/claims Some predicated on concerns about economic development, differential growth rates, e.g., the Digital Divide de regia non est disputandum, but... By definition, sovereignty issues are domain of pure politics Issues of economics and development are different -- research, data, facts can play a useful role... i.e., only 50% politics... The Internet routing table: A rich resource for policy research Digital Divide often defined in terms of asymmetrical growth in: i.e., subscribers, Users opportunistic users i.e., time online, Usage multiple access methods i.e., diversity of content Uses and services...and value ...with “asymmetry” defined by means of nationalUsers comparisons Internet routing table(s) informs these questions in the aggregate(s) + + e scaling factors policy era-specific factors Users, Usage Uses growth slack/inefficiency = IP addresses injected into the Internet routing table by an individual ISP/network operator Where to count Internet production? e Each router connected maintains a local view of paths leading to e every Internet resource e e e Each of those views router may vary substantially e in almost every way e e -- except one: e e e All will share a common view of the network of AS Autonomous System origination for each Internet resource* e
    [Show full text]
  • The Real-Time Internet Routing Observatory
    the real-time Internet routing observatory Luca Sani TOP-IX MEETING, 26 September 2017 1/22 Our research interest: the Internet AS-level ecosystem Why is it important? To identify Internet topological properties and drawbacks To build realistic network topology generators for simulations To evaluate the effectiveness of new protocols 2/22 Classic BGP route collector concept Route collectors are devices which collects BGP routing data from co-operating ASes (feeders) Route collectors collect routing information and not user traffic 3/22 BGP route collector projects University of Oregon Route Views Project Route Views was originally conceived as a tool for Internet operators to obtain real-time information about the global routing system from the perspectives of several different backbones and locations around the Internet. It collects BGP packets since 1997, in MRT format since 1997 http://www.routeviews.org RIPE NCC Routing Information Service (RIS) The RIPE NCC collects and stores Internet routing data from several locations around the globe, using RIS. It collects BGP packets in MRT format since 1999 https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris Packet Clearing House (PCH) PCH is the international organization responsible for providing operational support and security to critical Internet infrastructure, including Internet exchange points and the core of the domain name system. It operates route collectors at more than 100 IXPs around the world and its data is made available in MRT format since 2011 https://www.pch.net/resources/Raw
    [Show full text]
  • DNS Infrastructure Distribution
    DNS Infrastructure Distribution Steve Gibbard Packet Clearing House http://www.pch.net/ [email protected] Introduction Previous talk on importance of keeping critical infrastructure local. Without local infrastructure, local communications are subject to far away outages, costs, and performance. Critical infrastructure includes DNS. If a domain is critical, so is everything above it in the hierarchy. Sri Lanka a case in point. Root server placement Currently 110 root servers(?) Number is a moving target. Operated by 12 organizations. 13 IP addresses. (At most) 13 servers visible from any one place at any one time. Six are anycasted. Four are anycasted in large numbers. All remaining unicast roots are in the Bay Area, Los Angeles, or Washington, DC. Distribution by continent 34 in North America: 8 each in Bay Area/DC Area, 5 in Los Angeles. Only non-costal roots in US are in Chicago and Atlanta. 34 in Europe: Clusters of 4 each in London and Amsterdam, Europe’s biggest exchanges. Even throughout rest of Europe. Distribution by continent… 26 in Asia (excluding Middle East): 5 in Japan. 3 each in India, Korea, and Singapore. 2 each in Hong Kong, Jakarta, and Beijing. South Asia an area of rapid expansion. 6 in Australia/New Zealand: 2 in Brisbane. 1 each in Auckland, Perth, Sydney, and Wellington. Distribution by continent… 5 in Middle East: 1 each in Ankara, Tel Aviv, Doha, Dubai, and Abu Dhabi. 3 in Africa: 2 in Johannesburg 1 in Nairobi -- 1 more being shipped. Very little inter-city or inter-country connectivity. 2 in South America: Sao Paolo.
    [Show full text]
  • Toward Efficiencies in Canadian Internet Traffic Exchange
    Toward Efficiencies in Canadian Internet Traffic Exchange –!Bill Woodcock & Benjamin Edelman • By increasing the richness and density of connections between Canadian networks, additional IXPs will increase the reliability of Internet access in Canada and its resilience to disaster and attack. Short, fast, inexpensive path Canadian Canadian Canadian Canadian Canadian Internet Internet Service Internet Internet Service Internet Customer Provider Exchange Provider Customer Canada U.S. U.S. U.S. Internet Service Internet Long, slow, expensive path Provider Exchange The figure above shows alternative paths to connect two Canadian Internet customers. The top option shows a short, efficient, direct path via a Canadian Internet exchange point, whereas the bottom path detours via a US ISP and Internet exchange point. Relative to comparable international peers, Canada is well behind in its provision of IXPs. Canada currently has two operational IXPs (in Toronto and Ottawa) and three in planning – approximately one operational IXP per 17 million people, three to thirty times fewer than other similarly developed nations. A void of Canadian Internet strategy and policy has resulted in Canadian Internet users inheriting U.S. policy, costs, and flaws rather than enjoying an environment deliberately crafted to Canadian benefit. The provision of IXPs is not automatic: a network, or group of networks, must step up and take the lead in addressing the physical, managerial, and technical requirements. Moreover, the mere presence of an IXP is not sufficient to improve conditions; ISPs must actually make the effort to use them. Indeed, as many Canadian networks peer in London, UK, as in the existing exchange in Ottawa.
    [Show full text]
  • A Comparative Look Into Public IXP Datasets
    A Comparative Look into Public IXP Datasets Rowan Kloti¨ Bernhard Ager Vasileios Kotronis George Nomikos Xenofontas Dimitropoulos ETH Zurich, Switzerland FORTH, Greece frkloeti,bager,[email protected] fgnomikos,[email protected] ABSTRACT the global IXP ecosystem, namely the European Internet Exchange Internet eXchange Points (IXPs) are core components of the Inter- Association (Euro-IX) [3] and Packet Clearing House (PCH) [6]. net infrastructure where Internet Service Providers (ISPs) meet and These datasets are contributed and kept up-to-date by different stake- exchange traffic. During the last few years, the number and size of holders, e.g., by the publisher, or through self-reporting by the IXPs IXPs have increased rapidly, driving the flattening and shortening and their participants. of Internet paths. However, understanding the present status of the In this work, we do the first cross-comparison of the IXP data IXP ecosystem and its potential role in shaping the future Internet provided by PeeringDB, Euro-IX, and PCH. We compare in depth requires rigorous data about IXPs, their presence, status, partici- several attributes, like IXPs’ locations, facilities and participant pants, etc. In this work, we do the first cross-comparison of three information. We highlight the similarity of the available data, com- well-known publicly available IXP databases, namely of PeeringDB, plementary information, and data discrepancies. We analyze in total Euro-IX, and PCH. A key challenge we address is linking IXP iden- data from about 499, 490, and 687 IXPs in PeeringDB, Euro-IX, tifiers across databases maintained by different organizations. We and PCH, respectively.
    [Show full text]
  • Internet Infrastructure Development and Protection in an Intern
    Design and Deployment of a Global Data-Collection Infrastructure Version 1.0 January, 2004 Bill Woodcock Packet Clearing House PCH Background • Started in 1993 and 1994 • 70% of the Internet was in California • 50% of Internet traffic both originated and terminated in California • 100% went through Washington D.C. • PCH formed to address that problem • Went on to assist in other places PCH Goals • Uphold the core values of the Internet: unconstrained access and sound engineering. • Support the Internet operations community through training, policy development, and the creation and maintenance of tools. • Support the research and academic community through data collection, dissemination of information, and mediation with sources. PCH Principal Projects • Internet Exchanges • Internet Routing Topology Archive • INOC-DBA hotline phone system • PeerMaster Designing a Platform • Assess needs • Fix minimum requirements • Design a platform architecture • Components • Node • Topology • Prototype and test Assess Needs • Support an Internet Exchange • Route-server / Looking-glass • Switch ports or spares • Perform data collection • Perform data collection • Host experiments • Host services Minimum Criteria • BGP routing, many views • IPv4, IPv6 • Unicast, anycast, multicast • Data collection, spooling, reduction • DNS, HTTP, SMTP, NTP • Secure remote management Specifying an Equipment Package • Many, many tradeoffs: • Cost versus scalability • Broad range of capability versus cost • Specific strengths versus breadth of capability • Size, weight, heat, power, redundancy • Modernity versus availability Uniformity Deployment Considerations • Weight thresholds • Dimension thresholds • Apparent value • Consumables and disposable tools • Sparing Local Participation Katmandu, Nepal Maputo, Mozambique Topology • Redundant transit at every location • Tunnel mesh • Redundant private hubs Current Data-Collection Footprint Stockholm Seattle London Vienna San Francisco Palo Alto New York Katmandu Los Angeles Washington D.C.
    [Show full text]
  • A Comparative Look Into Public IXP Datasets
    • • Public Review for • • • A Comparative Look into Public IXP • • Datasets • • Rowan Klöti, Bernhard Ager, Vasileios Kotronis, • • George Xenofontas, and Xenofontas Dimitropoulos • • • • The topic of Internet eXchange Points (IXPs) has attracted growing interest in the last few years as • our community becomes aware of their increasingly central role in the Internet, from interdomain • connectivity and overall network structure to performance and economics. Anyone starting to look • • at the topic (there’s plenty to take on) quickly becomes aware of the dearth of publicly available • information, the value of three main datasets – from PeeringDB, the European Internet Exchange • Association (Euro-IX) and the Packet Clearing House (PCH), and the pain that dealing with them • • entails. For the intrepid, this article should ease some of that pain. • The authors present the first analysis and detailed cross-comparison of these three public datasets. • • They analyze data from between 500 and 700 IXPs found in each of the different sources and high- • light the similarities, complementary information and discrepancies they found. For those consid- • • ering doing work in the area, the authors are also sharing the combined data as well as the code used • for data collection and analysis. • • Not everything is resolved, of course, and there is still much pain to cope with. The reviewers point • to the fact that the sources are far from rigorous, manual inspection is needed and question the abil- • ity of the code to handle discrepancies that exist between the different datasets. As the authors note, • • a fully automated approach to linking all IXPs may not be desirable given the many ambiguous • mappings (one of my favorites – “SIX” occurs as an identifier with minor variations 5 times in • • PeeringDB with the “S” standing alternatively for Seattle, Stuttgart, Slovak, Slovenia and • Stavanger, all of them different IXPs!).
    [Show full text]