Quad9 -- mostly constructive comments (Was: Google DNS on Salt Mobile)

On 2018-11-01 09:18, Bill Woodcock wrote:
[..]
> No, that’s false.  Please read RFCs 7816 and 7871.  Quad9 implements
> the former and not the latter

And because of the latter instead of going to the local ISP netflix 
cache one might go to the country-level cache or because it does not 
know better to the continental cache. GeoDNS goes rather bad when the 
source address is odd.
Next to the problem of load-balancing or traffic engineering that the 
sending party is trying to fix by doing those tricks in the first place.


Hence, supporting ENDS-Client-Subnet (stripping at minimum to BGP or /24 
or /48 subnet) would be a good thing.
If it is not considered a good thing, a little note on the site why not 
would go a long way.


> Again, if, after acquainting yourself with Quad9’s practices and the
> relevant RFCs, you see any way in which Quad9 could provide better
> privacy or security protections to users, they would VERY MUCH LIKE
> YOUR CONSTRUCTIVE INPUT, as that’s the entire point.  It’s an open and
> transparent community project, to serve the community.


- Please put on the quad9 website a _versioned_ "policy" and "privacy" 
page, thus that one can also see the previous editions. That would be 
good transparency.
- align https://quad9.net/about/ with them, as "policy" does not mention 
"no other secondary revenue streams for personally-identifiable data" 
which is a 'good' sentence, but needs repeating there too.
- Create a minimal version of those; 99% of the people do not bother 
reading them at all, let alone when too long.

- Provide a /technical/ details page:
  - what software is used (e.g "we run bind4 custom patched by vix 
himself") and when possible point to Open Source to recognize their 
efforts (one does run multiple different resolver types to avoid any 
bugs I hope ;)
  - what actual RFCs/techniques are (not) used
    - why for instance RFC7871 is chosen not be to be supported
    - that DNSSEC is supported and that validation is active

  - list of providers of 'malicious domains' and who randomly 
samples/verifies that list (otherwise: who censors it)
    "Quad9 checks the site against a list of domains combined from 19 
different threat intelligence partners."
    does one hit in a list block the domain, or do N lists (RPZ?) need to 
blacklist it?
    (RPZ does not have spamassassin-like scoring, asked for that option 
once though, but it is hard to do ;)

Technical details (even though not verifiable as one does not have 
access to the infra) would be a great thing.



Some other not-so-constructive comments (I snipped around those sections 
of the mail):

- Remove refs to "not-for-profit" as that just means that all the money 
goes into the business instead of paying taxes...
- "The three primary founding collaborators for the project have goals 
that are similar.", I can only assume that Big Blue is not a founding 
collaborator then... but the logos tell differently.

> in order to minimize the leakage of
> data from end-user to authoritative server.  Moreover, that’s only an
> issue with zones for which PCH is not authoritative.  For all those
> for which PCH is authoritative, no queries pass “through” to anywhere
> else.

(I can only assume that you mean "9.9.9.9 recursor sits on the same 
net/vlan/switch as the PCH auth, thus it never leaks ;)

>> Integrity is a bigger issue and there are many examples where it is 
>> actively
>> being violated - this is at least partially addressed by DNSSEC.
> 
> Which is why Quad9 was the first global anycast resolver to implement
> DNSSEC validation, and why PCH is the only DNSSEC operator besides
> ICANN to implement FIPS 140-2 Level 4 security.

"global anycast resolver". That is a DNS recursor that is 'open for the 
world' right? :)



Greets,
  Jeroen



_______________________________________________
swinog mailing list
[email protected]
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog