@jsbsmd said in SAD DNS and unbound question:
they will have access to multiple blocking lists that "I hope" staff will be monitoring them.
Quad9 is a non-profit project funded by donations, so we don't have a lot of staff, but there's a field and button on the front page of the web site for checking whether we're blocking a domain in the malware-blocking version of the service, and if so, which feed reported it, and any reasons they may have stated. There's also a button for people to report something as a false positive, and we do investigate anything that's reported as a false positive, though that's kind of time-consuming, because the badguys of course report all their stuff as false positives too... And we keep stats on how many times each blocking rule gets exercised without a false-positive report, and reputation-score each of the threat intel feeds. And we keep a list of things that should never be blocked even if they come up in a threat intel feed, so when a threat intel feed includes something on that list, that also contributes (negatively) to their reputational score. Since there are, at any time, millions of things being blocked, and the level of churn is very high (as domains stop being used by badguys and leave the list), there's no way for our small group of staff and volunteers to proactively research each case before it goes into the blocklist, but also the vast majority (more than 99.99%) of blocked domains are never reported as false-positives, either while they're blocked, or after the fact.
Will connecting to 9.9.9.9 using udp 53 protect a user or is it a must to use ssl/tls 853? Just thinking about man in the middle attacks.
"Defense in depth" means a series of layers and complimentary security measures which all contribute to a more safe posture. So, there are several answers to that question, all valid and cumulative:
Using 9.9.9.9 gives you access to an aggregate set of threat intel which is not available in any other way (since it includes internal (not-available-as-a-product) threat data from several large security teams in companies which compete with each other). That's one benefit, and is available regardless of the transport protocol between the user and our recursive resolver.
Using 9.9.9.9 also gives you an external DNSSEC validator. It's better to not have to rely upon someone else for that, but relying on someone else is better than not doing it at all. And for most people, most of the time, there's no mechanism by which they could do it themselves, since it's unfortunately not supported in any significant number of endpoints, and most people don't run their own forwarding/validating or recursive/validating resolver. To be clear, the correct place to do DNSSEC validation is in the endpoint, but there's almost no support for that by vendors, and it's not something that can be easily added in to many platforms by a third party. So we all have to keep pushing for that over time.
Using 9.9.9.9 protects you from the recursive resolver recording your DNS resolution history, and protects you from parties upstream from the recursive resolver seeing your query or associating it with you, but if you use a UDP/53 transport rather than one of the encryption methods (DoT, DoH, or DNScrypt), any party between you and the recursive resolver can record your query and associate it with (at best) the public-facing IP address used to transmit it, or (at worst) a unique "cache busting" key tied to your identity.
In addition, using UDP/53 also leaves you open to man-in-the-middle attacks in which the recursive resolver is impersonated by another entity, usually the access-providing ISP, who may have contracted with a third party to capture and monetize queries.
So, we strongly recommend encrypting the connection between you and your recursive resolver, both for your privacy, and also as a step toward authenticating the recursive resolver. While that authentication currently depends on CA certs, which don't actually provide any security, as that process gets upgraded to DANE certs, that will become real strong authentication that you could rely upon.
