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