Add use-application-dns.net - explicit signal for DNS filtering #504
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This domain is meant to be used as a signal that overt DNS filtering is in effect. Applications can try to resolve the name as a test for the presence of DNS filtering. DNS filters that wish to announce their presence can respond with NXDOMAIN rather than an IP address. Applications may use the use-application-dns.net to alter their own behavior. For example, Firefox intends to interpret a use-application-dns.net NXDOMAIN as a command to disable DNS-over-HTTPS and use plain old subject-to-tampering DNS instead. The obvious application of use-application-dns.net, to a network eavesdropper, is to always return NXDOMAIN, in order to force users onto insecure DNS. Mozilla says they intend to monitor the use of use-application-dns.net and stop honoring it if and when ISPs start to use it. https://use-application-dns.net/ This domain is intended to be a content-neutral name that DNS filtering products add to their domain block lists. This will allow users, as well as browsers and other user agents that may implement DNS themselves, to know that the default DNS has implemented some sort of content policy that the user may wish to maintain, and thus application DNS perhaps should not be used, since it would bypass that policy. Resolve use-application-dns.net using the platform’s DNS. If the result is NXDOMAIN, then there is some sort of content filtering or other policy implemented by platform DNS. If the domain returns a result, then there is not (or the DNS server has not added use-application-dns.net to its filtering lists.) https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https Network administrators may configure their networks as follows to signal that their local DNS resolver implemented special features that make the network unsuitable for DoH: DNS queries for the A and AAAA records for the domain “use-application-dns.net” must respond with NXDOMAIN rather than the IP address retrieved from the authoritative nameserver. https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/ This canary domain is intended for use in cases where users have opted in to parental controls. We plan to revisit the use of this heuristic over time, and we will be paying close attention to how the canary domain is adopted. If we find that it is being abused to disable DoH in situations where users have not explicitly opted in, we will revisit our approach.
|
LGTM. |
R6CG
pushed a commit
to R6CG/test-lists
that referenced
this pull request
Sep 25, 2021
iCloud Private Relay is an onion routing proxy available in some versions of iOS, iPadOS, and macOS. Apple's advice to network operators who want to block access to Private Relay is to configure the DNS server to respond negatively for queries for the two names added in this commit, mask.icloud.com and mask-h2.icloud.com. https://developer.apple.com/support/prepare-your-network-for-icloud-private-relay Heading "Allow for network traffic audits". Some caveats to adding these domain names to test-lists: * We really only care to test a DNS resolution for these names, not actually attempt to fetch a web page. A similar situation applied with use-application-dns.net (citizenlab#504). * The documented protocol of Private Relay is anyway UDP+QUIC (HTTP/3), not TCP+TLS. I am guessing, purely based on the name, that mask-h2.icloud.com may be an HTTP/2-based fallback for mask.icloud.com. * Apple clients reportedly send not only A queries for these names but also HTTPS (RR type 65) queries. net4people/bbs#87 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07#section-14.2 Being able to resolve mask.icloud.com and mask-h2.icloud.com does not guarantee that Private Relay will actually work. Apple self-censors the service in certain geographic regions. I don't know how Apple's own restrictions are enforced. Various other domain names may be involved in a Private Relay connection. This commit includes only the ones that are documented by Apple to use for blocking access. * mask.apple-dns.net: mask.icloud.com is a CNAME for this name. * mask-t.apple-dns.net: mask-h2.icloud.com is a CNAME for this name. * mask-api.icloud.com: Apple clients were seen to make queries for this name in experiments. * mask-api.fe.apple-dns.net: mask-api.icloud.com is a CNAME for this name.
hellais
added a commit
that referenced
this pull request
Jan 13, 2022
iCloud Private Relay is an onion routing proxy available in some versions of iOS, iPadOS, and macOS. Apple's advice to network operators who want to block access to Private Relay is to configure the DNS server to respond negatively for queries for the two names added in this commit, mask.icloud.com and mask-h2.icloud.com. https://developer.apple.com/support/prepare-your-network-for-icloud-private-relay Heading "Allow for network traffic audits". Some caveats to adding these domain names to test-lists: * We really only care to test a DNS resolution for these names, not actually attempt to fetch a web page. A similar situation applied with use-application-dns.net (#504). * The documented protocol of Private Relay is anyway UDP+QUIC (HTTP/3), not TCP+TLS. I am guessing, purely based on the name, that mask-h2.icloud.com may be an HTTP/2-based fallback for mask.icloud.com. * Apple clients reportedly send not only A queries for these names but also HTTPS (RR type 65) queries. net4people/bbs#87 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07#section-14.2 Being able to resolve mask.icloud.com and mask-h2.icloud.com does not guarantee that Private Relay will actually work. Apple self-censors the service in certain geographic regions. I don't know how Apple's own restrictions are enforced. Various other domain names may be involved in a Private Relay connection. This commit includes only the ones that are documented by Apple to use for blocking access. * mask.apple-dns.net: mask.icloud.com is a CNAME for this name. * mask-t.apple-dns.net: mask-h2.icloud.com is a CNAME for this name. * mask-api.icloud.com: Apple clients were seen to make queries for this name in experiments. * mask-api.fe.apple-dns.net: mask-api.icloud.com is a CNAME for this name. Co-authored-by: David Fifield <[email protected]> Co-authored-by: Arturo Filastò <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This domain is meant to be used as a signal that overt DNS filtering is
in effect. Applications can try to resolve the name as a test for the
presence of DNS filtering. DNS filters that wish to announce their
presence can respond with NXDOMAIN rather than an IP address.
Applications may use the use-application-dns.net to alter their own
behavior. For example, Firefox intends to interpret a
use-application-dns.net NXDOMAIN as a command to disable DNS-over-HTTPS
and use plain old subject-to-tampering DNS instead.
The obvious application of use-application-dns.net, to a network
eavesdropper, is to always return NXDOMAIN, in order to force users onto
insecure DNS. Mozilla says they intend to monitor the use of
use-application-dns.net and stop honoring it if and when ISPs start to
use it.
https://use-application-dns.net/
This domain is intended to be a content-neutral name that DNS
filtering products add to their domain block lists.
https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
Network administrators may configure their networks as follows
to signal that their local DNS resolver implemented special
features that make the network unsuitable for DoH:
https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/
This canary domain is intended for use in cases where users have
opted in to parental controls. We plan to revisit the use of
this heuristic over time, and we will be paying close attention
to how the canary domain is adopted. If we find that it is being
abused to disable DoH in situations where users have not
explicitly opted in, we will revisit our approach.