DNS: Domain Name System a Scalable Naming System for the Internet
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Configuring DNS
Configuring DNS The Domain Name System (DNS) is a distributed database in which you can map hostnames to IP addresses through the DNS protocol from a DNS server. Each unique IP address can have an associated hostname. The Cisco IOS software maintains a cache of hostname-to-address mappings for use by the connect, telnet, and ping EXEC commands, and related Telnet support operations. This cache speeds the process of converting names to addresses. Note You can specify IPv4 and IPv6 addresses while performing various tasks in this feature. The resource record type AAAA is used to map a domain name to an IPv6 address. The IP6.ARPA domain is defined to look up a record given an IPv6 address. • Finding Feature Information, page 1 • Prerequisites for Configuring DNS, page 2 • Information About DNS, page 2 • How to Configure DNS, page 4 • Configuration Examples for DNS, page 13 • Additional References, page 14 • Feature Information for DNS, page 15 Finding Feature Information Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required. -
Reverse DNS What Is 'Reverse DNS'?
Reverse DNS Overview • Principles • Creating reverse zones • Setting up nameservers • Reverse delegation procedures What is ‘Reverse DNS’? • ‘Forward DNS’ maps names to numbers – svc00.apnic.net -> 202.12.28.131 • ‘Reverse DNS’ maps numbers to names – 202.12.28.131 -> svc00.apnic.net 1 Reverse DNS - why bother? • Service denial • That only allow access when fully reverse delegated eg. anonymous ftp • Diagnostics • Assisting in trace routes etc • SPAM identifications • Registration • Responsibility as a member and Local IR In-addr.arpa • Hierarchy of IP addresses – Uses ‘in-addr.arpa’ domain • INverse ADDRess • IP addresses: – Less specific to More specific • 210.56.14.1 • Domain names: – More specific to Less specific • delhi.vsnl.net.in – Reversed in in-addr.arpa hierarchy • 14.56.210.in-addr.arpa Principles • Delegate maintenance of the reverse DNS to the custodian of the address block • Address allocation is hierarchical – LIRs/ISPs -> Customers -> End users 2 Principles – DNS tree - Mapping numbers to names - ‘reverse DNS’ Root DNS net edu com arpa au apnic in-addr whoiswhois RIR 202202 203 210 211.. ISP 6464 22 .64.202 .in-addr.arpa Customer 2222 Creating reverse zones • Same as creating a forward zone file – SOA and initial NS records are the same as normal zone – Main difference • need to create additional PTR records • Can use BIND or other DNS software to create and manage reverse zones – Details can be different Creating reverse zones - contd • Files involved – Zone files • Forward zone file – e.g. db.domain.net • Reverse zone file – e.g. db.192.168.254 – Config files • <named.conf> – Other • Hints files etc. -
Rough Consensus and Running Code: Integrating Engineering Principles Into Internet Policy Debates
Federal Communications Law Journal Volume 63 Issue 2 Article 2 3-2011 Rough Consensus and Running Code: Integrating Engineering Principles into Internet Policy Debates Christopher S. Yoo University of Pennsylvania Follow this and additional works at: https://www.repository.law.indiana.edu/fclj Part of the Administrative Law Commons, Communications Law Commons, Computer and Systems Architecture Commons, Internet Law Commons, and the Legislation Commons Recommended Citation Yoo, Christopher S. (2011) "Rough Consensus and Running Code: Integrating Engineering Principles into Internet Policy Debates," Federal Communications Law Journal: Vol. 63 : Iss. 2 , Article 2. Available at: https://www.repository.law.indiana.edu/fclj/vol63/iss2/2 This Symposium is brought to you for free and open access by the Law School Journals at Digital Repository @ Maurer Law. It has been accepted for inclusion in Federal Communications Law Journal by an authorized editor of Digital Repository @ Maurer Law. For more information, please contact [email protected]. SYMPOSIUM INTRODUCTION Rough Consensus and Running Code: Integrating Engineering Principles into Internet Policy Debates Christopher S. Yoo* I. TUTORIAL ............................................. 343 II. THE CONTINUING DEBATE OVER NETWORK MANAGEMENT AND QUALITY OF SERVICE ........................... 344 III. CHANGING TECHNOLOGY AND THE LIMITS OF THE LAYERED AND END-TO-END MODELS ............ ............... 346 IV. ARCHITECTURE AND NETWORK SECURITY ..................... 349 V. KEYNOTE ADDRESS BY PAUL -
Ethereum Based Domain Name System Using Smart Contracts
ETHEREUM BASED DOMAIN NAME SYSTEM USING SMART CONTRACTS (BC-DNS) A Project Presented to the faculty of the Department of Computer Science California State University, Sacramento Submitted in partial satisfaction of the requirements for the degree of MASTER OF SCIENCE in Computer Science by Rodney Pinto SPRING 2019 © 2019 Rodney Pinto ALL RIGHTS RESERVED ii ETHEREUM BASED DOMAIN NAME SYSTEM USING SMART CONTRACTS (BC-DNS) A Project by Rodney Pinto Approved by: __________________________________, Committee Chair Dr. Jun Dai. __________________________________, Second Reader Dr. Xuyu Wang. ____________________________ Date iii Student: Rodney Pinto I certify that this student has met the requirements for format contained in the university format manual, and that this project is suitable for shelving in the library and credit is to be awarded for the project. __________________________, Graduate Coordinator ____________________ Dr. Jinsong Ouyang, Ph.D. Date Department of Computer Science iv Abstract of ETHEREUM BASED DOMAIN NAME SYSTEM USING SMART CONTRACTS (BC-DNS) by Rodney Pinto One of the most critical resources that ensure the current working of the internet is the domain name system (DNS). It is a decentralized, hierarchical naming system that is responsible for translating the human-readable domain name to its associated IP address. The use of DNS thus eliminates the need for humans to remember the IP address of all their favorite websites (such as 172.217.6.68 an IPV4 address for google.com). Despite its widespread use, DNS is vulnerable to various security issues. This project focuses on replicating the basic functionality of the existing DNS on the blockchain and deploying it on a peer to peer network making it completely decentralized and, in the process, make it a bit more secure and reliable by addressing few of the security vulnerabilities of the existing system. -
The Internet and Isi: Four Decades of Innovation
THE INTERNET AND ISI: FOUR DECADES OF INNOVATION ROD BECKSTROM President and Chief Executive Officer Internet Corporation for Assigned Names and Numbers (ICANN) 40th Anniversary of USC Information Sciences Institute 26 April 2012 As prepared for delivery It’s an honor to be here today to mark the 40th anniversary of the University of Southern California’s Information Sciences Institute. Thank you to Herb Schorr for inviting me to speak with you today and participate in the day’s events. When he steps down he will leave some very large shoes to fill. When I received Herb’s invitation, I seized upon it as an opportunity to come before you to express the sincere gratitude that my colleagues and I feel for the work and support of ISI. When I think of ICANN and its development, and all we have accomplished, I never forget that we stand upon the shoulders of giants, many of whom contributed to my remarks today. In fact, I owe a special debt of gratitude to Bob Kahn, who has been a mentor to me. I am honored that he took the time to walk through a number of details in the history I have been asked to relate. The organizers asked me to speak about the history of ISI and ICANN. They also invited me to talk a bit about the future of the Internet. In my role as President and CEO of ICANN, I have many speaking engagements that are forward looking. They are opportunities to talk about ICANN’s work and how it will usher in the next phase in the history of the global, unified Internet that many of you have helped to create. -
A History of Software Engineering in ICS at UC Irvine
Institute for Software Research University of California, Irvine A History of Software Engineering in ICS at UC Irvine Richard N. Taylor University of California, Irvine [email protected] October 2018 ISR Technical Report # UCI-ISR-18-5 Institute for Software Research ICS2 221 University of California, Irvine Irvine, CA 92697-3455 isr.uci.edu isr.uci.edu/publications A History of Software Engineering in ICS at UC Irvine UCI-ISR-18-5 Richard N. Taylor October 2018 Introduction A history of software engineering in ICS at UCI is a bit of a name game. The term “software engineering” was effectively coined in 1968, the same year that ICS began. But what research topics constitute software engineering has always been somewhat fluid. Nonetheless, the very first PhD student graduated by ICS was William Howden, who throughout his subsequent career as a professor was focused on a core SE topic, software testing. Software for the Internet has a long and strong history in ICS. From the creation of DNS by Paul Mockapetris through to the HTTP/1.1 protocol, the REST architectural style, and the Apache web server, software engineering concerns and approaches have been at the forefront. Indeed, a hallmark of SE research at UCI has been its interdisciplinary character; many of the key results were the consequence of looking at key software challenges in applied circumstances, such as the Internet, or as the result of working with researchers in other fields, such as human-computer interaction. Major software engineering topics at Irvine have included software reuse, programming environments, integrated software engineering environments, process, software safety, analysis and testing, security, design methods and tools, open source software, and software architecture. -
Service (SRV) Records
Service (SRV) Records You deploy multiple DNS SRV records in different locations on your enterprise DNS structure. Understand which records you should provision on which name servers. Review examples of SRV records to ensure a successful deployment. • Deploy SRV Records, page 1 • SRV Records, page 4 Deploy SRV Records The client queries name servers for records in the services domain. The services domain is determined as described in How the Client Discovers Available Services. You must deploy SRV records in each DNS zone for those service domains if your organization has multiple subsets of users who use different service domains. Deploy SRV Records in a Separate Domain Structure In a separate name design there are two domains, an internal domain and an external domain. The client queries for SRV records in the services domain. The internal name server must serve records for the services domain. However in a separate name design, a zone for the services domain might not exist on the internal name server. If the services domain is not currently served by the internal name server, you can: • Deploy records within an internal zone for the services domain. • Deploy records within a pinpoint subdomain zone on the internal name server. Use an Internal Zone for a Services Domain If you do not already have a zone for the services domain on the internal name server, you can create one. This method makes the internal name server authoritative for the services domain. Because it is authoritative, the internal name server does not forward queries to any other name server. -
The Consensus Protocol
8/5/2020 The Consensus Protocol FEATURE AUGUST 2020 The Consensus Protocol How a radical process, invented to build the ARPANET, spawned history's greatest tool for collaborative work BY STEVE CROCKER UCLA’s Boelter Hall housed one of the four original ARPANET nodes. ach March, July, and November, we are reminded that the Internet is not Equite the mature, stable technology that it seems to be. We rely on the Internet as an essential tool for our economic, social, educational, and political lives. But when the Internet Engineering Task Force meets every four months at an open conference that bounces from continent to continent, more than 1,000 people from around the world gather with change on their minds. Their vision of the global network that all humanity shares is dynamic, evolving, and continuously improving. Their efforts combine with the contributions of myriad others to ensure that the Internet always works but is never done, never complete. The rapid yet orderly evolution of the Internet is all the more remarkable considering the highly unusual way it happens: without a company, a government, or a board of directors in charge. Nothing about digital communications technology suggests that it should be self-organizing or, for that matter, fundamentally reliable. We enjoy an Internet that is both of those at once because multiple generations of network developers have embraced a principle and a https://read.nxtbook.com/ieee/spectrum/spectrum_na_august_2020/the_consensus_protocol.html?mkt_tok=eyJpIjoiTmpWh h b i i h hi f h l haVpXSmxOMll6TURZeSIsInQiOiIyc280i i l i h … 1/12 8/5/2020 The Consensus Protocol process that have been quite rare in the history of technology. -
ICANN, Ipv6 and the Root
ICANN, IPv6 and the Root John L. Crain Chief Technical Officer Beijing, China April 12, 2007 1 12 APRIL 2007 In the beginning . 2 12 APRIL 2007 Internet’s unique identifiers were coordinated through the Internet Address Naming Authority JonJon PostelPostel 19431943––19981998 3 12 APRIL 2007 Need for change circa 1996–97 • Globalisation of Internet • Commercialisation of Internet • Lack of competition in domain name space • Trademark–domain name conflicts • Need for a new model of governance 4 12 APRIL 2007 ICANN mission statement • To coordinate, overall, the global Internet's system of unique identifiers, and to ensure stable and secure operation of the Internet's unique identifier systems. In particular, ICANN coordinates: 1. Allocation and assignment of the three sets of unique identifiers for the Internet: • Domain names (forming a system called the DNS) • Internet protocol (IP) addresses and autonomous system (AS) numbers • Protocol port and parameter numbers 2. Operation and evolution of the DNS root name server system 3. Policy development reasonably and appropriately related to these technical functions 5 12 APRIL 2007 Principles of operation 1. Contribute to stability and security of the unique identifiers system and root management 2. Promote competition and choice for registrants and other users 3. Forum for multi-stakeholder bottom-up development of related policy 4. Ensuring on a global basis an opportunity for participation by all interested parties 6 12 APRIL 2007 The Secretariat (People doing the day to day work) 58 Staff from 26 Countries 7 12 APRIL 2007 • The secretariat’s work is administration and aiding policy processes. • We do not set policy, that is the job of the community. -
Identifier System Attack Mitigation Methodology DATE: 13 February 2017 Identifier System Attack Mitigation Methodology
Identifier System Attack Mitigation Methodology DATE: 13 February 2017 Identifier System Attack Mitigation Methodology Introduction This document is part of ICANN’s effort to contribute to enhancing the Stability, Security, and Resiliency (SSR) of the Internet’s system of unique identifiers (“Internet Identifiers”) by working with the Community to identify and increase awareness of related attacks and to promote broader adoption of attack mitigation practices. This effort also addresses Recommendation #12 of the Security, Stability & Resiliency (SSR) Review Team (SSR-RT) by creating an Identifier System Attack Mitigation Methodology. Specifically, this document identifies and prioritizes types of attacks against the Identifier System, providing a stepping-off point for ICANN to coordinate with the Community to develop a series of short technical documents (“Tech Notes”) on actual high-impact attacks and emerging high-risk vulnerabilities. This document will be periodically updated to reflect evolution of both the Identifier System and the cybercrime landscape, supporting on-going efforts within both ICANN and the Community to mitigate attacks that pose the greatest risk to Identifier System SSR. Authors: Lisa Phifer and David Piscitello Page 1 Identifier System Attack Mitigation Methodology DATE: 13 February 2017 Attack Mitigation Methodology ICANN is proposing a new Identifier System Attack Mitigation Methodology to: • Identify, prioritize, and periodically refresh a list of top Identifier System attacks; • Develop guidance on actual high-impact attacks and emerging high-risk vulnerabilities; • Describe corresponding attack mitigation practices that are commonly considered useful; and • Encourage broader adoption of those practices via contracts, agreements, incentives, etc. This document represents the first component of this methodology. -
DNS) Administration Guide
Edgecast Route (DNS) Administration Guide Disclaimer Care was taken in the creation of this guide. However, Edgecast cannot accept any responsibility for errors or omissions. There are no warranties, expressed or implied, including the warranty of merchantability or fitness for a particular purpose, accompanying this product. Trademark Information EDGECAST is a registered trademark of Verizon Digital Media Services Inc. About This Guide Route (DNS) Administration Guide Version 2.40 8/28/2021 ©2021 Verizon Media. All rights reserved. Table of Contents Route ............................................................................................................................................................. 1 Introduction .............................................................................................................................................. 1 Scope ......................................................................................................................................................... 1 Module Comparison ................................................................................................................................. 2 Managed (Primary) or Secondary DNS Module .................................................................................... 2 DNS Health Checks Module .................................................................................................................. 3 Billing Activation ...................................................................................................................................... -
Guidelines for the Secure Deployment of Ipv6
Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks NIST Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 December 2010 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Dr. Patrick D. Gallagher, Director GUIDELINES FOR THE SECURE DEPLOYMENT OF IPV6 Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-119 Natl. Inst. Stand. Technol. Spec. Publ. 800-119, 188 pages (Dec. 2010) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately.