Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[John Levine]

In article  
you write:
>Encryption at the root is very possible.

Indeed, but that's not the same question as whether it's a good idea.

It is my strong impression that whatever problem you would solve with
DoT to the root can also be solved using a local copy of the root,
which has the practical advantage that you can do it right now.

Also, depending how we decide that a name server signals that it
supports DoT (or perhaps a parent gives a hint with the referral) it
might make life a lot easier if the signals don't have to start all
the way at the top.

Let's put this in the pile of things to think about later.

R's,
John


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[Livingood, Jason]

I agree that this is not a technical issue of scaling the root; that quantity 
of queries per day and second is not a big problem. Rather, as you note, it is 
a layer-9 issue. But I don't think we should constrain our requirements 
development & protocol design because of this. Ultimately root operators and 
others will need to make independent assessments of cost/benefit and it's not 
unheard of for communities in ICANN to initiate the different policy 
development processes in order to change pricing/margin/contract stuff to 
accommodate new requirements.

On 10/29/19, 11:30 PM, "dns-privacy on behalf of Jim Reid" 
 wrote:

On 30 Oct 2019, at 01:32, Eric Rescorla  wrote:
>
>> Yes, it's hard, but I think it's worthwhile, because the prospect of 
getting the root to offer ADoT seems very distant to me.
>>
> Why? Do we have estimates of the load level here as compared to (say) 
Quad9 or 1.1.1.1?

The root server operators publish statistics on the traffic they get. Links 
for some of their data can be found at 
https://protect2.fireeye.com/url?k=2afc0159bfd08024.2afc26ed-cd00c20c720e6f6a=https://root-servers.org.

The anycast cluster for a.root-servers.net alone currently handles upwards 
of 8B queries/day - roughly 100,000 queries/second. That’s steady state. The 
numbers would go *far* higher than that during a Mirai-style DDoS attack.

It’s going to be a challenge to get authoritative servers handling those 
sorts of query levels to support DoT (over TCP?). FWIW solving the non-trivial 
operational and engineering issues will be the easy bit. Solving the layer-9 
issues will be harder. I expect that also holds for DoT support at 
authoritative servers for important TLDs or the DNS hosting platforms from the 
likes of Akamai, Dyn, UltraDNS, etc that handle very high query rates.

I suppose someone could ask RSSAC* for their opinion on deploying DoT at 
the root. And having lit the blue touchpaper, I will now run away at great 
speed to watch the ensuing firework display. :-)

* Other ICANN advisory committees are available.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] draft-lmo-dprive-phase2-requirements-00.txt, wiretapping, and RFC 2804

[John R Levine]

Can you be more specific on your bullet list? What I mean is that this 
list seems covered in "Threat Model and Problem Statement" so I am 
wondering what gaps there may be there, if any. Perhaps just ensuring 
you are talking to the correct/intended server (the cert issue you 
note)?


It seems to me there's a bunch of threats that don't overlap very much, 
and what you do depends on what threats you think are important, e.g.. how 
much you care who you're talking to vs. who might be observing on the 
side.  Tossing all the threats into one pot and trying to solve them all 
at the same time doesn't strike me as a path to success.


I don't think I have any new threats there, but I do think it's worth 
separating them into groups that can be addressed by particular 
techniques.



On 10/29/19, 3:08 PM, "dns-privacy on behalf of John Levine" 
 wrote:

   In article 
 you write:
   >
   >I appreciate the authors kicking off the effort with this draft that
   >proposes phase 2 requirements.

   As do I, but it still needs a lot of work.

   One thing that would help me a lot is matching up the features with
   what problem they're supposed to solve.

   * Keeping specific people from seeing your query stream (e.g., your ISP)
   * Keeping random snoopers from seeing your query stream
   * The above for particular parts of your query stream, e.g. 2LDs
   * Being sure you're talking to the right server (the certificate issue)
   * Other stuff?

   Depending on what your goal is, you might mix and match other techniques
   like local mirroring of zones, at least ones that aren't too huge.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29

[Livingood, Jason]

From my perspective it didn't seem that query privacy meant only encryption; 
there may be steps that can be privacy-protective that can be taken 
independently of or before encryption (ergo QNAME min). That seems a key 
question for the WG --> is query privacy limited to encryption or are there 
addition things or alternative things that can be done?

In addition, the notion of addressing potential differences between RSOs, TLDs 
and SLDs grew from the realization that each of these are usually distinct 
groups of operators, may have different requirements or operational 
goals/concerns, and will likely implement on different timeframes. But this is 
simply a matter of opinion right now - let’s maybe see how it looks as we amend 
the requirements based on the call & mailing list and see how things shape up.

Jason

On 10/29/19, 10:20 AM, "dns-privacy on behalf of Paul Hoffman" 
 wrote:

Here are a few responses to the initial draft. I will try to be on the call 
unless we lose power again.

There are many parts of the "core requirements" that seem out of place.

- Resolvers have never had to understand the different between the root 
zone and TLDs and SLDs and "other", so introducing that here might cause 
bikeshedding and lack of adoption. A simpler core requirement would be that DoT 
is required between resolvers and any interested authoritative server.

- QNAME minimization is orthogonal to adding cryptographic privacy. If you 
have a cryptographic tunnel, QNAME minimization adds overhead and the risk of 
additional round trips. On the other hand, some resolvers are perfectly happy 
using QNAME minimization all the time, so they shouldn't have to know whether 
to change settings if DoT is in use.

- The aggressive caching requirement mixes up aggressive caching and normal 
caching in the all-caps bit. Aggressive caching will reduce the number of TLS 
connections you need to set up, so it is a positive, but it is unclear how 
requiring it in order to use ADoT could be enforced.

- DNSSEC validation is orthogonal to adding cryptographic privacy.

--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [EXTERNAL] Re: [Ext] Re: DPRIVE Interim: 10/29

[Livingood, Jason]

Great detailed feedback, thanks. Have flagged in 
https://github.com/alex-nicat/ietf-dprive-phase2-requirements/issues/11

From: Brian Dickson 
Date: Tuesday, October 29, 2019 at 12:37 AM
To: Alexander Mayrhofer 
Cc: "Livingood, Jason" , Brian Haberman 
, "dns-privacy@ietf.org" 
Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29

Hi, everyone interested in ADoT,
I'm planning on being on the call, although given the early hour for me I can't 
be sure I'll be on my game as much as usual...

In the interests of getting all the ideas I have after reading the -00 draft, I 
thought I'd send them to the list, and maybe they can be discussed on the call, 
time permitting.

Simple notion up front: add an EDNS flag or OPT code to signal ADoT support (or 
a bit field of all the supported transport types) on a given IP (analogous to 
the RA flag), and possibly include the canonical name(s) of the server at that 
IP, if the query include EDNS. This limits downgrades to on-path adversaries 
who block port 853 and modify port 53 traffic. Maybe SIG(0) or TSIG can further 
prevent downgrades by on-path attackers who would modify UDP/TCP port 53?

Certificates for DoT and DoH should really be DANE/TLSA entries. We're 
literally talking DNS here, so it would be particularly shortsighted not to 
standardize on this. It also potentially decouples from any hard dependency on 
particular CA support matrix, notwithstanding that the authoritative server 
might be using a CA-issued certificate. Having the ability to validate without 
needing to unilaterally trust some particular set of CAs is a feature not a bug.

State exhaustion protection mechanism, optionally use TCP cookies during 
handshake, regardless of TLS or not. This limits the TCP impact of needing 
established connections to do the TLS stuff to legitimate TCP connections only. 
Servers can limit the number of connections doing TLS handshakes, and 
prioritize those. The, use of aggressive timers on those prioritized 
connections protects against deliberate DOS via "slow transaction" attacks. 
Handshake-complete connections can be resumed, so making them lower priority 
and having aggressive connection dropping on those has comparatively low impact 
(since session resumption is cheaper than redoing the handshake). 
Experimentation is needed to establish recommendations on all the appropriate 
values (timeouts, number of sessions to support in each state, etc.)

The rest of the ideas mostly relate to the question "when is using DoT really 
optional, vs strongly desirable?".

I have a few suggestions along that line, as well as a few additional 
observations.

First, there is a strong correlation between the first time any client queries 
a given name, the visibility of the corresponding R2A query (presuming no 
ADoT), and the subsequent client data traffic (even with HTTPS).
The R2A (recursive to authoritative) query is a strong indicator that the name 
isn't cached (and may never have been cached).
This correlation may not be that important per se, but identifying it as 
somewhat distinctive means there's a reason to potentially look at the 
implications of that (from the perspective of ADoT being "strongly desirable").

In contrast, very popular domain names (and qtypes) are likely to be heavily 
served from the cache. If cache refresh (what was once identified in the HAMMER 
draft) is done for popular cache entries, there would no longer be any 
identifiable query triggering the R2A lookup, and in particular no timing side 
channel for identifying even a single DNS client.

What I'm suggesting is, using ADoT predominantly (or even exclusively) for 
"cold cache" lookups, and doing "cache refresh" lookups without ADoT, is one 
way to minimize the TLS overhead, which incurs a cost on the authority server 
(mostly CPU) and a penalty on the recursive (mostly latency, and maybe some 
CPU). Refresh without TLS would have lower latency, IMHO.

IMHO, the same rationale for "cold cache" also applies to "ECS" (EDNS client 
subnet). First instance (of a particular ECS parameter value), use ADoT; 
refresh, ADoT is optional.

The other question (observation?) is that ADoT is a poor substitute for DNSSEC. 
I.e. unsigned zones might seem like attractive reasons to force DoT for 
transport, but doing so would basically amount to "security theater". It would 
also discourage, rather than encourage, use of DNSSEC validation. It would be 
justifiable for an authority operator to respond "REFUSED" for ADoT queries 
doing "refresh cache" queries on unsigned domains, at least during periods of 
heavy load. Or maybe some new error code or EDE to signal "retry on non-TLS 
connections".

It remains an open (and perhaps interesting) question of the relative overhead 
of DNSSEC validation when compared with TLS transport. It might be interesting 
to compare those based on crypto algorithms (for negotiated TLS connections, 
and for DNSSEC zones), and based on various TTL 

Re: [dns-privacy] Comments on draft-lmo-dprive-phase2-requirements-00.txt

[Livingood, Jason]

Very helpful feedback! I recorded this as an issue to track down the last 2 
segments of your mail since those are very actionable.

Jason

https://github.com/alex-nicat/ietf-dprive-phase2-requirements/issues/10


From: dns-privacy  on behalf of Eric Rescorla 

Date: Tuesday, October 29, 2019 at 7:02 PM
To: "dns-privacy@ietf.org" 
Subject: [dns-privacy] Comments on draft-lmo-dprive-phase2-requirements-00.txt

Document: draft-lmo-dprive-phase2-requirements-00.txt

After reviewing this draft, it is not clear to me what architectural
model people have in mind. At a high level, say that I attempt to
dereference example.com and I have a cached NS record for 
.com. So, I
query example.com and get back:

- An NS record for the for the authoritative host, say
  ns.service.example.
- An A record for ns.service.example in the additional
  section.

Given this information, I then connect to ns.service.example
given this IP and query for example.com. So what happens 
when
we introduce TLS into the equation? In particular:

1. How do I know that the server handles TLS?
2. What identity ought the server to have and how do I verify it?

Now, we already have a worked example of a similar, though not
totally analogous situation in the Web case, so it might be
worth working through it. For instance, what happens when I
want to search for some term "example" at a search engine.
I connect to the engine, give it the term, and then it
gives me some possibilities, each of which is associated
with a link. I click on one, etc. In this scenario, the
answers to these questions are:

1. Primarily, the referring server tells me by using an https:
   URI rather than an http: one. If not, there is a way for the
   origin to redirect me to https:. It also is able to tell me
   that this origin should always use HTTPS using HSTS.

2. The server's identity is the domain name in the URL, and it's
   verified by having a WebPKI certificate with that domain name.

Note that there's basically no context in which the Web client
does any opportunistic probing as suggested by S 4.2. The client
is either trying to dereference something that is HTTPS or it is
not.


If we try to transplant this into the DNS model, it would seem we
want something like:

- There's something in the additional data section (i.e., the
  reference) that tells the recursive resolver that this nameserver
  supports DoT. [Analogous to the https: scheme]

- There's a way for a server to tell clients that it supports DoQ and
  commit to it for some future period [Analagous to HSTS.]

- The domain name in the NS record is used to authenticate the client
  via TLS, tied back to some external authentication scheme (WebPKI or
  DANE) [Analogous to the host portion of the HTTPS URI].


I think this helps answer some of the questions asked by this draft.
Specifically:

- In S 4.3, the answer ought to be "by identified nameserver". The
  other alternatives seem much more confusing to reason about.
  IP address specifically is a problem because it courts downgrade
  attacks.

- In S 4.3, I don't think talking about privacy over availability
  is that helpful. The semantic you want is that the server
  is committing to supply DoT for some period of time and then
  clients can decide if they want DoT. I think it's unwise to
  ever allow fallback from DoT to Do53 because that makes
  downgrade easy. I would expect that recursive resolvers
  will by and large operate in environments where DoT filtering
  is not an issue.

- S 5.3, I don't understand why you would want to allow an
  opportunistic mode at all. Whether your preference is DANE
  or WebPKI, we're certainly at a point where authentic
  server identities are readily available, so why make
  life complicated?

-Ekr














___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] draft-lmo-dprive-phase2-requirements-00.txt, wiretapping, and RFC 2804

[Livingood, Jason]

