The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00135, EX. 2042
`1 of 23
`
`

`

`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00135, EX. 2042
`2 of 23
`
`

`

`8/2/22, 6:39 PM
`
`History
`
`Domain Name System = Wikipedia
`
`Using a simpler, more memorable namein place of a host's numerical address dates back to the
`ARPANETera. The Stanford Research Institute (now SRI International) maintaineda text file named
`HOSTS.TXT that mapped host names to the numerical addresses of computers on the
`ARPANETSI[6] Elizabeth Feinler developed and maintained the first ARPANET directory.!ZI[8]
`Maintenance of numerical addresses, called the Assigned NumbersList, was handled by Jon Postel at
`the University of Southern California's Information Sciences Institute (ISI), whose team worked
`closely with SRI.!9]
`
`Addresses were assigned manually. Computers, including their hostnamesand addresses, were added
`to the primary file by contacting the SRI Network Information Center (NIC), directed by Feinler,
`telephone during business hours.!!°] Later, Feinler set up a WHOISdirectory on a server in the NIC
`for retrieval of information about resources, contacts, and entities.24 She and her team developed the
`conceptof domains.) Feinler suggested that domainsshould bebasedon thelocation ofthe physical
`address of the computer.22] Computers at educational institutions would have the domain edu, for
`example.3] She and her team managedthe Host Naming Registry from 1972 to 1989.41
`
`By the early 1980s, maintaining a single, centralized host table had become slow and unwieldy and
`the emerging network required an automated naming system to address technical and personnel
`issues. Postel directed the task of forging a compromise between five competing proposals of solutions
`to Paul Mockapetris. Mockapetris instead created the Domain Name System in 1983 while at the
`University of Southern California.20J[45]
`
`The Internet Engineering Task Force published the original specifications in RFC 882 and RFC 883 in
`November1983.!6JE7] These were updated in RFC 973 in January 1986.
`
`In 1984, four UC Berkeley students, Douglas Terry, Mark Painter, David Riggle, and Songnian Zhou,
`wrote the first Unix nameserver implementation for the Berkeley Internet Name Domain, commonly
`referred to as BIND.!8] In 1985, Kevin Dunlap of DEC substantially revised the DNS implementation.
`Mike Karels, Phil Almquist, and Paul Vixie then took over BIND maintenance. Internet Systems
`Consortium was foundedin 1994 by Rick Adams,Paul Vixie, and Carl Malamud, expressly to provide
`a home for BIND development and maintenance. BIND versions from 4.9.3 onward were developed
`and maintained by ISC, with support provided by ISC’s sponsors. As co-architects/programmers, Bob
`Halley and Paul Vixie released the first production-ready version of BIND version 8 in May 1997.
`Since 2000, over 43 different core developers have worked on BIND. Lo]
`
`In November 1987, RFC 1034!2°] and RFC 1035!3! superseded the 1983 DNSspecifications. Several
`additional Request for Comments have proposedextensionsto the core DNSprotocols.!24
`
`Structure
`
`Domain name space
`
`The domain namespaceconsists of a tree data structure. Each nodeorleaf in the tree has a label and
`zero or more resource records (RR), which hold information associated with the domain name. The
`domain nameitself consists of the label, concatenated with theBanas, PLitsparentnode oR, Hye right,
`separatedby a dot.!22]
`IPR2022-00135, EX. 2042
`3 of 23
`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00138, EX, 2042
`3 of 23
`
`https://en,wikipedia.org/wiki/Domain_Name_System
`
`3/23
`
`

`

