Domain Name System - Revision history

imported>Kvng: restore Timeline of the history of the Internet. abc.

2025-12-26T15:16:04Z

restore Timeline of the history of the Internet. abc.

← Previous revision		Revision as of 15:16, 26 December 2025
Line 22:		Line 22:
	}}		}}
	{{IPstack}}		{{IPstack}}
	~~{{Internet history timeline}}~~

	The '''Domain Name System''' ('''DNS''') is a hierarchical and distributed [[name service]] that provides a naming system for [[computer]]s, services, and other resources on the Internet or other [[Internet Protocol]] (IP) networks. It associates various information with ''[[domain name]]s'' ([[identification (information)\|identification]] [[String (computer science)\|strings]]) assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical [[IP address]]es needed for locating and identifying computer services and devices with the underlying [[network protocol]]s.<ref>{{Cite journal \|last1=Wu \|first1=Hao \|last2=Dang \|first2=Xianglei \|last3=Wang \|first3=Lidong \|last4=He \|first4=Longtao \|date=2016 \|title=Information fusion-based method for distributed domain name system cache poisoning attack detection and identification \|url=https://onlinelibrary.wiley.com/doi/10.1049/iet-ifs.2014.0386 \|journal=IET Information Security \|language=en \|volume=10 \|issue=1 \|pages=37–44 \|doi=10.1049/iet-ifs.2014.0386 \|s2cid=45091791 \|issn=1751-8717\|url-access=subscription }}</ref> The Domain Name System has been an essential component of the functionality of the Internet since 1985.		The '''Domain Name System''' ('''DNS''') is a hierarchical and distributed [[name service]] that provides a naming system for [[computer]]s, services, and other resources on the Internet or other [[Internet Protocol]] (IP) networks. It associates various information with ''[[domain name]]s'' ([[identification (information)\|identification]] [[String (computer science)\|strings]]) assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical [[IP address]]es needed for locating and identifying computer services and devices with the underlying [[network protocol]]s.<ref>{{Cite journal \|last1=Wu \|first1=Hao \|last2=Dang \|first2=Xianglei \|last3=Wang \|first3=Lidong \|last4=He \|first4=Longtao \|date=2016 \|title=Information fusion-based method for distributed domain name system cache poisoning attack detection and identification \|url=https://onlinelibrary.wiley.com/doi/10.1049/iet-ifs.2014.0386 \|journal=IET Information Security \|language=en \|volume=10 \|issue=1 \|pages=37–44 \|doi=10.1049/iet-ifs.2014.0386 \|s2cid=45091791 \|issn=1751-8717\|url-access=subscription }}</ref> The Domain Name System has been an essential component of the functionality of the Internet since 1985.
Line 145:		Line 144:

	===Record caching===		===Record caching===
	A common approach to reduce the ~~burden~~ on DNS servers is to cache the results of name resolution locally or on intermediary resolver hosts. Each DNS query result comes with a time to live (TTL), which indicates how long the information remains valid before it needs to be discarded or refreshed. This TTL is determined by the administrator of the authoritative DNS server and can range from a few seconds to several days or even weeks.<ref>{{Cite web \|title=What is DNS propagation? \|url=https://www.ionos.com/digitalguide/server/know-how/dns-propagation/ \|access-date=2022-04-22 \|website=IONOS Digitalguide \|language=en}}</ref>		A common approach to reduce the query load on DNS servers is to cache the results of name resolution locally or on intermediary resolver hosts. Each DNS query result comes with a time to live (TTL), which indicates how long the information remains valid before it needs to be discarded or refreshed. This TTL is determined by the administrator of the authoritative DNS server and can range from a few seconds to several days or even weeks.<ref>{{Cite web \|title=What is DNS propagation? \|url=https://www.ionos.com/digitalguide/server/know-how/dns-propagation/ \|access-date=2022-04-22 \|website=IONOS Digitalguide \|language=en}}</ref>

	As a result of this distributed caching architecture, changes to DNS records do not propagate throughout the network immediately, but require all caches to expire and to be refreshed after the TTL. RFC 1912 conveys basic rules for determining appropriate TTL values.		As a result of this distributed caching architecture, changes to DNS records do not propagate throughout the network immediately, but require all caches to expire and to be refreshed after the TTL. RFC 1912 conveys basic rules for determining appropriate TTL values.
Line 324:		Line 323:
	===DNSCrypt===		===DNSCrypt===
	{{Main\|DNSCrypt}}		{{Main\|DNSCrypt}}
	The [[DNSCrypt]] protocol, which was developed in 2011 outside the [[Internet Engineering Task Force\|IETF]] standards framework, 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.<ref>{{Cite web \|last=Ulevitch \|first=David \|date=6 December 2011 \|title=DNSCrypt – Critical, fundamental, and about time. \|url=https://umbrella.cisco.com/blog/dnscrypt-critical-fundamental-and-about-time \|url-status=live \|archive-url=https://web.archive.org/web/20200701221715/https://umbrella.cisco.com/blog/dnscrypt-critical-fundamental-and-about-time \|archive-date=1 July 2020 \|website=Cisco Umbrella \|language=en-US}}</ref> DNSCrypt uses either TCP port 443, the same port as [[HTTPS]] encrypted web traffic, or UDP port 443. 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.<ref name="Anonymized DNSCrypt specification">{{Cite web \|title=Anonymized DNSCrypt specification \|url=https://raw.githubusercontent.com/DNSCrypt/dnscrypt-protocol/master/ANONYMIZED-DNSCRYPT.txt \|url-status=live \|archive-url=https://web.archive.org/web/20191025094649/https://raw.githubusercontent.com/DNSCrypt/dnscrypt-protocol/master/ANONYMIZED-DNSCRYPT.txt \|archive-date=25 October 2019 \|website=[[GitHub]] \|publisher=DNSCrypt}}</ref> 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.<ref name="ODoH_(2022)">{{cite web \|title=Oblivious DoH · DNSCrypt/dnscrypt-proxy Wiki \|url=https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Oblivious-DoH \|website=GitHub \|publisher=DNSCrypt project \|access-date=28 July 2022 \|language=en}}</ref> It is available for a variety of operating systems, including Unix, Apple iOS, Linux, Android, and Windows.		The [[DNSCrypt]] protocol, which was developed in 2011 outside the [[Internet Engineering Task Force\|IETF]] standards framework, 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.<ref>{{Cite web \|last=Ulevitch \|first=David \|date=6 December 2011 \|title=DNSCrypt – Critical, fundamental, and about time. \|url=https://umbrella.cisco.com/blog/dnscrypt-critical-fundamental-and-about-time \|url-status=live \|archive-url=https://web.archive.org/web/20200701221715/https://umbrella.cisco.com/blog/dnscrypt-critical-fundamental-and-about-time \|archive-date=1 July 2020 \|website=Cisco Umbrella \|language=en-US}}</ref> DNSCrypt uses either TCP port 443, the same port as [[HTTPS]] encrypted web traffic, or UDP port 443. 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.<ref name="Anonymized DNSCrypt specification">{{Cite web \|title=Anonymized DNSCrypt specification \|url=https://raw.githubusercontent.com/DNSCrypt/dnscrypt-protocol/master/ANONYMIZED-DNSCRYPT.txt \|url-status=live \|archive-url=https://web.archive.org/web/20191025094649/https://raw.githubusercontent.com/DNSCrypt/dnscrypt-protocol/master/ANONYMIZED-DNSCRYPT.txt \|archive-date=25 October 2019 \|website=[[GitHub]] \|publisher=DNSCrypt}}</ref> Privacy of user/query pairs is created, since the ingress node does not know the content of the query, while the egress node 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.<ref name="ODoH_(2022)">{{cite web \|title=Oblivious DoH · DNSCrypt/dnscrypt-proxy Wiki \|url=https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Oblivious-DoH \|website=GitHub \|publisher=DNSCrypt project \|access-date=28 July 2022 \|language=en}}</ref> It is available for a variety of operating systems, including Unix, Apple iOS, Linux, Android, and Windows.

	==Security issues==		==Security issues==
Line 361:		Line 360:

	{{Blockquote\|text=Google is the dominant provider of the platform in [[Android (operating system)\|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 Inc.\|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?\|sign=\|source=DNS Privacy and the IETF}}		{{Blockquote\|text=Google is the dominant provider of the platform in [[Android (operating system)\|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 Inc.\|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?\|sign=\|source=DNS Privacy and the IETF}}


	==Domain name registration==		==Domain name registration==
Line 378:		Line 376:
	* [[Comparison of DNS server software]]		* [[Comparison of DNS server software]]
	* [[Decentralized object location and routing]]		* [[Decentralized object location and routing]]
	* [[Domain hijacking]]
	* [[DNS hijacking]]		* [[DNS hijacking]]
			* [[DNS leak]]
	* [[DNS Long-Lived Queries]]		* [[DNS Long-Lived Queries]]
	* [[DNS management software]]		* [[DNS management software]]
	* [[DNS over HTTPS]]		* [[DNS over HTTPS]]
	* [[DNS over TLS]]		* [[DNS over TLS]]
			* [[Domain hijacking]]
	* [[Hierarchical namespace]]		* [[Hierarchical namespace]]
	* [[IPv6 brokenness and DNS whitelisting]]		* [[IPv6 brokenness and DNS whitelisting]]
			* [[List of DNS record types]]
			* [[List of managed DNS providers]]
	* [[Multicast DNS]]		* [[Multicast DNS]]
	* [[Public recursive name server]]		* [[Public recursive name server]]
	* [[resolv.conf]]		* [[resolv.conf]]
	* [[Split-horizon DNS]]		* [[Split-horizon DNS]]
	* [[~~List~~ of ~~DNS record types]]~~		* [[Timeline of the history of the Internet]]
	* [[List of ~~managed DNS providers~~]]
	* [[Zone file]]		* [[Zone file]]
	* [[DNS leak]]

	{{div col end}}		{{div col end}}

imported>Manveer.chawla: Added the citation

2025-11-09T00:30:36Z

Added the citation

← Previous revision		Revision as of 00:30, 9 November 2025
Line 3:		Line 3:
	{{Use American English\|date = February 2019}}		{{Use American English\|date = February 2019}}
	{{Infobox networking protocol		{{Infobox networking protocol
	\| title = Domain Name ~~Service~~		\| title = Domain Name System
	\| logo =		\| logo =
	\| logo alt =		\| logo alt =
Line 18:		Line 18:
	\| osilayer = [[Application layer]]		\| osilayer = [[Application layer]]
	\| ports = 53		\| ports = 53
	\| rfcs = RFC 1034~~, RFC~~ 1035		\| rfcs = {{IETF RFC\|1034\|1035\|plainlink=yes}}
	\| hardware =		\| hardware =
	}}		}}
Line 86:		Line 86:
	The hierarchy of domains descends from right to left; each label to the left specifies a subdivision, or [[subdomain]] of the domain to the right. For example, the label ''example'' specifies a subdomain of the ''com'' domain, and ''www'' is a subdomain of example.com. This tree of subdivisions may have up to 127 levels.<ref>{{Cite book\|title=International Domain Name Law: ICANN and the UDRP\|last=Lindsay\|first=David\|publisher=Bloomsbury Publishing\|year=2007\|isbn=978-1-84113-584-7\|pages=8}}</ref>		The hierarchy of domains descends from right to left; each label to the left specifies a subdivision, or [[subdomain]] of the domain to the right. For example, the label ''example'' specifies a subdomain of the ''com'' domain, and ''www'' is a subdomain of example.com. This tree of subdivisions may have up to 127 levels.<ref>{{Cite book\|title=International Domain Name Law: ICANN and the UDRP\|last=Lindsay\|first=David\|publisher=Bloomsbury Publishing\|year=2007\|isbn=978-1-84113-584-7\|pages=8}}</ref>

	A label may contain zero to 63 characters, because the length is only allowed to take 6 bits. The null label of length zero is reserved for the root zone. The full domain name may not exceed the length of 253 characters in its textual representation (or 254 with the trailing dot).<ref name=rfc1034/> In the internal binary representation of the DNS this maximum length of 253 requires 255 octets of storage, as it also stores the length of the first of many labels and adds last null byte.<ref name=rfc1035/> 255 length is only achieved with at least 6 labels (counting the last null label).~~{{Citation needed\|date~~=~~November 2024}}~~		A label may contain zero to 63 characters, because the length is only allowed to take 6 bits. The null label of length zero is reserved for the root zone. The full domain name may not exceed the length of 253 characters in its textual representation (or 254 with the trailing dot).<ref name=rfc1034/> In the internal binary representation of the DNS this maximum length of 253 requires 255 octets of storage, as it also stores the length of the first of many labels and adds last null byte.<ref name=rfc1035/> 255 length is only achieved with at least 6 labels (counting the last null label).<ref name=rfc1035/>

	Although no technical limitation exists to prevent domain name labels from using any character that is representable by an octet, hostnames use a preferred format and character set. The characters allowed in labels are a subset of the [[ASCII]] character set, consisting of characters ''a'' through ''z'', ''A'' through ''Z'', digits ''0'' through ''9'', and hyphen. This rule is known as the ''LDH rule'' (letters, digits, hyphen). Domain names are interpreted in a case-independent manner.{{Ref RFC\|4343}} Labels may not start or end with a hyphen.{{Ref RFC\|3696}} An additional rule requires that top-level domain names should not be all-numeric.<ref name=rfc3696 />		Although no technical limitation exists to prevent domain name labels from using any character that is representable by an octet, hostnames use a preferred format and character set. The characters allowed in labels are a subset of the [[ASCII]] character set, consisting of characters ''a'' through ''z'', ''A'' through ''Z'', digits ''0'' through ''9'', and hyphen. This rule is known as the ''LDH rule'' (letters, digits, hyphen). Domain names are interpreted in a case-independent manner.{{Ref RFC\|4343}} Labels may not start or end with a hyphen.{{Ref RFC\|3696}} An additional rule requires that top-level domain names should not be all-numeric.<ref name=rfc3696 />
Line 305:		Line 305:

	===DNS over TLS (DoT)===		===DNS over TLS (DoT)===
			{{Main\|DNS over TLS}}
	[[DNS over TLS]] emerged as an IETF standard for encrypted DNS in 2016, utilizing Transport Layer Security (TLS) to protect the entire connection, rather than just the DNS payload. DoT servers listen on TCP port 853. {{IETF RFC\|7858}} specifies that opportunistic encryption and authenticated encryption may be supported, but did not make either server or client authentication mandatory.		[[DNS over TLS]] emerged as an IETF standard for encrypted DNS in 2016, utilizing Transport Layer Security (TLS) to protect the entire connection, rather than just the DNS payload. DoT servers listen on TCP port 853. {{IETF 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)===		===DNS over HTTPS (DoH)===
			{{Main\|DNS over HTTPS}}
	[[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.<ref>{{cite web \|last1=Csikor \|first1=Levente \|last2=Divakaran \|first2=Dinil Mon \|title=Privacy of DNS over HTTPS: Requiem for a Dream? \|url=https://raw.githubusercontent.com/cslev/doh_ml/main/DNS_over_HTTPS_identification.pdf \|publisher=National University of Singapore \|date=February 2021 \|quote=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.}}</ref>		[[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.<ref>{{cite web \|last1=Csikor \|first1=Levente \|last2=Divakaran \|first2=Dinil Mon \|title=Privacy of DNS over HTTPS: Requiem for a Dream? \|url=https://raw.githubusercontent.com/cslev/doh_ml/main/DNS_over_HTTPS_identification.pdf \|publisher=National University of Singapore \|date=February 2021 \|quote=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.}}</ref>

Line 314:		Line 316:

	===Oblivious DoH (ODoH) and predecessor Oblivious DNS (ODNS)===		===Oblivious DoH (ODoH) and predecessor Oblivious DNS (ODNS)===
			{{Main\|DNS over HTTPS#Oblivious DNS over HTTPS}}
	Oblivious DNS (ODNS) was invented and implemented by researchers at [[Princeton University]] and the [[University of Chicago]] as an extension to unencrypted DNS,<ref>{{Cite journal\|last1=Schmitt\|first1=Paul\|last2=Edmundson\|first2=Anne\|last3=Feamster\|first3=Nick\|title=Oblivious DNS: Practical Privacy for DNS Queries\|url=https://petsymposium.org/2019/files/papers/issue2/popets-2019-0028.pdf \|archive-url=https://web.archive.org/web/20220121210624/https://petsymposium.org/2019/files/papers/issue2/popets-2019-0028.pdf \|archive-date=2022-01-21 \|url-status=live\|journal=Privacy Enhancing Technologies \|date=2019\|volume=2019 \|issue=2 \|pages=228–244 \|doi=10.2478/popets-2019-0028 \|arxiv=1806.00276 \|s2cid=44126163 }}</ref> before DoH was standardized and widely deployed. Apple and Cloudflare subsequently deployed the technology in the context of DoH, as [[DNS over HTTPS#Oblivious DNS over HTTPS\|Oblivious DoH]] (ODoH).<ref>{{cite web \|title=Oblivious DNS Deployed by Cloudflare and Apple \|date=9 December 2020 \|url=https://medium.com/noise-lab/oblivious-dns-deployed-by-cloudflare-and-apple-1522ccf53cab \|access-date=27 July 2022}}</ref> ODoH combines ingress/egress separation (invented in ODNS) with DoH's HTTPS tunneling and TLS transport-layer encryption in a single protocol.<ref>{{cite web \|last1=Pauly \|first1=Tommy \|title=Oblivious DNS Over HTTPS \|url=https://datatracker.ietf.org/doc/draft-pauly-dprive-oblivious-doh/\|publisher=IETF \|date=2 September 2021}}</ref>		Oblivious DNS (ODNS) was invented and implemented by researchers at [[Princeton University]] and the [[University of Chicago]] as an extension to unencrypted DNS,<ref>{{Cite journal\|last1=Schmitt\|first1=Paul\|last2=Edmundson\|first2=Anne\|last3=Feamster\|first3=Nick\|title=Oblivious DNS: Practical Privacy for DNS Queries\|url=https://petsymposium.org/2019/files/papers/issue2/popets-2019-0028.pdf \|archive-url=https://web.archive.org/web/20220121210624/https://petsymposium.org/2019/files/papers/issue2/popets-2019-0028.pdf \|archive-date=2022-01-21 \|url-status=live\|journal=Privacy Enhancing Technologies \|date=2019\|volume=2019 \|issue=2 \|pages=228–244 \|doi=10.2478/popets-2019-0028 \|arxiv=1806.00276 \|s2cid=44126163 }}</ref> before DoH was standardized and widely deployed. Apple and Cloudflare subsequently deployed the technology in the context of DoH, as [[DNS over HTTPS#Oblivious DNS over HTTPS\|Oblivious DoH]] (ODoH).<ref>{{cite web \|title=Oblivious DNS Deployed by Cloudflare and Apple \|date=9 December 2020 \|url=https://medium.com/noise-lab/oblivious-dns-deployed-by-cloudflare-and-apple-1522ccf53cab \|access-date=27 July 2022}}</ref> ODoH combines ingress/egress separation (invented in ODNS) with DoH's HTTPS tunneling and TLS transport-layer encryption in a single protocol.<ref>{{cite web \|last1=Pauly \|first1=Tommy \|title=Oblivious DNS Over HTTPS \|url=https://datatracker.ietf.org/doc/draft-pauly-dprive-oblivious-doh/\|publisher=IETF \|date=2 September 2021}}</ref>

Line 320:		Line 323:

	===DNSCrypt===		===DNSCrypt===
			{{Main\|DNSCrypt}}
	The [[DNSCrypt]] protocol, which was developed in 2011 outside the [[Internet Engineering Task Force\|IETF]] standards framework, 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.<ref>{{Cite web \|last=Ulevitch \|first=David \|date=6 December 2011 \|title=DNSCrypt – Critical, fundamental, and about time. \|url=https://umbrella.cisco.com/blog/dnscrypt-critical-fundamental-and-about-time \|url-status=live \|archive-url=https://web.archive.org/web/20200701221715/https://umbrella.cisco.com/blog/dnscrypt-critical-fundamental-and-about-time \|archive-date=1 July 2020 \|website=Cisco Umbrella \|language=en-US}}</ref> DNSCrypt uses either TCP port 443, the same port as [[HTTPS]] encrypted web traffic, or UDP port 443. 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.<ref name="Anonymized DNSCrypt specification">{{Cite web \|title=Anonymized DNSCrypt specification \|url=https://raw.githubusercontent.com/DNSCrypt/dnscrypt-protocol/master/ANONYMIZED-DNSCRYPT.txt \|url-status=live \|archive-url=https://web.archive.org/web/20191025094649/https://raw.githubusercontent.com/DNSCrypt/dnscrypt-protocol/master/ANONYMIZED-DNSCRYPT.txt \|archive-date=25 October 2019 \|website=[[GitHub]] \|publisher=DNSCrypt}}</ref> 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.<ref name="ODoH_(2022)">{{cite web \|title=Oblivious DoH · DNSCrypt/dnscrypt-proxy Wiki \|url=https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Oblivious-DoH \|website=GitHub \|publisher=DNSCrypt project \|access-date=28 July 2022 \|language=en}}</ref> It is available for a variety of operating systems, including Unix, Apple iOS, Linux, Android, and Windows.		The [[DNSCrypt]] protocol, which was developed in 2011 outside the [[Internet Engineering Task Force\|IETF]] standards framework, 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.<ref>{{Cite web \|last=Ulevitch \|first=David \|date=6 December 2011 \|title=DNSCrypt – Critical, fundamental, and about time. \|url=https://umbrella.cisco.com/blog/dnscrypt-critical-fundamental-and-about-time \|url-status=live \|archive-url=https://web.archive.org/web/20200701221715/https://umbrella.cisco.com/blog/dnscrypt-critical-fundamental-and-about-time \|archive-date=1 July 2020 \|website=Cisco Umbrella \|language=en-US}}</ref> DNSCrypt uses either TCP port 443, the same port as [[HTTPS]] encrypted web traffic, or UDP port 443. 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.<ref name="Anonymized DNSCrypt specification">{{Cite web \|title=Anonymized DNSCrypt specification \|url=https://raw.githubusercontent.com/DNSCrypt/dnscrypt-protocol/master/ANONYMIZED-DNSCRYPT.txt \|url-status=live \|archive-url=https://web.archive.org/web/20191025094649/https://raw.githubusercontent.com/DNSCrypt/dnscrypt-protocol/master/ANONYMIZED-DNSCRYPT.txt \|archive-date=25 October 2019 \|website=[[GitHub]] \|publisher=DNSCrypt}}</ref> 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.<ref name="ODoH_(2022)">{{cite web \|title=Oblivious DoH · DNSCrypt/dnscrypt-proxy Wiki \|url=https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Oblivious-DoH \|website=GitHub \|publisher=DNSCrypt project \|access-date=28 July 2022 \|language=en}}</ref> It is available for a variety of operating systems, including Unix, Apple iOS, Linux, Android, and Windows.

Line 327:		Line 331:
	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 origin 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.		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 origin 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 Security Extensions]] (DNSSEC) modify DNS to add support for cryptographically signed responses.<ref>{{Cite journal \|last1=Herzberg \|first1=Amir \|last2=Shulman \|first2=Haya \|date=2014-01-01 \|title=Retrofitting Security into Network Protocols: The Case of DNSSEC ~~\|url=https://ieeexplore.ieee.org/document/6756846~~ \|journal=IEEE Internet Computing \|volume=18 \|issue=1 \|pages=66–71 \|doi=10.1109/MIC.2014.14 \|s2cid=12230888 \|issn=1089-7801~~\|url-access=subscription~~ }}</ref> [[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.		DNS responses traditionally do not have a [[cryptographic signature]], leading to many attack possibilities; the [[Domain Name System Security Extensions]] (DNSSEC) modify DNS to add support for cryptographically signed responses.<ref>{{Cite journal \|last1=Herzberg \|first1=Amir \|last2=Shulman \|first2=Haya \|date=2014-01-01 \|title=Retrofitting Security into Network Protocols: The Case of DNSSEC \|journal=IEEE Internet Computing \|volume=18 \|issue=1 \|pages=66–71 \|doi=10.1109/MIC.2014.14 \|bibcode=2014IIC....18a..66H \|s2cid=12230888 \|issn=1089-7801}}</ref> [[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.

	Techniques such as [[forward-confirmed reverse DNS]] can also be used to help validate DNS results.		Techniques such as [[forward-confirmed reverse DNS]] can also be used to help validate DNS results.
Line 481:		Line 485:
	* {{Sum RFC\|1033}}		* {{Sum RFC\|1033}}
	* {{Sum RFC\|1101}}		* {{Sum RFC\|1101}}
	~~{{Reflist}}~~

	==External links==		==External links==

84.254.82.211: /* Oblivious DoH (ODoH) and predecessor Oblivious DNS (ODNS) */

2025-06-23T21:00:36Z

Oblivious DoH (ODoH) and predecessor Oblivious DNS (ODNS)

← Previous revision		Revision as of 21:00, 23 June 2025
Line 300:		Line 300:
	From the time of its origin in 1983 the DNS has used the [[User Datagram Protocol]] (UDP) for transport over IP. Its limitations have motivated numerous protocol developments for reliability, security, privacy, and other criteria, in the following decades.		From the time of its origin in 1983 the DNS has used the [[User Datagram Protocol]] (UDP) for transport over IP. Its limitations have motivated numerous protocol developments for reliability, security, privacy, and other criteria, in the following decades.

	===Conventional: DNS over UDP and TCP ~~ports~~ 53 (Do53)===		===Conventional: DNS over UDP and TCP port 53 (Do53)===

	# UDP reserves port number 53 for servers listening to queries.<ref name="rfc1035" /> Such a query consists 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.<ref>{{IETF RFC\|2671}}, ''Extension Mechanisms for DNS (EDNS0)'', P. Vixie (August 1999)</ref> 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, [[DNS zone transfer\|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.		UDP reserves port number 53 for servers listening to queries.<ref name="rfc1035" /> Such a query consists 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.<ref>{{IETF RFC\|2671}}, ''Extension Mechanisms for DNS (EDNS0)'', P. Vixie (August 1999)</ref> 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, [[DNS zone transfer\|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)===		===DNS over TLS (DoT)===
Line 314:		Line 314:

	===Oblivious DoH (ODoH) and predecessor Oblivious DNS (ODNS)===		===Oblivious DoH (ODoH) and predecessor Oblivious DNS (ODNS)===
	Oblivious DNS (ODNS) was invented and implemented by researchers at [[Princeton University]] and the [[University of Chicago]] as an extension to unencrypted DNS,<ref>{{Cite journal\|last1=Schmitt\|first1=Paul\|last2=Edmundson\|first2=Anne\|last3=Feamster\|first3=Nick\|title=Oblivious DNS: Practical Privacy for DNS Queries\|url=https://petsymposium.org/2019/files/papers/issue2/popets-2019-0028.pdf \|archive-url=https://web.archive.org/web/20220121210624/https://petsymposium.org/2019/files/papers/issue2/popets-2019-0028.pdf \|archive-date=2022-01-21 \|url-status=live\|journal=Privacy Enhancing Technologies \|date=2019\|volume=2019 \|issue=2 \|pages=228–244 \|doi=10.2478/popets-2019-0028 \|arxiv=1806.00276 \|s2cid=44126163 }}</ref> before DoH was standardized and widely deployed. Apple and Cloudflare subsequently deployed the technology in the context of DoH, as Oblivious DoH (ODoH).<ref>{{cite web \|title=Oblivious DNS Deployed by Cloudflare and Apple \|date=9 December 2020 \|url=https://medium.com/noise-lab/oblivious-dns-deployed-by-cloudflare-and-apple-1522ccf53cab \|access-date=27 July 2022}}</ref> ODoH combines ingress/egress separation (invented in ODNS) with DoH's HTTPS tunneling and TLS transport-layer encryption in a single protocol.<ref>{{cite web \|last1=Pauly \|first1=Tommy \|title=Oblivious DNS Over HTTPS \|url=https://datatracker.ietf.org/doc/draft-pauly-dprive-oblivious-doh/\|publisher=IETF \|date=2 September 2021}}</ref>		Oblivious DNS (ODNS) was invented and implemented by researchers at [[Princeton University]] and the [[University of Chicago]] as an extension to unencrypted DNS,<ref>{{Cite journal\|last1=Schmitt\|first1=Paul\|last2=Edmundson\|first2=Anne\|last3=Feamster\|first3=Nick\|title=Oblivious DNS: Practical Privacy for DNS Queries\|url=https://petsymposium.org/2019/files/papers/issue2/popets-2019-0028.pdf \|archive-url=https://web.archive.org/web/20220121210624/https://petsymposium.org/2019/files/papers/issue2/popets-2019-0028.pdf \|archive-date=2022-01-21 \|url-status=live\|journal=Privacy Enhancing Technologies \|date=2019\|volume=2019 \|issue=2 \|pages=228–244 \|doi=10.2478/popets-2019-0028 \|arxiv=1806.00276 \|s2cid=44126163 }}</ref> before DoH was standardized and widely deployed. Apple and Cloudflare subsequently deployed the technology in the context of DoH, as [[DNS over HTTPS#Oblivious DNS over HTTPS\|Oblivious DoH]] (ODoH).<ref>{{cite web \|title=Oblivious DNS Deployed by Cloudflare and Apple \|date=9 December 2020 \|url=https://medium.com/noise-lab/oblivious-dns-deployed-by-cloudflare-and-apple-1522ccf53cab \|access-date=27 July 2022}}</ref> ODoH combines ingress/egress separation (invented in ODNS) with DoH's HTTPS tunneling and TLS transport-layer encryption in a single protocol.<ref>{{cite web \|last1=Pauly \|first1=Tommy \|title=Oblivious DNS Over HTTPS \|url=https://datatracker.ietf.org/doc/draft-pauly-dprive-oblivious-doh/\|publisher=IETF \|date=2 September 2021}}</ref>

	===DNS over Tor===		===DNS over Tor===

imported>Annh07: Reverted edit by Goooglex (talk) to last version by Omphalographer

2025-06-15T13:55:46Z

Reverted edit by Goooglex (talk) to last version by Omphalographer

← Previous revision	Revision as of 13:55, 15 June 2025
(No difference)

imported>OAbot: Open access bot: url-access updated in citation with #oabot.

2025-05-26T06:02:51Z

Open access bot: url-access updated in citation with #oabot.

Show changes