Can you be more specific on your bullet list? What I mean is that this list 
seems covered in "Threat Model and Problem Statement" so I am wondering what 
gaps there may be there, if any. Perhaps just ensuring you are talking to the 
correct/intended server (the cert issue you note)?

Jason

On 10/29/19, 3:08 PM, "dns-privacy on behalf of John Levine" 
 wrote:

In article 
 you write:
>
>I appreciate the authors kicking off the effort with this draft that
>proposes phase 2 requirements.

As do I, but it still needs a lot of work.

One thing that would help me a lot is matching up the features with
what problem they're supposed to solve.

* Keeping specific people from seeing your query stream (e.g., your ISP)
* Keeping random snoopers from seeing your query stream
* The above for particular parts of your query stream, e.g. 2LDs
* Being sure you're talking to the right server (the certificate issue)
* Other stuff?

Depending on what your goal is, you might mix and match other techniques
like local mirroring of zones, at least ones that aren't too huge.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] draft-lmo-dprive-phase2-requirements-00.txt, wiretapping, and RFC 2804

[Livingood, Jason]

How does this change suit you? 
https://github.com/alex-nicat/ietf-dprive-phase2-requirements/pull/9/commits/7662d32616c4b1bf8da43f782974cf9dcf9aeebc

s/ and to comply with locally relevant law enforcement or regulatory 
requirements/ and to comply with locally relevant legal requirements

or should it change to “locally relevant requirements”?

Jason

From: dns-privacy  on behalf of Patrick McManus 

Date: Tuesday, October 29, 2019 at 12:20 PM
To: DNS Privacy Working Group 
Subject: [dns-privacy] draft-lmo-dprive-phase2-requirements-00.txt, 
wiretapping, and RFC 2804

I appreciate the authors kicking off the effort with this draft that proposes 
phase 2 requirements.

On a couple of occasions the draft makes creates requirements wrt law 
enforcement compliance. e.g. "comply with locally relevant law enforcement [..] 
(high priority)"..

While RFC 2804 says
"The IETF has decided not to consider requirements for wiretapping as part of 
the process for creating and maintaining IETF standards.". There is clear 
guidance for avoiding this requirement in any document designed to create an 
expectation of privacy from end to end, before it is adopted by a WG.

-Patrick
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] ADoT requirements for authentication?

[Tony Finch]

Some miscellaneous thoughts vaguely related to the discussion ...

## nameserver hostnames in certificates

It's not uncommon for zones to use in-bailiwick aliases for their
nameservers, which avoids transitive configuration dependencies and speeds
up resolution because the resolver gets glue with the referral rather than
having to chase down server addresses.

(see discussion of gluelessness on https://cr.yp.to/djbdns/notes.html)

This is obviously problematic for using hostname authentication. I suppose
a server could provide its IP address(es) and official hostnames in its
cert to allow either for authentication...

## third-party secondary servers

If the ADoT status is in the delegation (special DS records, special NS
records) then that implies a nasty co-ordination cost to any changes.

## glueful bootstrapping

If we rely on TLSA records at the nameserver's hostname then there's a fun
bootstrapping problem for in-bailiwick delegations. If a resolver queries
for the TLSA records in the clear then they'll leak the zone name; if it
speculatively tries TLS then it might be really slow waiting for timeouts.

## reverse dns bootstrapping

If the resolver looks for TLSA records in the reverse DNS there's a fun
case where it has a referral for (say) example.com with glue for
ns1.example.com in 192.0.2.1, but then it finds that ns1.example.com is
also a server for 2.0.192.in-addr.arpa. The resolver needs to be able to
re-use the forward DNS glue to get to the reverse DNS zone.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Great Orme Head to the Mull of Galloway: East or southeast 4 to 6. Smooth or
slight, occasionally moderate in west. Fair. Good.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[Paul Wouters]

> On Oct 29, 2019, at 20:44, Ben Schwartz  
> wrote:
> 
> 
> 
> 
> 
> My understanding is that one has no choice but to trust the parent zone, even 
> with DNSSEC. 

One can limit the trust severely, which is what 
https://datatracker.ietf.org/doc/draft-pwouters-powerbind/ does.

Paul


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[Ralf Weber]

Moin!

On 30 Oct 2019, at 1:37, Watson Ladd wrote:
> The root zone is data: whether one distributes it via DoT, DoH, IPv6, or
> carrier pigeon is irrelevant to the policies that goven what's in it. And
> furthermore none of the network engineering issues raised against DoH apply
> to recursive to authoritative.
>
> We absolutely can engineer reliable anycast clusters to handle 100,000
> queries a second. That's only 100 cores if each core can do 1000 queries a
> second.
We can and I don’t think Jim questioned that it is technically possible. But
someone has to pay for it and there are layer 9 problems. At some parts of
the DNS infrastructure the margins are thin and increasing your server load
or server foot print for ADoT might be the difference between making a profit
or a loss.

> Akamai handles a substantially greater  volume of considerably more
> expensive HTTPS traffic: the DNS queries are part of the HTTPS.
That is true, but we also have way more servers for HTTPS then for DNS, and
while I don’t want to see DNS traffic inside the same channel that delivers
content for various reason that for sure won’t happen with ADoT as we are
talking about a resolver and not and end client issuing the queries.

> Encryption at the root is very possible.
It for sure is, but it’s not as easy and I see the root probably being one
of the latest adopters of ADoT. In general that does not matter. We have
to design a protocol first and then maybe look at the special cases some
part of the tree might have.

So long
-Ralf
—--
Ralf Weber

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29

[Alexander Mayrhofer]

Brian,

sorry, i haven’t yet posted the link to the list. The Repo is here:

https://github.com/alex-nicat/ietf-dprive-phase2-requirements

If anybody is in desperate need of elevated permissions on the repo, please let 
me know ;)