`8/2/22, 6:39 PM
`Domain Name System = Wikipedia
`The tree sub-divides into zones beginning at the root zone. A DNS zone mayconsist of as many
`domains and sub domains as the zone manager chooses. DNScan also be partitioned according to
`class wheretheseparate classes can be thoughtofas anarray ofparallel namespacetrees.!231
`
`Administrative responsibility for any
`zone may be divided by creating
`additional zones. Authority over the new
`zone is
`said to be delegated to a
`designated nameserver. The parent zone
`ceases to be authoritative for the new
`zone.|23]
`
`Domain namesyntax,
`
`Domain Name Space
`
`internationalization The definitive descriptions of the rules
`
`for forming domain names appear in
`RFC 1035, RFC 1123, RFC 2181, and RFC
`5892. A domain nameconsists of one or
`moreparts, technically called labels, that
`are conventionally concatenated, and
`delimited by dots, such as example.com.
`
` Zone of authority,
`
`t = managed Dy a name server
`seo alsa: AFC 1034 42:
`How the datatase is divided into zones
`
`Thehierarchical Domain Name System forclass /nternet,
`organized into zones, each served by a nameserver
`
`The right-most label conveys the top-
`level domain; for example, the domain name www.example.com belongsto the top-level domain com.
`
`The hierarchy of domains descendsfrom rightto 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 wwwis a subdomain of example.com.This tree of subdivisions may have up to 127
`levels. [24]
`
`A label may contain zero to 63 characters. The null label, of length zero, is reserved for the root zone.
`The full domain name maynot exceedthe length of 253 charactersin its textual representation.!2°] In
`the internal binary representation of the DNS the maximumlength requires 255 octets of storage,as it
`also stores the length of the name.!3!
`
`Although notechnical limitation exists to prevent domain namelabels using any character which is
`representable by an octet, hostnamesuse 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 o through 9, and hyphen.This rule is known as the LDH rule (letters, digits, hyphen). Domain
`names are interpreted in case-independent manner.!25] Labels maynotstart or end with a hyphen.[26!
`An additionalrule requires that top-level domain namesshould notbe all-numeric.!26!
`
`The limited set of ASCII characters permitted in the DNS prevented the representation of names and
`words of many languagesin their native alphabets or scripts. To make this possible, ICANN approved
`the Internationalizing Domain Namesin Applications (IDNA) system, by which user applications,
`such as web browsers, map Unicodestrings into the valid DNS character set using Punycode. In 2009
`ICANNapproved the installation of internationalized domain name country code top-level domains
`(ccTLDs). In addition, manyregistries of the existing topatévelcdoreniiteteteses(TEDsWaved‘adopted
`the IDNA system, guided by RFC 5890, RFC 5891, RFC 5892, RFC 5893.
`4 of 23
`The Data Company TechnologiesInc. v. Bright Data Ltd.
`IPR2022-00138, EX. 2042
`4 of 23
`
`https://en,wikipedia,org/wiki/Domain_Name_System
`
`4/23
`
`

`

`The Data Company Technologies Inc. v. Bright Data Ltd
`IPR2022-00135, EX. 2042
`5 of 23
`
`

`

`8/2/22, 6:39 PM
`
`Domain Name System = Wikipedia
`
`an
`receives
`it
`until
`process
`this
`
`answer. The
`diagram
`authoritative
`re
`EP,
`
`Where 5 wwwew. wikipedia.org?">rn
`illustrates this process for the host that
`SF. —!} } — "try 208.74
`
`
`a SBy 2048-74aie1122"— ere
`is named by the fully qualified domain
`c™2
`—_
`-
`
`name "www.wikipedia.org”".
`
`
`
`This mechanism would place a large
`traffic burden on the root servers,
`if
`every resolution on the Internet required
`starting at the root. In practice caching is
`used in DNSserversto off-load the root
`servers, and as a result,
`root name
`servers actually are involved in only a
`relatively small fraction of all requests.
`
`Recursive and caching nameserver
`
`A DNS resolver that implements the iterative approach mandated
`by RFC 1034; in this case, the resolver consults three name
`serversto resolve the fully qualified domain name
`"www.wikipedia.org”.
`
`In theory, authoritative name servers are sufficient for the operation of the Internet. However, with
`only authoritative nameservers operating, every DNS query must start with recursive queries at the
`root zone of the Domain Name System and each user system would have to implement resolver
`software capable of recursive operation.!3°1
`
`To improveefficiency, reduce DNStraffic across the Internet, and increase performance in end-user
`applications, the Domain Name System supports DNScache servers which store DNS query results
`for a period of time determined in the configuration (time-to-live) of the domain namerecord in
`question. Typically, such caching DNS servers also implementthe recursive algorithm necessary to
`resolve a given namestarting with the DNS root through to the authoritative nameservers of the
`queried domain. With this function implementedin the nameserver, user applications gain efficiency
`in design and operation.
`
`The combination of DNS caching and recursive functions in a nameserver is not mandatory; the
`functions can be implemented independently in servers for special purposes.
`
`Internet service providers typically provide recursive and caching nameservers for their customers.
`In addition, many home networking routers implement DNS caches and recursion to improve
`efficiency in the local network.
`
`DNS resolvers
`
`The client side of the DNSis called a DNS resolver. A resolver is responsible for initiating and
`sequencing the queries that ultimately lead to a full resolution (translation) of the resource sought,
`e.g., translation of a domain name into an IP address. DNS resolversare classified by a variety of
`query methods, such as recursive, non-recursive, and iterative. A resolution process may use a
`combination of these methods.!2°!
`
`In a non-recursive query, a DNSresolver queries a DNSserverthat provides a recordeither for which
`the server is authoritative, or it provides a partial result without querying other servers. In case of a
`caching DNSresolver, the non-recursive query of its local DNS cachedelivers a result and reduces the
`load on upstream DNSservers by caching DNS resource’tebedsherdpetetecftiniestfer dh initial
`IPR2022-00135, EX. 2042
`response from upstream DNSservers.
`6 of 23
`The Data Company TechnologiesInc. v. Bright Data Ltd.
`IPR2022-00138, EX. 2042
`6 of 23
`
`https://en,wikipedia,org/wiki/Domain_Name_System
`
`6/23
`
`

`

`8/2/22, 6:39 PM
`Domain Name System = Wikipedia
`In a recursive query, a DNSresolver queries a single DNSserver, which may in turn query other DNS
`servers on behalf of the requester. For example, a simple stub resolver running on a homerouter
`typically makes a recursive query to the DNSserverrun bythe user's ISP. A recursive query is one for
`which the DNS server answers the query completely by querying other name servers as needed. In
`typical operation, a client
`issues a recursive query to a caching recursive DNS server, which
`subsequently issues non-recursive queries to determine the answer and send a single answer back to
`the client. The resolver, or another DNSserveracting recursively on behalf of the resolver, negotiates
`use of recursive service using bits in the query headers. DNSservers are not required to support
`recursive queries.
`
`The iterative query procedure is a process in which a DNSresolver queries a chain of one or more
`DNSservers. Each serverrefers the client to the next server in the chain, until the current server can
`fully resolve the request. For example, a possible resolution of www.example.com would query a
`global root server, then a "com"server, andfinally an "example.com"server.
`
`Circular dependencies and glue records
`
`Nameservers in delegations are identified by name, rather than by IP address. This means that a
`resolving name server must issue another DNS request to find out the IP address of the server to
`whichit has been referred. If the namegiven in the delegation is a subdomain of the domain for which
`the delegation is being provided,thereis a circular dependency.
`
`In this case, the name server providing the delegation must also provide one or more IP addressesfor
`the authoritative name server mentioned in the delegation. This information is called glue. The
`delegating nameserver providesthis glue in the form of records in the additional section of the DNS
`response, and provides the delegation in the authority section of the response. A glue record is a
`combination of the nameserver and IP address.
`
`For example, if the authoritative nameserver for example.org is ns1.example.org, a computertrying to
`resolve www.example.org first resolves nsi.example.org. As nsi is contained in example.org, this
`requires resolving example.orgfirst, which presents a circular dependency. To break the dependency,
`the nameserver for the top level domain org includesglue along with the delegation for example.org.
`Theglue records are address records that provide IP addresses for ns1.example.org. The resolver uses
`one or more of these IP addresses to query one of the domain's authoritative servers, which allowsit
`to complete the DNSquery.
`
`Record caching
`
`A standard practice in implementing nameresolution in applications is to reduce the load on the
`Domain Name System servers by caching results locally, or in intermediate resolver hosts. Results
`obtained from a DNSrequest are always associated with the time to live (TTL), an expiration time
`after which the results must be discarded or refreshed. The TTL is set by the administrator of the
`authoritative DNSserver. The period of validity may vary from a few seconds to days or even
`
`weeks. !31
`
`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 andto be refreshed after the
`TTL. RFC 1912 conveysbasic rules for determining appropriateTTLvaluS Jogies Inc. v. Bright Data Lid
`
`https://en,wikipedia,org/wiki/Domain_Name_System
`
`IPR2022-00135, EX. 2042
`7 of 23
`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00138, EX. 2042
`7 of 23
`
`7/23
`
`

