Dns Applications and Resource Records
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
RFC 2168 Resolution of Uris Using the DNS June 1997
Network Working Group R. Daniel Request for Comments: 2168 Los Alamos National Laboratory Category: Experimental M. Mealling Network Solutions, Inc. June 1997 Resolution of Uniform Resource Identifiers using the Domain Name System Status of this Memo =================== This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Abstract: ========= Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). The requirements document for URN resolution systems[15] defines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. -
XEP-0347: Internet of Things - Discovery
XEP-0347: Internet of Things - Discovery Peter Waher mailto:peterwaher@hotmail:com xmpp:peter:waher@jabber:org http://www:linkedin:com/in/peterwaher Ronny Klauck mailto:rklauck@informatik:tu-cottbus:de xmpp:TBD http://www-rnks:informatik:tu-cottbus:de/~rklauck 2018-11-03 Version 0.5.1 Status Type Short Name Deferred Standards Track iot-discovery This specification describes an architecture based on the XMPP protocol whereby Things can be in- stalled and safely discovered by their owners and connected into networks of Things. Legal Copyright This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the ”Specification”), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specifi- cation, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or sub- stantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or pub- lisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. Warranty ## NOTE WELL: This Specification is provided on an ”AS IS” BASIS, WITHOUT WARRANTIES OR CONDI- TIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. -
A Survey of DNSSEC Deployment in the US R&E Community
A survey of DNSSEC deployment in the U.S. R&E community Shumon Huque; University of Pennsylvania Bill Owens; NySERNET Joint Techs Conference, Stanford University, July 16th 2012 http://events.internet2.edu/2012/jt-stanford/ 1 Abstract: DNSSEC (DNS Security Extensions) is a system to verify the authenticity of DNS data using public key signatures. Although a small number of institutions in the R&E community have been at the forefront of DNSSEC deployment, the adoption rate in the larger community is still quite low. This talk will present some results of an ongoing project to survey the status of DNSSEC deployment in the US Research & Education and a few other communities. It also surveys the status of several other DNS capabilities, such as availability of the service over IPv6 transport, TCP transport, EDNS0 support, etc. [Joint Techs, Stanford University, Jul 2012] 2 Agenda • DNSSEC deployment monitoring project overview • Live demo of the website • New uses of DNSSEC by applications (DANE/TLSA etc) • (time permitting) [Joint Techs, Stanford University, Jul 2012] 3 DNSSEC at a glance • “DNS Security Extensions” • A system to verify the authenticity of DNS “data” using public key signatures • Specs: RFC 4033, 4034, 4035, 5155 (and more) • Helps detect DNS spoofing, misdirection, cache poisoning .. • Additional benefits: • Ability to store and use cryptographic keying material in the DNS, eg. SSHFP, IPSECKEY, CERT, DKIM, TLSA, etc .. [Joint Techs, Stanford University, Jul 2012] 4 Other surveys • SecSpider • http://secspider.cs.ucla.edu/ -
XEP-0156: Discovering Alternative XMPP Connection Methods
XEP-0156: Discovering Alternative XMPP Connection Methods Joe Hildebrand Peter Saint-Andre Lance Stout mailto:jhildebr@cisco:com mailto:xsf@stpeter:im mailto:lance@andyet:com xmpp:hildjj@jabber:org xmpp:peter@jabber:org xmpp:lance@lance:im http://stpeter:im/ 2020-07-07 Version 1.3.1 Status Type Short Name Draft Standards Track alt-connections This document defines an XMPP Extension Protocol for discovering alternative methods of connecting to an XMPP server using two ways: (1) DNS TXT Resource Record format; and (2) Web Host Metadata Link format. Legal Copyright This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the ”Specification”), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specifi- cation, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or sub- stantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or pub- lisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. Warranty ## NOTE WELL: This Specification is provided on an ”AS IS” BASIS, WITHOUT WARRANTIES OR CONDI- TIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. -
1912 the Pennsylvania State University Obsoletes: 1537 February 1996 Category: Informational
Network Working Group D. Barr Request for Comments: 1912 The Pennsylvania State University Obsoletes: 1537 February 1996 Category: Informational Common DNS Operational and Configuration Errors Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain. This memo tries to summarize current Internet requirements as well as common practice in the operation and configuration of the DNS. This memo also tries to summarize or expand upon issues raised in [RFC 1537]. 1. Introduction Running a nameserver is not a trivial task. There are many things that can go wrong, and many decisions have to be made about what data to put in the DNS and how to set up servers. This memo attempts to address many of the common mistakes and pitfalls that are made in DNS data as well as in the operation of nameservers. Discussions are also made regarding some other relevant issues such as server or resolver bugs, and a few political issues with respect to the operation of DNS on the Internet. 2. DNS Data This section discusses problems people typically have with the DNS data in their nameserver, as found in the zone data files that the nameserver loads into memory. 2.1 Inconsistent, Missing, or Bad Data Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious. -
DNS/ENUM Guidelines for Service Providers & GRX/IPX
GSM Association Non Confidential Official Document IR.67 IR.67 - DNS/ENUM Guidelines for Service Providers & GRX/IPX Providers 6.0 1 December 2011 This is a non-binding permanent reference document of the GSM Association. Security Classification – NON-CONFIDENTIAL GSMA Material Copyright Notice Copyright © 2011 GSM Association Antitrust Notice The information contain herein is in full compliance with the GSM Association’s antitrust compliance policy. V6.0 Page 1 of 78 GSM Association Non Confidential Official Document IR.67 Table of Contents IR.67 - DNS/ENUM Guidelines for Service Providers & GRX/IPX Providers .......... 1 6.0 ............................................................................................................................... 1 1 December 2011 ....................................................................................................... 1 1 Introduction ...................................................................................................... 5 1.1 Overview ..................................................................................................... 5 1.2 Scope .......................................................................................................... 5 1.3 Definition of Acronyms and Abbreviations ................................................... 5 1.4 Definition of Terms ...................................................................................... 6 1.5 Document Cross-References ...................................................................... 7 2 DNS -
Technical Realization of Communication Networks
TECHNISCHE UNIVERSITAT ••• WIEN • • • institute of Vienna University of Technology • e • telecommunications Lecture Notes Technical Realization of Communication Networks Course Number: 388.031 Part : Networking o. Univ. Prof. Dr. Hannen R. van As Institute of Telecommunications Vienna University of Technology 2011 2 CONTENTS 1.5.14 Adrnii;sion control 59 l.5.15 Flow control .... 60 1.5.16 Congestion control 61 1.6 Mobility 62 1. 7 Security . .. 63 Contents 2 Source and transmission coding 65 2.1 Introduction . 66 2.2 Source coding . 67 2.3 Linc coding aJJd modulation . 68 2.3.1 Binary coding . 69 1 Networking 1 2.3.2 I3lock <.'Oding .... 70 1.1 Network architecture . 2 2.3.3 Convolution coding . 71 1.1.1 Network planes . .. 2 2.4 Modulation . 72 1.1.2 Wired and wireless media 3 2.4.l OFDM ....... 73 1.1.3 Transmission . 3 2.4.2 CMSK .. .. ... 74 1.1.4 Switching . 9 2.5 System-related coding and tra.nsrnh;sion 75 1.1.5 Signaling and control . 13 2.5.1 PCM .......... .... 76 1.1.6 Network intelligence 14 1.1.7 Network management 14 3 Tuansmission 77 1.1.8 Service transport . 14 3.1 Introduction . 78 1.1.9 Communication and content services 14 3.2 Transmission media . 82 1.1.10 Technological layering 14 3.2.l CoaxiaJ cable 82 1.1.11 Geographical areas 15 3.2.2 Copper twisted pair 82 1.2 Protocol Architecture 19 3.2.3 Fiber . 83 1.3 Network protocols 23 3.2.4 Free-space optic link 83 1.4 Network availability 27 3.2.5 Frequency spcctmrn 83 1.5 Network control . -
March 22, 2006 Marlene H. Dortch Federal Communications Commission Office of the Secretary 445 12Th Street, SW Washington, DC 2
1875 K Street, NW Washington, DC 20006 Tel: 202 303 1000 Fax: 202 303 2000 March 22, 2006 Marlene H. Dortch Federal Communications Commission Office of the Secretary 445 12th Street, SW Washington, DC 20554 Re: In re Telecommunications Relay Services and Speech-to-Speech Services for Individuals with Hearing and Speech Disabilities; Petition for Declaratory Ruling on Video Relay Service Interoperability, CG Docket No. 03-123 Dear Ms. Dortch: On March 20, 2006, representatives of Snap Telecommunications, Inc. (“Snap”), Aequus Technologies Corp. (“Aequus”), and WorldGate Communications, Inc. (“WorldGate”) met with Tom Chandler, Chief, Disability Rights Office; Jay Keithley, Deputy Bureau Chief, Consumer & Governmental Affairs Bureau; Greg Hlibok, Disability Rights Office; and Sharon Diskin, Office of the General Counsel. Also attending the meeting were David Dinin, President, Aequus; Daryl Crouse, President and Founder, Snap; Randy Gort, General Counsel, WorldGate; Richard Westerfer, Chief Operating Officer and Senior Vice-President, WorldGate; and the undersigned. During the meeting, the parties supported the petition in the above-captioned proceeding and opposed restrictive marketing practices, IP blocking, or other techniques by a VRS provider designed to prevent a hearing-impaired individual from placing a VRS call to a different VRS provider. However, the parties also cautioned the Commission to avoid the adoption of requirements in this proceeding that could have the inadvertent effect of impeding the ability of new or existing VRS providers from introducing VRS equipment and services implementing the newer and more robust open standard called Session Initiation Protocol (“SIP”). The parties described the benefits of SIP in providing functionally equivalent service for the hearing-impaired community, the fact that SIP is increasingly being embraced as the standard of choice in the video phone and VoIP arenas, and that SIP is the focus of significant efforts by various industry players to establish E-911 solutions for VoIP and VRS. -
ENUM Guidelines for Service Providers and IPX Providers
GSM Association Non-confidential Official Document NG.105 - ENUM Guidelines for Service Providers and IPX Providers ENUM Guidelines for Service Providers and IPX Providers Version 1.1 28 May 2018 This is a Non-binding Permanent Reference Document of the GSMA Security Classification: Non-confidential Access to and distribution of this document is restricted to the persons permitted by the security classification. This document is confidential to the Association and is subject to copyright protection. This document is to be used only for the purposes for which it has been supplied and information contained in it must not be disclosed or in any other way made available, in whole or in part, to persons other than those permitted under the security classification without the prior written approval of the Association. Copyright Notice (Test) Copyright © 2018 GSM Association Disclaimer The GSM Association (“Association”) makes no representation, warranty or undertaking (express or implied) with respect to and does not accept any responsibility for, and hereby disclaims liability for the accuracy or completeness or timeliness of the information contained in this document. The information contained in this document may be subject to change without prior notice. Antitrust Notice The information contain herein is in full compliance with the GSM Association’s antitrust compliance policy. V1.1 Page 1 of 55 GSM Association Non-confidential Official Document NG.105 - ENUM Guidelines for Service Providers and IPX Providers Table of Contents 1 Introduction -
Vitalqip® DNS/DHCP & IP Management Software ENUM
VitalQIP® DNS/DHCP & IP Management Software ENUM Manager Release 1.2 User’s Guide 190-409-067R7.1 Issue 1 August 2007 Alcatel-Lucent - Proprietary This document contains proprietary information of Alcatel-Lucent and is not to be disclosed or used except in accordance with applicable agreements. Copyright © 2007 Alcatel-Lucent. Unpublished and not for publication. All rights reserved. Copyright © 2007 Alcatel-Lucent. All Rights Reserved. This material is protected by the copyright laws of the United States and other countries. It may not be reproduced, distributed, or altered in any fashion by any entity (either internal or external to Alcatel-Lucent), except in accordance with applicable agreements, contracts, or licensing, without the express written consent of Alcatel-Lucent and the business management owner of the material. This material is protected by the copyright and trade secret laws of the United States and other countries. It may not be reproduced, distributed, or altered in any fashion by any entity (either internal or external to Alcatel-Lucent), except in accordance with applicable agreements, contracts, or licensing, without the express written consent of Alcatel-Lucent and the business management owner of the material. Trademarks All trademarks and service marks specified herein are owned by their respective companies. Licenses Apache This product includes software developed by the Apache Software Foundation (http:// www.apache.org/). Alcatel-Lucent - Proprietary See notice on first page. Contents About this document 1 ENUM -
4322 SSW Category: Informational D.H
Network Working Group M. Richardson Request for Comments: 4322 SSW Category: Informational D.H. Redelmeier Mimosa December 2005 Opportunistic Encryption using the Internet Key Exchange (IKE) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet Key Exchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well. As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance. Table of Contents 1. Introduction ....................................................3 1.1. Motivation .................................................3 1.2. Encryption Regimes .........................................4 1.3. Peer Authentication in Opportunistic Encryption ............4 1.4. Use of RFC 2119 Terms ......................................5 2. Overview ........................................................6 -
Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates Version 1.7.2
Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates Version 1.7.2 CA/Browser Forum 22 September, 2020 Copyright 2020 CA/Browser Forum This work is licensed under the Creative Commons Attribution 4.0 International license. Table of Contents 1. INTRODUCTION ................................................................................................................................................ 11 1.1 Overview ....................................................................................................................................................... 11 1.2 Document name and identification ................................................................................................... 11 1.2.1 Revisions .............................................................................................................................................. 12 1.2.2. Relevant Dates .................................................................................................................................. 15 1.3 PKI Participants ......................................................................................................................................... 17 1.3.1 Certification Authorities ................................................................................................................ 17 1.3.2 Registration Authorities ................................................................................................................ 17 1.3.3 Subscribers .........................................................................................................................................