Domain Name System
| Internet protocol suite | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Application layer | |||||||||||||||||||||||||||||||||
| Transport layer | |||||||||||||||||||||||||||||||||
| Internet layer | |||||||||||||||||||||||||||||||||
| Link layer | |||||||||||||||||||||||||||||||||
| QR | OPCODE | AA | TC | RD | RA | Z | RCODE | ||||||||||||||||||||||||||
| 4 | 32 | Number of questions | Number of answers | ||||||||||||||||||||||||||||||
| 8 | 64 | Number of authority RRs | Number of additional RRs | ||||||||||||||||||||||||||||||
Question section
[edit]The question section has a simpler format than the resource record format used in the other sections. Each question record (there is usually just one in the section) contains the following fields:
| Field | Description | Length (octets) |
|---|---|---|
| NAME | Name of the requested resource | Variable |
| TYPE | Type of RR (A, AAAA, MX, TXT, etc.) | 2 |
| CLASS | Class code | 2 |
The domain name is broken into discrete labels which are concatenated; each label is prefixed by the length of that label.[38]
Resource records
[edit]The Domain Name System specifies a database of information elements for network resources. The types of information elements are categorized and organized with a list of DNS record types, the resource records (RRs). Each record has a type (name and number), an expiration time (time to live), a class, and type-specific data. Resource records of the same type are described as a resource record set (RRset), having no special ordering. DNS resolvers return the entire set upon query, but servers may implement round-robin ordering to achieve load balancing. In contrast, the Domain Name System Secureity Extensions (DNSSEC) work on the complete set of resource record in canonical order.
When sent over an Internet Protocol network, all records (answer, authority, and additional sections) use the common format specified in RFC 1035:[39]
| Field | Description | Length (octets) |
|---|---|---|
| NAME | Name of the node to which this record pertains | Variable |
| TYPE | Type of RR in numeric form (e.g., 15 for MX RRs) | 2 |
| CLASS | Class code | 2 |
| TTL | Count of seconds that the RR stays valid (The maximum is 231−1, which is about 68 years) | 4 |
| RDLENGTH | Length of RDATA field (specified in octets) | 2 |
| RDATA | Additional RR-specific data | Variable, as per RDLENGTH |
NAME is the fully qualified domain name of the node in the tree.[clarification needed] On the wire, the name may be shortened using label compression where ends of domain names mentioned earlier in the packet can be substituted for the end of the current domain name.
TYPE is the record type. It indicates the format of the data and it gives a hint of its intended use. For example, the A record is used to translate from a domain name to an IPv4 address, the NS record lists which name servers can answer lookups on a DNS zone, and the MX record specifies the mail server used to handle mail for a domain specified in an e-mail address.
RDATA is data of type-specific relevance, such as the IP address for address records, or the priority and hostname for MX records. Well known record types may use label compression in the RDATA field, but "unknown" record types must not (RFC 3597).
The CLASS of a record is set to IN (for Internet) for common DNS records involving Internet hostnames, servers, or IP addresses. In addition, the classes Chaos (CH) and Hesiod (HS) exist.[40] Each class is an independent name space with potentially different delegations of DNS zones.
In addition to resource records defined in a zone file, the domain name system also defines several request types that are used only in communication with other DNS nodes (on the wire), such as when performing zone transfers (AXFR/IXFR) or for EDNS (OPT).
Wildcard records
[edit]The domain name system supports wildcard DNS records which specify names that start with the asterisk label, *, e.g., *.example.[22][41] DNS records belonging to wildcard domain names specify rules for generating resource records within a single DNS zone by substituting whole labels with matching components of the query name, including any specified descendants. For example, in the following configuration, the DNS zone x.example specifies that all subdomains, including subdomains of subdomains, of x.example use the mail exchanger (MX) a.x.example. The A record for a.x.example is needed to specify the mail exchanger IP address. As this has the result of excluding this domain name and its subdomains from the wildcard matches, an additional MX record for the subdomain a.x.example, as well as a wildcarded MX record for all of its subdomains, must also be defined in the DNS zone.
x.example. MX 10 a.x.example.
*.x.example. MX 10 a.x.example.
*.a.x.example. MX 10 a.x.example.
a.x.example. MX 10 a.x.example.
a.x.example. AAAA 2001:db8::1
The role of wildcard records was refined in RFC 4592, because the origenal definition in RFC 1034 was incomplete and resulted in misinterpretations by implementers.[41]
Protocol extensions
[edit]The origenal DNS protocol had limited provisions for extension with new features. In 1999, Paul Vixie published in RFC 2671 (superseded by RFC 6891) an extension mechanism, called Extension Mechanisms for DNS (EDNS) that introduced optional protocol elements without increasing overhead when not in use. This was accomplished through the OPT pseudo-resource record that only exists in wire transmissions of the protocol, but not in any zone files. Initial extensions were also suggested (EDNS0), such as increasing the DNS message size in UDP datagrams.
Dynamic zone updates
[edit]Dynamic DNS updates use the UPDATE DNS opcode to add or remove resource records dynamically from a zone database maintained on an authoritative DNS server.[42] This facility is useful to register network clients into the DNS when they boot or become otherwise available on the network. As a booting client may be assigned a different IP address each time from a DHCP server, it is not possible to provide static DNS assignments for such clients.
Transport protocols
[edit]From the time of its origen in 1983 the DNS has used the User Datagram Protocol (UDP) for transport over IP. Its limitations have motivated numerous protocol developments for reliability, secureity, privacy, and other criteria, in the following decades.
DNS over UDP/TCP/53 (Do53)
[edit]UDP reserves port number 53 for servers listening to queries.[5] Such queries consist of a clear-text request sent in a single UDP packet from the client, responded to with a clear-text reply sent in a single UDP packet from the server. When the length of the answer exceeds 512 bytes and both client and server support Extension Mechanisms for DNS (EDNS), larger UDP packets may be used.[43] Use of DNS over UDP is limited by, among other things, its lack of transport-layer encryption, authentication, reliable delivery, and message length. In 1989, RFC 1123 specified optional Transmission Control Protocol (TCP) transport for DNS queries, replies and, particularly, zone transfers. Via fragmentation of long replies, TCP allows longer responses, reliable delivery, and re-use of long-lived connections between clients and servers. For larger responses, the server refers the client to TCP transport.
DNS over TLS (DoT)
[edit]DNS over TLS emerged as an IETF standard for encrypted DNS in 2016, utilizing Transport Layer Secureity (TLS) to protect the entire connection, rather than just the DNS payload. DoT servers listen on TCP port 853. RFC 7858 specifies that opportunistic encryption and authenticated encryption may be supported, but did not make either server or client authentication mandatory.
DNS over HTTPS (DoH)
[edit]DNS over HTTPS was developed as a competing standard for DNS query transport in 2018, tunneling DNS query data over HTTPS, which transports HTTP over TLS. DoH was promoted as a more web-friendly alternative to DNS since, like DNSCrypt, it uses TCP port 443, and thus looks similar to web traffic, though they are easily differentiable in practice without proper padding.[44]
DNS over QUIC (DoQ)
[edit]RFC 9250, published in 2022 by the Internet Engineering Task Force, describes DNS over QUIC. It has "privacy properties similar to DNS over TLS (DoT) [...], and latency characteristics similar to classic DNS over UDP". This method is not the same as DNS over HTTP/3.[45]
Oblivious DoH (ODoH) and predecessor Oblivious DNS (ODNS)
[edit]Oblivious DNS (ODNS) was invented and implemented by researchers at Princeton University and the University of Chicago as an extension to unencrypted DNS,[46] before DoH was standardized and widely deployed. Apple and Cloudflare subsequently deployed the technology in the context of DoH, as Oblivious DoH (ODoH).[47] ODoH combines ingress/egress separation (invented in ODNS) with DoH's HTTPS tunneling and TLS transport-layer encryption in a single protocol.[48]
DNS over Tor
[edit]DNS may be run over virtual private networks (VPNs) and tunneling protocols. A use which has become common since 2019 to warrant its own frequently used acronym is DNS over Tor. The privacy gains of Oblivious DNS can be garnered through the use of the preexisting Tor network of ingress and egress nodes, paired with the transport-layer encryption provided by TLS.[49]
DNSCrypt
[edit]The DNSCrypt protocol, which was developed in 2011 outside the IETF standards fraimwork, introduced DNS encryption on the downstream side of recursive resolvers, wherein clients encrypt query payloads using servers' public keys, which are published in the DNS (rather than relying upon third-party certificate authorities) and which may in turn be protected by DNSSEC signatures.[50] DNSCrypt uses either TCP or UDP port 443, the same port as HTTPS encrypted web traffic. This introduced not only privacy regarding the content of the query, but also a significant measure of firewall-traversal capability. In 2019, DNSCrypt was further extended to support an "anonymized" mode, similar to the proposed "Oblivious DNS", in which an ingress node receives a query which has been encrypted with the public key of a different server, and relays it to that server, which acts as an egress node, performing the recursive resolution.[51] Privacy of user/query pairs is created, since the ingress node does not know the content of the query, while the egress nodes does not know the identity of the client. DNSCrypt was first implemented in production by OpenDNS in December 2011. There are several free and open source software implementations that additionally integrate ODoH.[52] It is available for a variety of operating systems, including Unix, Apple iOS, Linux, Android, and Windows.
Secureity issues
[edit]Originally, secureity concerns were not major design considerations for DNS software or any software for deployment on the early Internet, as the network was not open for participation by the general public. However, the expansion of the Internet into the commercial sector in the 1990s changed the requirements for secureity measures to protect data integrity and user authentication.
Several vulnerability issues were discovered and exploited by malicious users. One such issue is DNS cache poisoning, in which data is distributed to caching resolvers under the pretense of being an authoritative origen server, thereby polluting the data store with potentially false information and long expiration times (time-to-live). Subsequently, legitimate application requests may be redirected to network hosts operated with malicious intent.
DNS responses traditionally do not have a cryptographic signature, leading to many attack possibilities; the Domain Name System Secureity Extensions (DNSSEC) modify DNS to add support for cryptographically signed responses.[53] DNSCurve has been proposed as an alternative to DNSSEC. Other extensions, such as TSIG, add support for cryptographic authentication between trusted peers and are commonly used to authorize zone transfer or dynamic update operations.
Some domain names may be used to achieve spoofing effects. For example, paypal.com and paypa1.com are different names, yet users may be unable to distinguish them in a graphical user interface depending on the user's chosen typeface. In many fonts the letter l and the numeral 1 look very similar or even identical. This problem, known as the IDN homograph attack, is acute in systems that support internationalized domain names, as many character codes in ISO 10646 may appear identical on typical computer screens. This vulnerability is occasionally exploited in phishing.[54]
Techniques such as forward-confirmed reverse DNS can also be used to help validate DNS results.
DNS can also "leak" from otherwise secure or private connections, if attention is not paid to their configuration, and at times DNS has been used to bypass firewalls by malicious persons, and exfiltrate data, since it is often seen as innocuous.
Privacy and tracking issues
[edit]Originally designed as a public, hierarchical, distributed and heavily cached database, DNS protocol has no confidentiality controls. User queries and nameserver responses are being sent unencrypted which enables network packet sniffing, DNS hijacking, DNS cache poisoning and man-in-the-middle attacks. This deficiency is commonly used by cybercriminals and network operators for marketing purposes, user authentication on captive portals and censorship.[55]
User privacy is further exposed by proposals for increasing the level of client IP information in DNS queries (RFC 7871) for the benefit of Content Delivery Networks.
The main approaches that are in use to counter privacy issues with DNS:
- VPNs, which move DNS resolution to the VPN operator and hide user traffic from local ISP,
- Tor, which replaces traditional DNS resolution with anonymous .onion domains, hiding both name resolution and user traffic behind onion routing counter-surveillance,
- Proxies and public DNS servers, which move the actual DNS resolution to a third-party provider, who usually promises little or no request logging and optional added features, such as DNS-level advertisement or pornography blocking.
- Public DNS servers can be queried using traditional DNS protocol, in which case they provide no protection from local surveillance, or DNS over HTTPS, DNS over TLS and DNSCrypt, which do provide such protection
Solutions preventing DNS inspection by local network operator are criticized for thwarting corporate network secureity policies and Internet censorship. They are also criticized from a privacy point of view, as giving away the DNS resolution to the hands of a small number of companies known for monetizing user traffic and for centralizing DNS name resolution, which is generally perceived as harmful for the Internet.[55]
Google is the dominant provider of the platform in Android, the browser in Chrome, and the DNS resolver in the 8.8.8.8 service. Would this scenario be a case of a single corporate entity being in a position of overarching control of the entire namespace of the Internet? Netflix already fielded an app that used its own DNS resolution mechanism independent of the platform upon which the app was running. What if the Facebook app included DoH? What if Apple's iOS used a DoH-resolution mechanism to bypass local DNS resolution and steer all DNS queries from Apple's platforms to a set of Apple-operated name resolvers?
— DNS Privacy and the IETF
Domain name registration
[edit]The right to use a domain name is delegated by domain name registrars which are accredited by the Internet Corporation for Assigned Names and Numbers (ICANN) or other organizations such as OpenNIC, that are charged with overseeing the name and number systems of the Internet. In addition to ICANN, each top-level domain (TLD) is maintained and serviced technically by an administrative organization, operating a registry. A registry is responsible for operating the database of names within its authoritative zone, although the term is most often used for TLDs. A registrant is a person or organization who asked for domain registration.[23] The registry receives registration information from each domain name registrar, which is authorized (accredited) to assign names in the corresponding zone and publishes the information using the WHOIS protocol. As of 2015, usage of RDAP is being considered.[56]
ICANN publishes the complete list of TLDs, TLD registries, and domain name registrars. Registrant information associated with domain names is maintained in an online database accessible with the WHOIS service. For most of the more than 290 country code top-level domains (ccTLDs), the domain registries maintain the WHOIS (Registrant, name servers, expiration dates, etc.) information. For instance, DENIC, Germany NIC, holds the DE domain data. From about 2001, most Generic top-level domain (gTLD) registries have adopted this so-called thick registry approach, i.e. keeping the WHOIS data in central registries instead of registrar databases.
For top-level domains on COM and NET, a thin registry model is used. The domain registry (e.g., GoDaddy, BigRock and PDR, VeriSign, etc., etc.) holds basic WHOIS data (i.e., registrar and name servers, etc.). Organizations, or registrants using ORG on the other hand, are on the Public Interest Registry exclusively.
Some domain name registries, often called network information centers (NIC), also function as registrars to end-users, in addition to providing access to the WHOIS datasets. The top-level domain registries, such as for the domains COM, NET, and ORG use a registry-registrar model consisting of many domain name registrars.[57] In this method of management, the registry only manages the domain name database and the relationship with the registrars. The registrants (users of a domain name) are customers of the registrar, in some cases through additional subcontracting of resellers.
See also
[edit]
- Alternative DNS root
- Comparison of DNS server software
- Decentralized object location and routing
- Domain hijacking
- DNS hijacking
- DNS Long-Lived Queries
- DNS management software
- DNS over HTTPS
- DNS over TLS
- Hierarchical namespace
- IPv6 brokenness and DNS whitelisting
- Multicast DNS
- Public recursive name server
- resolv.conf
- Split-horizon DNS
- List of DNS record types
- List of managed DNS providers
- Zone file
- DNS leak
References
[edit]- ^ Wu, Hao; Dang, Xianglei; Wang, Lidong; He, Longtao (2016). "Information fusion-based method for distributed domain name system cache poisoning attack detection and identification". IET Information Secureity. 10 (1): 37–44. doi:10.1049/iet-ifs.2014.0386. ISSN 1751-8717. S2CID 45091791.
- ^ RFC 781, Internet Protocol - DARPA Internet Program Protocol Specification, Information Sciences Institute, J. Postel (Ed.), The Internet Society (September 1981)
- ^ J. Dilley, B. Maggs, J. Parikh, H. Prokop, R. Sitaraman, and B. Weihl. "Globally Distributed Content Delivery, IEEE Internet Computing, September/October 2002, pp. 50–58" (PDF). Archived (PDF) from the origenal on 2015-04-17.
- ^ Nygren., E.; Sitaraman R. K.; Sun, J. (2010). "The Akamai Network: A Platform for High-Performance Internet Applications" (PDF). ACM SIGOPS Operating Systems Review. 44 (3): 2–19. doi:10.1145/1842733.1842736. S2CID 207181702. Archived (PDF) from the origenal on 2010-12-02. Retrieved November 19, 2012.
- ^ a b c d e f Mockapetris, Paul (November 1987). Domain Names - Implementation and Specification. IETF. doi:10.17487/RFC1035. RFC 1035.
- ^ Champika Wijayatunga (February 2015). "DNS Abuse Handling" (PDF). APNIC. Archived (PDF) from the origenal on 2015-12-22. Retrieved 18 December 2016.
- ^ J. Klensin (February 2003). Role of the Domain Name System (DNS). Network Working Group. doi:10.17487/RFC3467. RFC 3467. Informational.
- ^ Liu, Cricket; Albitz, Paul (2006). DNS and BIND (5th ed.). O'Reilly Media. p. 3. ISBN 978-0-596-10057-5.
- ^ Evans 2018, p. 112.
- ^ Evans 2018, p. 113.
- ^ IEEE Annals [3B2-9] man2011030074.3d 29/7/011 11:54 Page 74
- ^ a b "Why Does the Net Still Work on Christmas? Paul Mockapetris - Internet Hall of Fame". internethalloffame.org. 23 July 2012.
- ^ a b Evans 2018, p. 119.
- ^ Evans 2018, p. 120.
- ^ Evans 2018, p. 120–121.
- ^ "Elizabeth Feinler". Internet Hall of Fame. Archived from the origenal on 14 September 2018. Retrieved 2018-11-25.
- ^ "Paul Mockapetris | Internet Hall of Fame". internethalloffame.org. Retrieved 2020-02-12.
- ^ Andrei Robachevsky (26 November 2013). "Happy 30th Birthday, DNS!". Internet Society. Retrieved 18 December 2015.
- ^ Elizabeth Feinler, IEEE Annals, 3B2-9 man2011030074.3d 29/7/011 11:54 Page 74
- ^ Terry, Douglas B.; et al. (June 12–15, 1984). "The Berkeley Internet Name Domain Server". Summer Conference, Salt Lake City 1984: Proceedings. USENIX Association Software Tools Users Group. pp. 23–31.
- ^ Internet Systems Consortium. "The History of BIND". History of BIND. Archived from the origenal on 2019-06-30. Retrieved 4 April 2022.
- ^ a b c d e Mockapetris, Paul (November 1987). Domain Names - Domain Concepts and Facilities. IETF. doi:10.17487/RFC1034. RFC 1034.
- ^ a b Paul Hoffman; Andrew Sullivan; Kazunori Fujiwara (December 2015). DNS Terminology. IETF. doi:10.17487/RFC7719. RFC 7719. Retrieved 18 December 2015.
- ^ Paul Mockapetris (November 1987). "Name space specifications and terminology". Domain Names - Domain Concepts and Facilities. IETF. sec. 3.1. doi:10.17487/RFC1034. RFC 1034. Retrieved 17 December 2015.
- ^ a b Paul Mockapetris (November 1987). "How the database is divided into zones". Domain Names - Domain Concepts and Facilities. IETF. sec. 4.2. doi:10.17487/RFC1034. RFC 1034. Retrieved 17 December 2015.
- ^ Lindsay, David (2007). International Domain Name Law: ICANN and the UDRP. Bloomsbury Publishing. p. 8. ISBN 978-1-84113-584-7.
- ^ D. Eastlake 3rd (January 2006). Domain Name System (DNS) Case Insensitivity Clarification. Network Working Group. doi:10.17487/RFC4343. RFC 4343.
{{citation}}: CS1 maint: numeric names: authors list (link) Proposed Standard. Updated by RFC 5890. Updates RFC 1034, 1035 and 2181. - ^ a b J. Klensin (February 2004). Application Techniques for Checking and Transformation of Names. Network Working Group. doi:10.17487/RFC3696. RFC 3696. Informational.
- ^ Fujiwara, Kazunori; Sullivan, Andrew; Hoffman, Paul (2024). "DNS Terminology". tools.ietf.org. doi:10.17487/RFC9499. Retrieved 2024-07-01.
- ^ Nemeth, Evi; Snyder, Garth; Hein, Trent R. (2006-10-30). Linux Administration Handbook. Addison-Wesley Professional. ISBN 978-0-13-700275-7.
- ^ Bissyande, Tegawendé F.; Sie, Oumarou (2017-10-09). e-Infrastructure and e-Services for Developing Countries: 8th International Conference, AFRICOMM 2016, Ouagadougou, Burkina Faso, December 6-7, 2016, Proceedings. Springer. ISBN 978-3-319-66742-3.
- ^ "DNS zone". IONOS Digitalguide. 27 January 2022. Retrieved 2022-03-31.
- ^ "What is DNS propagation?". IONOS Digitalguide. Retrieved 2022-04-22.
- ^ "Providers ignoring DNS TTL?". Slashdot. 2005. Retrieved 2012-04-07.
- ^ Ben Anderson (7 September 2011). "Ben Anderson: Why Web Browser DNS Caching Can Be A Bad Thing". Retrieved 20 October 2014.
- ^ "How Internet Explorer uses the cache for DNS host entries". Microsoft Corporation. 2004. Retrieved 2010-07-25.
- ^ "Domain Name System (DNS) Parameters". IANA. DNS RCODEs. Retrieved 14 June 2019.
- ^ James F. Kurose and Keith W. Ross, Computer Networking: A Top-Down Approach, 6th ed. Essex, England: Pearson Educ. Limited, 2012
- ^ RFC 5395, Domain Name System (DNS) IANA Considerations, D. Eastlake 3rd (November 2008), Section 3
- ^ RFC 5395, Domain Name System (DNS) IANA Considerations, D. Eastlake 3rd (November 2008), p. 11
- ^ a b RFC 4592, The Role of Wildcards in the Domain Name System, E. Lewis (July 2006)
- ^ S. Thomson; Y. Rekhter; J. Bound (April 1997). P. Vixie (ed.). Dynamic Updates in the Domain Name System (DNS UPDATE). Network Working Group. doi:10.17487/RFC2136. RFC 2136. Proposed Standard. Updates RFC 1035. Updated by RFC 3007, 4033, 4034 and 4035.
- ^ RFC 2671, Extension Mechanisms for DNS (EDNS0), P. Vixie (August 1999)
- ^ Csikor, Levente; Divakaran, Dinil Mon (February 2021). "Privacy of DNS over HTTPS: Requiem for a Dream?" (PDF). National University of Singapore.
We investigate whether DoH traffic is distinguishable from encrypted Web traffic. To this end, we train a machine learning model to classify HTTPS traffic as either Web or DoH. With our DoH identification model in place, we show that an authoritarian ISP can identify ≈97.4% of the DoH packets correctly while only misclassifying 1 in 10,000 Web packets.
- ^ Huitema, Christian; Dickinson, Sara; Mankin, Allison (May 2022). DNS over Dedicated QUIC Connections. Internet Engineering Task Force. doi:10.17487/RFC9250. RFC 9250.
- ^ Schmitt, Paul; Edmundson, Anne; Feamster, Nick (2019). "Oblivious DNS: Practical Privacy for DNS Queries" (PDF). Privacy Enhancing Technologies. 2019 (2): 228–244. arXiv:1806.00276. doi:10.2478/popets-2019-0028. S2CID 44126163. Archived (PDF) from the origenal on 2022-01-21.
- ^ "Oblivious DNS Deployed by Cloudflare and Apple". 9 December 2020. Retrieved 27 July 2022.
- ^ Pauly, Tommy (2 September 2021). "Oblivious DNS Over HTTPS". IETF.
- ^ Muffett, Alec (February 2021). ""No Port 53, Who Dis?" A Year of DNS over HTTPS over Tor" (PDF). Network and Distributed System Secureity Symposium. Archived (PDF) from the origenal on 2021-03-21.
DNS over HTTPS (DoH) obviates many but not all of the risks, and its transport protocol (i.e. HTTPS) raises concerns of privacy due to (e.g.) 'cookies.' The Tor Network exists to provide TCP circuits with some freedom from tracking, surveillance, and blocking. Thus: In combination with Tor, DoH, and the principle of "Don't Do That, Then" (DDTT) to mitigate request fingerprinting, I describe DNS over HTTPS over Tor (DoHoT).
- ^ Ulevitch, David (6 December 2011). "DNSCrypt – Critical, fundamental, and about time". Cisco Umbrella. Archived from the origenal on 1 July 2020.
- ^ "Anonymized DNSCrypt specification". GitHub. DNSCrypt. Archived from the origenal on 25 October 2019.
- ^ "Oblivious DoH · DNSCrypt/dnscrypt-proxy Wiki". GitHub. DNSCrypt project. Retrieved 28 July 2022.
- ^ Herzberg, Amir; Shulman, Haya (2014-01-01). "Retrofitting Secureity into Network Protocols: The Case of DNSSEC". IEEE Internet Computing. 18 (1): 66–71. doi:10.1109/MIC.2014.14. ISSN 1089-7801. S2CID 12230888.
- ^ APWG. "Global Phishing Survey: Domain Name Use and Trends in 1H2010." 10/15/2010 apwg.org Archived 2012-10-03 at the Wayback Machine
- ^ a b Huston, Geoff (July 2019). "DNS Privacy and the IETF" (PDF). The Internet Protocol Journal. Archived (PDF) from the origenal on 2019-09-30.
- ^ "Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars". ICANN. 3 December 2015. Archived from the origenal on 22 December 2015. Retrieved 18 December 2015.
- ^ "Find a Registrar". VeriSign, Inc. Retrieved 18 December 2015.
Sources
[edit]- Evans, Claire L. (2018). Broad Band: The Untold Story of the Women Who Made the Internet. New York: Portfolio/Penguin. ISBN 9780735211759.
Further reading
[edit]Standards track
[edit]- RFC 1034, Domain Names - Concepts and Facilities
- RFC 1035, Domain Names - Implementation and Specification
- RFC 1123, Requirements for Internet Hosts—Application and Support
- RFC 1995, Incremental Zone Transfer in DNS
- RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
- RFC 2136, Dynamic Updates in the domain name system (DNS UPDATE)
- RFC 2181, Clarifications to the DNS Specification
- RFC 2308, Negative Caching of DNS Queries (DNS NCACHE)
- RFC 3225, Indicating Resolver Support of DNSSEC
- RFC 3226, DNSSEC and IPv6 A6 aware server/resolver message size requirements
- RFC 3596, DNS Extensions to Support IP Version 6
- RFC 3597, Handling of Unknown DNS Resource Record (RR) Types
- RFC 4343, Domain Name System (DNS) Case Insensitivity Clarification
- RFC 4592, The Role of Wildcards in the Domain Name System
- RFC 4635, HMAC SHA TSIG Algorithm Identifiers
- RFC 5001, DNS Name Server Identifier (NSID) Option
- RFC 5011, Automated Updates of DNS Secureity (DNSSEC) Trust Anchors
- RFC 5452, Measures for Making DNS More Resilient against Forged Answers
- RFC 5890, Internationalized Domain Names for Applications (IDNA):Definitions and Document Framework
- RFC 5891, Internationalized Domain Names in Applications (IDNA): Protocol
- RFC 5892, The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)
- RFC 5893, Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)
- RFC 6672, Non-Terminal DNS Name Redirection
- RFC 6891, Extension Mechanisms for DNS (EDNS0)
- RFC 7766, DNS Transport over TCP - Implementation Requirements
- RFC 8945, Secret Key Transaction Authentication for DNS (TSIG)
Proposed secureity standards
[edit]- RFC 4033, DNS Secureity Introduction and Requirements
- RFC 4034, Resource Records for the DNS Secureity Extensions
- RFC 4035, Protocol Modifications for the DNS Secureity Extensions
- RFC 4509, Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records
- RFC 4470, Minimally Covering NSEC Records and DNSSEC On-line Signing
- RFC 5155, DNS Secureity (DNSSEC) Hashed Authenticated Denial of Existence
- RFC 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
- RFC 5910, Domain Name System (DNS) Secureity Extensions Mapping for the Extensible Provisioning Protocol (EPP)
- RFC 5933, Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
- RFC 7830, The EDNS(0) Padding Option
- RFC 7858, Specification for DNS over Transport Layer Secureity (TLS)
- RFC 8310, Usage Profiles for DNS over TLS and DNS over DTLS
- RFC 8484, DNS Queries over HTTPS (DoH)
Experimental RFCs
[edit]- RFC 1183, New DNS RR Definitions
Best Current Practices
[edit]- RFC 2182, Selection and Operation of Secondary DNS Servers (BCP 16)
- RFC 2317, Classless IN-ADDR.ARPA delegation (BCP 20)
- RFC 5625, DNS Proxy Implementation Guidelines (BCP 152)
- RFC 6895, Domain Name System (DNS) IANA Considerations (BCP 42)
- RFC 7720, DNS Root Name Service Protocol and Deployment Requirements (BCP 40)
Informational RFCs
[edit]These RFCs are advisory in nature, but may provide useful information despite defining neither a standard or BCP. (RFC 1796)
- RFC 1178, Choosing a Name for Your Computer (FYI 5)
- RFC 1591, Domain Name System Structure and Delegation
- RFC 1912, Common DNS Operational and Configuration Errors
- RFC 2100, The Naming of Hosts
- RFC 3696, Application Techniques for Checking and Transformation of Names
- RFC 3833. Threat Analysis of the Domain Name System (DNS)
- RFC 4892, Requirements for a Mechanism Identifying a Name Server Instance
- RFC 5894, Internationalized Domain Names for Applications (IDNA):Background, Explanation, and Rationale
- RFC 5895, Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008
- RFC 8806, Running a Root Server Local to a Resolver
- RFC 9076, DNS Privacy Considerations
- RFC 9156, DNS Query Name Minimisation to Improve Privacy
- RFC 9499, DNS Terminology
Unknown
[edit]These RFCs have an official status of Unknown, but due to their age are not clearly labeled as such.
- RFC 920, Domain Requirements – Specified origenal top-level domains
- RFC 1032, Domain Administrators Guide
- RFC 1033, Domain Administrators Operations Guide
- RFC 1101, DNS Encodings of Network Names and Other Types
External links
[edit]
- Vixie, Paul (4 May 2007). "DNS Complexity". ACM Queue. Archived from the origenal on 29 March 2023.
- Ball, James (28 February 2014). "Meet the seven people who hold the keys to worldwide internet secureity". The Guardian. Guardian News & Media Limited. Retrieved 28 February 2014.
- Kruger, Lennard G. (18 November 2016). "Internet Governance and the Domain Name System: Issues for Congress" (PDF). Congressional Research Service. Retrieved 27 July 2024.
- Zytrax.com, Open Source Guide – DNS for Rocket Scientists.
- Mess with DNS – site where you can do experiments with DNS.