`

`8/2/22, 6:39 PM
`Domain Name System = Wikipedia
`Someresolvers may override TTL values, as the protocol supports caching for up to sixty-eight years
`or no caching atall. Negative caching, i.e. the caching of the fact of non-existence of a record, is
`determined by nameservers authoritative for a zone which mustincludethe Start of Authority (SOA)
`record whenreporting no data of the requested type exists. The value of the minimum field of the
`SOArecord and the TTL of the SOAitself is used to establish the TTL for the negative answer.
`
`Reverse lookup
`
`A reverse DNS lookup is a query of the DNS for domain names when the IP address is known.
`Multiple domain names may be associated with an IP address. The DNSstores IP addresses in the
`form of domain names as specially formatted names in pointer
`(PTR)
`records within the
`infrastructure top-level domain arpa. For IPv4, the domain is in-addr.arpa. For IPv6, the reverse
`lookup domain is ip6.arpa. The IP address is represented as a name in reverse-ordered octet
`representation for IPv4, and reverse-ordered nibble representation for IPv6.
`
`When performing a reverse lookup, the DNS client converts the address into these formats before
`querying the name for a PTR record following the delegation chain as for any DNS query. For
`example, assuming the IPv4 address 208.80.152.2 is assigned to Wikimedia, it is represented as a
`DNSnamein reverse order: 2.152.80.208.in-addr.arpa. When the DNSresolvergets a pointer (PTR)
`request, it begins by querying the root servers, which point to the servers of American Registry for
`Internet Numbers (ARIN) for the 208.in-addr.arpa zone. ARIN's servers delegate 152.80.208.in-
`addr.arpa to Wikimedia to which the resolver sends another query for 2.152.80.208.in-addr.arpa,
`whichresults in an authoritative response.
`
`Client lookup
`
`Users generally do not communicate
`directly with a DNSresolver. Instead
`DNSresolution takes place transparently
`in applications such as web browsers, e-
`mail
`clients,
`and
`other
`Internet
`applications. When
`an_
`application
`makes a request that requires a domain
`name lookup, such programs send a
`resolution request to the DNSresolver in
`the local operating system, which in turn
`handles the communications required.
`
`
`
`Your Site or Orgasatan The fevterteet
`
`DNS resolution sequence
`
`The DNSresolver will almost invariably have a cache (see above) containing recent lookups. If the
`cache can provide the answer to the request, the resolver will return the value in the cache to the
`program that madethe request. If the cache does not contain the answer, the resolver will send the
`request to one or more designated DNSservers. In the case of most homeusers, the Internet service
`provider to which the machine connects will usually supply this DNS server: such a user will either
`have configured that server's address manually or allowed DHCP to set it; however, where systems
`administrators have configured systems to use their own DNSservers, their DNS resolvers point to
`separately maintained nameservers of the organization. In any event, the nameserver thus queried
`will follow the process outlined above, until it either successfully finds a result or does not. It then
`returnsits results to the DNSresolver; assumingit has feume ackesh)tedthe.gesalyersdialpaaches that
`result for future use, and hands the result back to the software whichinitiated'TR@#eeALeSEX. 2042
`8 of 23
`The Data Company TechnologiesInc. v. Bright Data Ltd.
`IPR2022-00138, EX. 2042
`8 of 23
`
`https://en,wikipedia,org/wiki/Domain_Name_System
`
`8/23
`
`

`

`The Data Company Technologies Inc v. Bright Data Ltd.
`IPR2022-00135, EX. 2042
`9 of 23
`
`

`

`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00135, EX. 2042
`10 of 23
`
`

`