best,
Alex


Von: dns-privacy  Im Auftrag von Brian Dickson
Gesendet: Dienstag, 29. Oktober 2019 19:51
An: Brian Haberman 
Cc: dns-privacy@ietf.org
Betreff: Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29

Does anyone who was on the call, have the URI of the github doc, please?

Off-list response is fine.

Brian Dickson

On Fri, Oct 25, 2019 at 8:04 AM Brian Haberman 
mailto:br...@innovationslab.net>> wrote:
Hi Paul,

On 10/25/19 10:27 AM, Paul Hoffman wrote:
> On 10/25/19 6:25 AM, Brian Haberman wrote:
>> https://datatracker.ietf.org/doc/agenda-interim-2019-dprive-01-dprive-01/
>>
>> On 9/25/19 10:45 AM, Brian Haberman wrote:
>>> All,
>>>   We are going to hold a DPRIVE virtual interim meeting on Oct. 29th
>>> at 4:00pm CET / 11:00am EDT / 8:00am PDT. The three agenda items are:
>>>
>>> - Review updates to the BCP based on WGLC comments,
>>> - Review updates to 7626bis based on WGLC comments,
>>> - Discuss recursive-to-authoritative requirements (-00 draft forthcoming).
>
> Will we be able to review the forthcoming recursive-to-authoritative 
> requirements draft before the interim meeting?

I have asked the authors to post either a -00 draft or a doc on GitHub
before the interim.

Brian

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

[Watson Ladd]

On Tue, Oct 29, 2019 at 8:30 PM Jim Reid  wrote:
>
> On 30 Oct 2019, at 01:32, Eric Rescorla  wrote:
> >
> >> Yes, it's hard, but I think it's worthwhile, because the prospect of
getting the root to offer ADoT seems very distant to me.
> >>
> > Why? Do we have estimates of the load level here as compared to (say)
Quad9 or 1.1.1.1?
>
> The root server operators publish statistics on the traffic they get.
Links for some of their data can be found at https://root-servers.org.
>
> The anycast cluster for a.root-servers.net alone currently handles
upwards of 8B queries/day - roughly 100,000 queries/second. That’s steady
state. The numbers would go *far* higher than that during a Mirai-style
DDoS attack.
>
> It’s going to be a challenge to get authoritative servers handling those
sorts of query levels to support DoT (over TCP?). FWIW solving the
non-trivial operational and engineering issues will be the easy bit.
Solving the layer-9 issues will be harder. I expect that also holds for DoT
support at authoritative servers for important TLDs or the DNS hosting
platforms from the likes of Akamai, Dyn, UltraDNS, etc that handle very
high query rates.
>
> I suppose someone could ask RS SAC* for their opinion on deploying DoT at
the root. And having lit the blue touchpaper, I will now run away at great
speed to watch the ensuing firework display. :-)

The root zone is data: whether one distributes it via DoT, DoH, IPv6, or
carrier pigeon is irrelevant to the policies that goven what's in it. And
furthermore none of the network engineering issues raised against DoH apply
to recursive to authoritative.

We absolutely can engineer reliable anycast clusters to handle 100,000
queries a second. That's only 100 cores if each core can do 1000 queries a
second.

Akamai handles a substantially greater  volume of considerably more
expensive HTTPS traffic: the DNS queries are part of the HTTPS.

Encryption at the root is very possible.

>
> * Other ICANN advisory committees are available.
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy


--
"Man is born free, but everywhere he is in chains".
--Rousseau.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy