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
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
