Re: [dns-operations] DoH client software using HTTP/1.1?
--- Begin Message --- On 02/04/2024 20.44, Christoph via dns-operations wrote: Do you know any DoH client software that is actually deployed and used in real world that does not support HTTP/2 yet? I know that some MikroTik routers used to support 1.x only. (Knot Resolver ever only supported that with experimental DoH code, so that's how we got to know.) --Vladimir --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Filtering policy: false positive rate
--- Begin Message --- On 06/02/2024 17.06, Peter Thomassen wrote: Then, how to define a false positive rate? Look at all blocked queries, and do a post-hoc investigation? How about popularity -- should one factor in that blocking *.ddns.net is more severe than blocking *.blank.page? I.e., is it a ratio of blocked/total queries, or blocked/total names? Yes, primarily post-hoc I expect - I mean, if we could easily recognize false positives in advance, we'd do that during the blocking, right? I'd do this statistically. Take a sample from the blocked names. You could weight the names with whatever you like when choosing among them, e.g. the mentioned popularity by unique IPs querying them. Then evaluate the sample in some better way, probably by a human. You could mix in a sample from non-blocked names, too (say [1]). I think it's not difficult to design these measurements in a way that you get an OK ratio of complexity (and human work) vs. precision of the false-positive estimate. Actually I suspect that it's probably *not* worth trying to affect the choice of the evaluated sample by reports from users, as it's probably very hard to get statistically correct-ish numbers out of that. [1] https://en.wikipedia.org/wiki/Scientific_control#Controlled_experiments (reposted from a correct e-mail address; Peter will probably get a duplicate) --Vladimir | knot-resolver.cz --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] anchors.atlas.ripe.net/ripe.net - DNSSEC bogus due expiration
--- Begin Message --- On 01/11/2023 17.18, Viktor Dukhovni wrote: Should authoritative resolvers have knobs to perform internal checks on the signed zones they serve and at least syslog loud warnings? My understanding is that in this case the signer was producing loud syslog warnings immediately when the issue happened (i.e. long before validation could fail). --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Why is DNS still hard to learn?
--- Begin Message --- On 29/07/2023 13.52, Stephane Bortzmeyer wrote: As usual, a good practical article by Julia Evans: For reference, in May there was a (slightly heated) discussion about this article on OARC's public chat: https://chat.dns-oarc.net/community/pl/ccajpprxttnmzj5a8mh4hh1kua --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Google Public DNS has enabled case randomization globally
--- Begin Message --- On 29/07/2023 23.20, Puneet Sood via dns-operations wrote: The worst are the small number that return NXDOMAIN for the queries or timeout. Those are clear protocol violation, as the names are case insensitive from the very beginning (RFC 1034 + 1035), regardless of deploying the 0x20 draft. I'll be glad if they start failing on 8.8.8.8 now, hoping that would put sufficient pressure on such cases. However, relying on receiving the same case is more difficult, as AFAIK no RFC implies that the cases in QNAME need to match. But yes, that TCP fallback is a nice workaround for those uncommon cases, so it doesn't matter really. We've used it in Knot Resolver's implementation for years, as case randomization is default there. (Of course, nowadays I'd ideally focus on more secure anti-spoofing techniques like DNSSEC...) --Vladimir --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region
--- Begin Message --- On 18/07/2023 23.53, Viktor Dukhovni wrote: On Tue, Jul 18, 2023 at 10:25:01PM +0200, Ondřej Surý wrote: It’s exactly like the serve-stale. The inception of the protocol change is driven by this isolated incident. That’s not a proper design, that’s slapping more bandaids on the camel. I don't even see a "protocol change" here. A bogus (possibly forged) answer arrived from server A, perhaps server B should be tried. I agree that at least one retry to a different IP seems nice before returning SERVFAIL, similarly to the case of reply not coming (in time). I thought popular resolvers do something like that already. But as mentioned, it's better to be careful about the overall amount of retries (which is not trivial to balance really). As for papering over issues, ideally most problems would not be solved as response to "internet breaking" for common users, though I'd generally try to avoid adding workarounds. Serious deployments should have monitoring to detect such problems, or possibly even approaches like this (though I'm not so sure): https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/ --Vladimir | knot-resolver.cz --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Cloudflare TYPE65283
--- Begin Message --- On 27/03/2023 17.09, Viktor Dukhovni wrote: On the fly signing with compact denial of existence is a bleeding-edge behaviour, and one might expect that the software in question is not ossified and operators might be proactive. Cloudflare's blog post about this is from 2016, so I wouldn't consider this particularly new. Though maybe still not ossified yet, as you write. https://blog.cloudflare.com/black-lies/ --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] ENT NXDOMAIN problem at .BS nameserver ns36.cdns.net
--- Begin Message --- On 22/09/2022 16.12, BS Domain Technical Contact wrote: Please provide an update regarding the same. Thanks. I'm still getting NXDOMAIN. It's fairly easy for anyone to check by running e.g. dig @ns36.cdns.net com.bs. --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] ns1-proddns.glbdns.o365filtering.com unreachable?
--- Begin Message --- On 06/07/2022 11.01, Thomas Mieslinger wrote: Anyone else with trouble to reach the *.o365filtering.com DNS Servers? I believe that's discussed here: https://chat.dns-oarc.net/community/pl/m864xf3xrf8adqm8kx6sdku6bo --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Input from dns-operations on NCAP proposal
--- Begin Message --- On 06/06/2022 16.57, Dave Lawrence wrote: To be clear, I'm not saying they*should* do it. I'm just trying to better understand the context. If the root zone is unchanged, many names could be hidden before reaching root servers - by DNSSEC aggressive caching and/or various local-root variants. (I'm not sure if we can well measure the extent to which this happens.) --Vladimir | knot-resolver.cz --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Input from dns-operations on NCAP proposal
--- Begin Message --- On 23/05/2022 15.48, Thomas, Matthew via dns-operations wrote: Configuration 1: Generate a synthetic NXDOMAIN response to all queries with no SOA provided in the authority section. I believe the protocol says not to cache such answers at all. Some implementations chose to cache at least a few seconds, but I don't think all of them. Breaking caching seems risky to me, as traffic could increase very much (if the TLD was queried a lot). Configuration 2: Generate a synthetic NXDOMAIN response to all queries with a SOA record. Some example queries for the TLD .foo are below: It still feels a bit risky to answer in this non-conforming way, and I can't really see why attempt that. At apex the NXDOMAIN would deny the SOA included in the very same answer... Configuration 3: Use a properly configured empty zone with correct NS and SOA records. Queries for the single label TLD would return a NOERROR and NODATA response. I expect that's OK, especially if it's a TLD that's seriously considered. I'd hope that "bad" usage is mainly sensitive to existence of records of other types like A. --Vladimir | knot-resolver.cz --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] CNAME at the apex breaks DNSSEC DS lookups from caches
--- Begin Message --- On 4/21/22 03:15, Mark Andrews wrote: My main worry is this, correct, cache behaviour breaks DNSSEC validation through a recursive server. Yes, same with Knot Resolver. When communicating with auths directly it does work I think, but it never worked with forwarding when signed (for us). Consequently, we know that these breakages don't have significant practical impact, due to some real-life deployments which default to forwarding with validation (by Knot Resolver; e.g. Turris). --Vladimir --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