`8/2/22, 6:39 PM
`
`Domain Name System = Wikipedia
`
`DNStransport protocols
`
`DNS-over-UDP/53 ("Do53")
`
`From the timeofits origin in 1983 until quite recently, DNS has primarily answered queries on User
`Datagram Protocol (UDP) port number 53.'3! Such queries consist of a clear-text request sent in a
`single UDP packet from theclient, responded to with a clear-text reply sent in a single UDP packet
`from the server. Whenthe length of the answer exceeds 512 bytes and both client and server support
`Extension Mechanisms for DNS (EDNS), larger UDP packets may be used.!37] Use of DNS-over-UDP
`is limited by, among other things, its lack of transport-layer encryption, authentication, reliable
`delivery, and messagelength.
`
`DNS-over-TCP/53 ("Do53/TCP")
`
`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 betweenclients and servers.
`
`DNS-over-TLS ("DoT")
`
`An IETFstandard for encrypted DNS emerged in 2016, utilizing standard Transport Layer Security
`(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 makeeitherserveror client authentication mandatory.
`
`DNS-over-HTTPS ("DoH")
`
`A competing standard for DNS query transport was introduced in 2018, tunneling DNS query data
`over HTTPS (which in turn transports HTTP over TLS). DoH was promoted as a more web-friendly
`alternative to DNSsince, like DNSCrypt, it travels on TCP port 443, and thus looks similar to web
`traffic, though they are easily differentiable in practice.[38] DoH has been widely criticized for
`decreasing user anonymity relative to DoT.[391
`
`Oblivious DNS-over-HTTPS ("ODoH")
`
`In 2021, an "oblivious" implementation of DoH was proposed and has been implemented in draft
`form, combining ingress/egress separation with HTTPStunneling and TLS transport-layer encryption
`in a single defined protocol.!4°!
`
`DNS-over-TOR
`
`Like other Internet protocols, DNS may be run over VPNsand tunnels. One use which has become
`commonenoughsince 2019 to warrant its own frequently used acronym is DNS-over-Tor. The privacy
`gains of Oblivious DNS can be garnered through the use SPTHEECERYTOERBtSTROPIABess and
`egress nodes, paired with the transport-layer encryption provided by TLS,(41)
`11 of23
`
`https://en.wikipedia.org/wiki/Domain_Name_System
`
`he Data CompanyTechnologiesInc, v. Bright Data Ltd.
`IPR2022-00138, EX, 2042
`11 of 23
`
`11/23
`
`

`

`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00135, EX. 2042
`12 of 23
`
`

`

`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00135, EX. 2042
`13 of 23
`
`

`

`8/2/22, 6:39 PM
`Domain Name System = Wikipedia
`overhead whennot in use. This was accomplished through the OPT pseudo-resource record that only
`exists in wire transmissions of the protocol, but not in any zonefiles. Initial extensions were also
`suggested (EDNSo), such as increasing the DNS messagesize in UDP datagrams.
`
`Dynamic zone updates
`
`Dynamic DNS updates use the UPDATE DNSopcodeto add or remove resource records dynamically
`from a zone database maintained on an authoritative DNS server. The feature is described in RFC
`2136. 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 DHCPserver,it is not possible to provide static DNS assignments for suchclients.
`
`Security issues
`
`Originally, security concerns were not major design considerations for DNS software or any software
`for deployment on theearly 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 changedthe
`requirements for security measuresto 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 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.
`
`leading to many attack
`DNS responses traditionally do not have a cryptographic signature,
`possibilities; the Domain Name System Security Extensions (DNSSEC) modify DNS to add support
`for cryptographically signed responses. 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
`paypai.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 manyfonts the letter / and the numeral 1 look
`very similar or even identical. This problem is acute in systems that support internationalized domain
`names, as manycharacter codes in ISO 10646 mayappearidentical on typical computer screens. This
`vulnerability is occasionally exploited in phishing.!48!
`
`Techniques such as forward-confirmedreverse DNScanalso be usedto help validate DNSresults.
`
`DNScanalso "leak" from otherwise secure or private connections, if attention is not paid to their
`configuration, and at times DNShas beenusedto bypassfirewalls by malicious persons, and exfiltrate
`data, since it is often seen as innocuous.
`
`Privacy and tracking issues
`
`Originally designed as a public, hierarchical, distributed and heavily cached database, DNS protocol
`has no confidentiality controls. User queries and nameseyyeKkesRANsRsnAisoboiasSenk wRencrypted
`which enables network packetsniffing, DNS hijacking, DNS cache poisoning!eadneatsinxthesemiddle
`0
`
`https://en,wikipedia,org/wiki/Domain_Name_System
`
`The Data Company TechnologiesInc. v. Bright Data Ltd.
`IPR2022-00138, EX. 2042
`14 of 23
`
`14/23
`
`

`

`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00135, EX. 2042
`15 of 23
`
`

`

`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00135, EX. 2042
`16 of 23
`
`

`

`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00135, EX. 2042
`17 of 23
`
`

`

`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00135, EX. 2042
`18 of 23
`
`

`

`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00135, EX. 2042
`19 of 23
`
`

`

`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00135, EX. 2042
`20 of 23
`
`

`

`8/2/22, 6:39 PM
`
`Domain NameSystem = Wikipedia
`
`29. Bissyande, TegawendeéF.; Sie, Oumarou (2017-10-09). e-/nfrastructure and e-Services for
`Developing Countries: 8th International Conference, AFRICOMM 2016, Ouagadougou, Burkina
`Faso, December 6-7, 2016, Proceedings (https://books.google.com/books?id=YjES5DWAAQBAJ&d
`
`q=%22lame+delegation%22&pg=PA235). Springer. ISBN 978-3-319-66742-3.
`
`30. "DNS zone"(https:/Awww.ionos.co.uk/digitalguide/server/know-how/dns-zone/). /ONOS
`Digitalguide. Retrieved 2022-03-31.
`. "What is DNS propagation?" (https:/Awww.ionos.com/digitalguide/server/know-how/dns-propagatio
`3 —
`n/). IONOSDigitalguide. Retrieved 2022-04-22.
`
`32. "Providers ignoring DNS TTL?"(http://ask.slashdot.org/story/05/04/18/198259/providers-ignoring-
`dns-ttl). Slashdot. 2005. Retrieved 2012-04-07.
`33. Ben Anderson (7 September 2011). "Ben Anderson: Why Web Browser DNS Caching Can Be A
`Bad Thing"(http://dyn.com/web-browser-dns-caching-bad-thing/). Retrieved 20 October 2014.
`34. "How Internet Explorer uses the cache for DNS hostentries" (http://support.microsoft.com/default.
`aspx?scid=KB:en-us;263558). Microsoft Corporation. 2004. Retrieved 2010-07-25.
`35. "Domain Name System (DNS) Parameters"(https://www.iana.org/assignments/dns-parameters/dn
`
`s-parameters.xhtml#dns-parameters-6). IANA. DNS RCODEs. Retrieved 14 June 2019,
`36. James F. Kurose and Keith W. Ross, Computer Networking: A Top-Down Approach, 6th ed.
`Essex, England: Pearson Educ.Limited, 2012
`37. RFC 2671 (https://datatracker.ietf.org/doc/html/rfc2671), Extension Mechanisms for DNS
`(EDNSO), P. Vixie (August 1999)
`38. Csikor, Levente; Divakaran, Dinil Mon (February 2021). "Privacy of DNS-over-HTTPS: Requiem
`for a Dream?"(https://raw.githubusercontent.com/cslev/doh_ml/main/DNS_over_HTTPS_identific
`ation.pdf) (PDF). National University of Singapore. "We investigate whether DoHtraffic is
`distinguishable from encrypted Webtraffic. To this end, we train a machine learning modelto
`classify HTTPStraffic as either Web or DoH. With our DoH identification modelin 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."
`39. Posch, Maya (21 October 2019). "DNS-over-HTTPSis the Wrong Partial Solution" (https://hackad
`ay.com/2019/10/21/dns-over-https-is-the-wrong-partial-solution/). Hackaday. "DoH removes
`options for network operators (private and corporate) to secure their own network, as one of the
`architects behind DNS, Paul Vixie, pointed out on Twitter last year. DoH is essentially DNS-over-
`HTTP-over-TLS, resulting in its own mime Media Type of application/dns-message andsignificant
`added complexity. By mixing DoH in with existing protocols, it means that every DNS request and
`response goes through an HTTPSstack. For embeddedapplications this is a nightmare scenario,
`butit is also incompatible with nearly every piece of existing security hardware. When rogue apps
`like Firefox circumvent the system's DoT-based DNS and useits own DNS resolver over DoH
`instead, this makes for a highly opaque security situation. That DNS resolving would moveinto
`individual applications, as we see happening now, seemslike a massive step backwards."
`40. Pauly, Tommy (2 September 2021). "Oblivious DNS Over HTTPS"(https://datatracker.ietf.org/doc/
`draft-pauly-dprive-oblivious-doh/). |ETF.
`41. Muffett, Alec (February 2021). ""No Port 53, Who Dis?" A Year of DNS over HTTPS overTor"(htt
`ps://www.ndss-symposium.org/wp-content/uploads/dnspriv21-03-paper.pdf) (PDF). Network and
`Distributed System Security Symposium. "DNS-over-HTTPS (DoH) obviates manybutnotall 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 requestfingerprinting, | describe DNS over HTTPS over Tor (DoHOoT),."
`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00135, EX. 2042
`21 of 23
`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00138, EX. 2042
`21 of 23
`
`https://en,wikipedia,org/wiki/Domain_Name_System
`
`21/23
`
`

`

`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00135, EX. 2042
`22 of 23
`
`

`

`8/2/22, 6:39 PM
`
`Domain Name System = Wikipedia
`
`Retrieved from "https://en,wikipedia.org/w/index. php?title=Domain_Name_System&oldid=1100910294"
`
`This page waslast edited on 28 July 2022, at 08:52 (UTC).
`
`Text is available under the Creative Commons Attribution-ShareAlike License 3.0; additional terms may apply. By using
`this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia
`Foundation, Inc., a non-profit organization.
`
`https://en,wikipedia,org/wiki/Domain_Name_System
`
`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00135, EX. 2042
`23 of 23
`The Data Company Technologies Inc. v. Bright Data Ltd.
`IPR2022-00138, EX. 2042
`23 of 23
`
`23/23
`
`