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
Re: [dns-operations] console.aws.amazon.com - breakage & confusing output from DNSViz?
On 07/02/2022 19.27, Matthew Richardson wrote: Knot Resolver returned NXDOMAIN Are you sure that you used the latest version? (5.4.4, a month old) Bug details: https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1237 --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] TLD .law - non-signing KSK with referenced DS
On 17/01/2022 11.00, Matthew Richardson wrote: Given that having a standby key is a standard (and probably good!) practice, should Zonemaster perhaps classify this as less of a problem, maybe as a "warning"? I already opened https://github.com/zonemaster/zonemaster/issues/1036 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Interesting increase in query volumes
On 25/11/2021 08.54, Juselius Juhani via dns-operations wrote: -Is there anything we could do for the traffic I'm sure it would lighten your load if you ensured that even negative replies from your servers can fit into UDP comfortably, ideally under 1232 bytes [1]. Many big TLDs take great care to fit, and my favorite way would be algorithm 13 (ECDSA, e.g. in my .cz TLD) but there are others. It's not so much about this particular problem you report, more like generally increasing robustness. [1] https://dnsflagday.net/2020/ --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] glb.cdc.gov nameservers not accepting TCP
On 20/10/2021 20.01, Viktor Dukhovni wrote: This is IIRC a well-known longstanding issue. Yes, non-support of TCP certainly isn't new there: https://dnsviz.net/d/glb.cdc.gov/Xp3Epw/dnssec/ ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Full-service resolver - Pending Upstream Query behaviour
On 05/10/2021 18.01, Frederico A C Neves wrote: I would like to start a discussion or to hear implenters and operators of Full-service resolvers on what would be the best software architecture or best current configuration practice to handle a traffic pattern when a very popular name enters a scenario were all the auth-servers are timing-out or network unreachable. I'm not sure if there can be *one* BCP way. I suspect it would even be harmful if all vendors aimed for the same approach here, as for rarer (combinations of) events I see lack of diversity as additional risk. (be it on scale of one resolver provider or wider internet) I suppose it would be possible to collect ideas from whoever wanted to contribute them, in some way, or at least collect "common problems" that need to be addressed - without prescribing too much how to solve them. --Vladimir | knot-resolver.cz ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Incomplete type bitmaps in NSEC(3) records and aggressive use of DNSSEC validated cache
Hello. On 08/09/2021 11.12, Ruben van Staveren via dns-operations wrote: should we do more analysis of this phenomenon and even have a dns flag day before even more resolvers and operators are going to implement RFC8198? There might be an issue by deliberately exploiting this and make websites/mail unreachable. Measuring how much this happens might be nice (or similar problems), but I don't think it will be worth a flag day. Aggressive resolvers have been deployed for years, and it apparently hasn't caused that much trouble. As for possibility of exploitation... experience (e.g. with F5) shows that some parties just won't fix stuff until there's significant pressure. I'd think that now the "gradient" for this is that operators should deploy aggressive caching instead of delaying, and that will help cleaning up this behavior (which has been non-compliant since RFC 4034+, not since 8198). --Vladimir | knot-resolver.cz ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] RRSIG expiry versus TTL
On 05/09/2021 19.31, Andrew Sullivan wrote: This is false in multiple ways. First, RRSIGs are in fact resource records and it _is_ possible to query for them directly: I would not advise using QTYPE=RRSIG. Mainly because you may get sigs for some other versions of RR sets than those obtained in a different DNS message. Also, RRSIG queries have similar DoS potential as ANY. https://datatracker.ietf.org/doc/html/rfc8482#section-7 Generally I'd recommend to treat sigs as attached to their respective RR sets. the RRSIG TTL should match the NS record TTL, but ..., the validating resolver does not care, and should not, about RRSIG TTL. So the difference between the expiration of the rrsig and the TTL shouldn't or doesn't impact the online services. Also false. Caches do not look at the RRTYPE to decide how to cache. They just cache whatever comes along for the TTL. If your RRSIG expires while it is cached, you will go bogus. This is discussed (IMO somewhat elliptically, because there was some controversy about what the Right Thing was, IIRC, and it never really got resolved) in RFC 6781. Well, that depends on the caches. RRSIGs do have special rules for TTL handling... which is surely the reason why dnsviz says "cache of *non-validating* resolver" See https://datatracker.ietf.org/doc/html/rfc4034#section-3 The TTL value of an RRSIG RR MUST match the TTL value of the RRset it covers. Also, TTL should be trimmed (by signers and validators) not to go past RRSIG expiration (or original TTL). I can't recall where this is stated and how strongly. To be clear, I agree with dnsviz that the state was not correct. I don't like arguments in style "I tried it and it worked for me, so it's OK". They make me dislike Postel's law. --Vladimir | knot-resolver.cz ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS
On 30/08/2021 17.02, Petr Špaček wrote: [...] It is clear to this group of DNS experts, but I think we should lend a helping hand to DNS consumers and at least explain why consumers have to check everything. Is anyone interesting in writing a short RFC on this topic? That might serve as a good reference when some DNS expert points out to others why they shouldn't be doing what they're doing. However, I don't think we can expect a new RFC (by itself) to reduce these cases: *if* they were reading DNS RFCs, they would've surely realized that they need to be more careful. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS
On 18/08/2021 01.49, Paul Ebersman wrote: DNS is a complicated, esoteric knowledge set. The reason apps, middleware and various other boxes mucking with DNS in transit tend to suck is exactly because the programmers on those boxes don't have this expertise and make all sorts of bad assumptions about what is safe/sane. I typically put the blame on them trying to dissect what they don't understand instead of using some library or tool that does. OK, perhaps the toolset could be improved, but I don't think we can make the DNS *protocol* itself easy (not anymore; maaaybe after a big incompatible redesign but who dares to push for that). It's similar to why you should not code TLS yourself, though there it's more obvious that you'll be prone to security bugs. --Vladimir | knot-resolver.cz ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] peacecorps.gov: large NXDOMAIN replies and no TCP service
It's not just a problem for NXDOMAIN. Their DNSKEY response is over 1250 bytes, so those who use a lower limit (e.g. 1232 recommended by dnsflagday.net/2020) will have no access to that subtree at all. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] why does that domain resolve?
On 05/06/2021 13.11, A. Schulze wrote: Is "being client centric" a candidate for a "dns-flag-day-2022"? Consider .com like to intercept gmail.com. Changing the delegation in .com would be enough. Really? The parent has full control of its subtree anyway. They can even roll the DNSSEC key of the child to anything. Getting a TLS cert for "big names" will be hard without causing alarm, though (e.g. cert. transparency)... and you'd surely need that to intercept e-mail towards an end-client. Recent discussion threads I see as related were around these two proposals: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-ns-revalidation-00.txt https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-delegation-only --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] nsec vs nsec3 use
On 13. 04. 21 18:40, Viktor Dukhovni wrote: - With NSEC you benefit from aggressive negative caching reducing query load on your authoritative server. Tiny detail: NSEC3 without opt-out also allows aggressive caching with the same benefits but it's less common. (so NSEC does give advantage there) Tony> Maybe use NSEC3 if you have a stunt DNS server like Cloudflare's that is able to generate narrow NSEC3 denials I think even for online minimal responses, NSEC will be a slightly better choice. (Cloudflare are such an example) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Spurious (?) DNSSEC SERVFAIL with some (?) versions of BIND for one domain?
On 3/11/21 9:21 AM, Matthijs Mekking wrote: which apparently has a DS at the apex of the child zone, which is somewhere between 'useless' and 'wrong'. It is more wrong than useless: From RFC 4035: All DS RRsets in a zone MUST be signed, and DS RRsets MUST NOT appear at a zone's apex. I've also encountered DS in the middle of a zone -- i.e. on a name without NS, in this case also with some child names existing within the same zone. I didn't find that it's really forbidden, but on the other hand I've had no motivation to fix Knot Resolver's forwarding+validation mode to tunnel through such an obstacle. That zone got fixed eventually, too. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Possibly-incorrect NSEC responses from many RSOs
On 3/2/21 2:23 PM, Peter van Dijk wrote: My suggestion (seriously): prohibit NSEC and RRSIG queries. They are ambiguous and nobody has any use for their output anyway. Not supporting them can really simplify some implementations as well (I submit RFC 8482 as exhibit A.) +1 In the sense that I can't see why a meaningful answer should be *required* in those cases. I don't really mind if someone does such a query or tries to provide a meaningful answer to it. --Vladimir | knot-resolver.cz ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Quad9 DNSSEC Validation?
On 2/28/21 10:11 AM, Bill Woodcock wrote: We put in negative trust anchors where safe and necessary to keep things working for actual users, because if we don’t, we get drowned by support calls. My (naive?) hope is that large validating services could form some agreement to start acting stricter in this respect. Of course it's often hard to argue that a breakage is the domain's fault as long as it works almost everywhere else, but dnsflagday.net has shown that similar arrangements are possible to pull off. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Possibly-incorrect NSEC responses from many RSOs
On 2/28/21 8:47 PM, Paul Hoffman wrote: [1]https://tools.ietf.org/html/rfc8482#section-7 [tools.ietf.org] That RFC (a) doesn't update RFC 4025 and (b) is only about QTYPE of "ANY". I meant just the informal future-work note focused on QTYPE=RRSIG (in the linked section), to support my claim that there are advantages in avoiding full replies to such queries. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Possibly-incorrect NSEC responses from many RSOs
On 2/28/21 3:24 AM, Paul Hoffman wrote: On Feb 27, 2021, at 5:32 PM, Mark Andrews wrote: It says that RRSIGs exist at that name. Could you say more? I don't understand the context here. For example, "dig @f.root-servers.net -4 nl rrsig" gives a reply with no Answer section. Explicit QTYPE=RRSIG is a gray area, I believe. In some cases it could be a DoS vector [1], and I don't know of a use case for such a query, so it makes sense not to answer (in full). In your particular example, if you ask for DS nl, you will get all RRSIGs for that name-type pair. Overall, it's even explicitly standardized that RRSIGs do not form an RRset; they're more like an appendage to the RRset they sign. [1] https://tools.ietf.org/html/rfc8482#section-7 --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] NXDOMAIN status, with answers?
Hello. On 2/8/21 3:00 PM, Anthony Lieuallen via dns-operations wrote: Is this (NXDOMAIN status, but CNAME and RRSIG in the answer) valid, per the spec In case of a CNAME chain, the RCODE refers to the end of the chain (i.e. past the last present CNAME). All CNAMEs in the ANSWER section are implied to be NOERROR. A common example is SERVFAIL, too. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] NSEC3 parameter selection (BCP: 1 0 0 -)
On 1/18/21 11:41 PM, Viktor Dukhovni wrote: For the salt to makes sense, and warrant rotation, one would have to operate a zone with enough records that some are hard to predict, sensitive and yet published (and not visible in transparency logs, PTR records, ...). This is very much a corner case. Perhaps, but this and some other arguments seem to be even against attempts to hide zone contents. I didn't mean to consider those in my post, as you had covered them nicely by the NSEC and opt-out bullets. My personal opinion is that most TLDs would better use NSEC instead of NSEC3, though it's possible that I just don't know their motivation for the policy. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] NSEC3 parameter selection (BCP: 1 0 0 -)
On 1/18/21 7:55 PM, Viktor Dukhovni wrote: The non-empty salt is pointless, but basically harmless. [...] Because: 1. Every zone is effectively already salted, because as you note below the hash covers the FQDN. 2. Changing the salt takes some care, so "nobody" does it. 3. Combining 1 and 2 we conclude that a fixed salt is no better than an empty salt. OK. I do agree that salt is pointless *unless* rotated. Even the original RFC 5155 clearly says that "The salt SHOULD be changed periodically". And to me it just... seemed relatively easy to do, if you already do resigning, rotating *SKs, etc. Both technically and in practice: https://www.knot-dns.cz/docs/3.0/singlehtml/#nsec3-salt-lifetime (since year 2016 in this case) The best part IMHO is that rotating a few bytes of salt is relatively easy and cheap for the good guys, in comparison to how much it hinders dictionaries. Properties of the iteration count seem far worse. It would be good to see all the iteration counts drop to 10 or less, ideally just 0. Certainly. 100 iterations seems ridiculous to me and I'm surprised the number got such a large share, though perhaps I'm personally biased against trying to hide contents of common TLD zones by NSEC3. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] NSEC3 parameter selection (BCP: 1 0 0 -)
Hello everyone! On 1/18/21 7:57 AM, Viktor Dukhovni wrote: The non-empty salt is pointless, but basically harmless. Why should salt be pointless? Can you hint/link? Quick link to original motivation: https://tools.ietf.org/html/rfc5155#appendix-C.1 (Though it seems relatively weak to me... nowadays I can't really imagine practical dictionaries for DNS names that would be "too expensive" to rehash whenever resigning happens.) I find the shared "salt" value somewhat "amusing" Whole FQDNs are hashed, so sharing salt among different zones seems safe to me, though I must admit I have no idea why anyone might want to do it. Though if salt is pointless overall... --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On 1/5/21 8:21 AM, Viktor Dukhovni wrote: On Tue, Jan 05, 2021 at 08:07:16AM +0100, Vladimír Čunát wrote: Off the top of my head, I don't even now how exactly is the escaping specified in RFCs. That's easy, any*non-digit* character can be escaped with a preceding "\", or alternatively as a 3-digit*decimal* \DDD sequence. Right, though my interest at this moment was more about how to *output* a name: there's lots of freedom and apparently no "preferred" way (in RFCs). Maybe it's not bad; otherwise more tools might start relying on one particular way of output. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On 1/5/21 5:52 AM, Paul Hoffman wrote: I brought the issue to this mailing list, instead of to the UltraDNS folks, because I am using tools that expect host names instead of domain names (in this case, dig); now I have to write shims around them. In case it helps you, kdig escapes punctuation characters like '!' and '~' (contrary to original dig, apparently). Off the top of my head, I don't even now how exactly is the escaping specified in RFCs. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Strange behavior of www.cdc.gov (was: Strange behavior of covid.cdc.gov)
On 12/25/20 1:12 AM, Robert Edmonds wrote: I'm also seeing intermittent SERVFAILs with www.cdc.gov. Some of their answers are broken. We now had a discussion about it on: https://gitlab.nic.cz/knot/knot-resolver/-/issues/662#note_188577 --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode
On 11/18/20 1:36 AM, Phil Pennock wrote: > Double-check: in such a scenario, if the request is for the recursive to > validate DNSSEC and this zone is not opt-out, then the recursive would > HAVE to get the data from the child, because the parent won't have RRSIG > records for the glue NS, right? > [...] I believe the requirements are stronger and a server may never put parent-side data into ANSWER section. Validation can help in the sense that if it succeeds, it doesn't matter where the data came from. The best reference is probably rfc2181 5.4.1 again: >Unauthenticated RRs received and cached from the least trustworthy of >those groupings, that is data from the additional data section, and >data from the authority section of a non-authoritative answer, should >not be cached in such a way that they would ever be returned as >answers to a received query. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode
Hello. First of all, I do hope you won't rely on how implementations do this (except aspects that are mandatory in standards-track RFCs). Note that even the delegation-revalidation draft in its current state plans just some SHOULDs and no hard obligations: https://tools.ietf.org/html/draft-ietf-dnsop-ns-revalidation On 11/17/20 1:09 AM, Doug Barton wrote: > If anyone from Nominet, or Knot, or other folks who referenced that > their software is also parent-centric have references, that would be > helpful as well. Knot Resolver developer here. I'm not aware of any references, but this list is archived so hopefully that's enough to post the approach we've been using so far. We get called parent-centric due to allowing queries to NSs based on parent-side NS RRs and address glue records - and not explicitly trying to refresh the child side of them. Nevertheless, *if* those child-side records do arrive in some answers (provided that they are in-bailiwick or DNSSEC-validable), they do get cached and used in preference for further iteration (rfc2181 ranking). --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] which breakage is this? FreeBSD.org / systemd-resolved
Hello. On 10/29/20 8:31 PM, Phil Pennock wrote: > the alternatives for a roaming laptop are even buggier (in the > resolver management, rather than in the actual resolver). Can you expand a bit on what you mean by this? I think people here are more likely to affect some of the alternatives rather than systemd-resolved. --Vladimir / Knot Resolver dev ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] which breakage is this? FreeBSD.org / systemd-resolved
On 10/30/20 5:29 AM, Paul Vixie wrote: > systemd is pretty configurable. there should be some way to turn this > DNS-like but not-actually-DNS listener off, and then either run a real > DNS listener (unbound, bind9, powerdns, knot, etc) there. Yes, systemd-resolved is an optional part of systemd, of course. It's up to each distribution to choose whether they use that part by default (some still don't) and perhaps even offer a simple way to switch. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] QTYPEs 65 and 65479
65 is the upcoming "HTTPS" RR, so perhaps testing future browser features or something. https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml (The other one is in "private use" range and I don't recognize it off the top of my head.) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] How widely implemented are different DNSSEC algorithms?
On 9/11/20 8:29 PM, John Levine wrote: > Are there any published numbers estimating how well the various DNSSEC > algorithms are supported in DNS caches and client software? Off the top of my head: https://dnsthought.nlnetlabs.nl/#ecdsa256 but 13 in particular feels quite deployed in zones - I know about .cz but I'm sure there are others. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] DNS Flag Day 2020 will become effective on 2020-10-01
On 9/11/20 9:14 PM, Randy Bush wrote: >> The main issue with having the discussion on github, is that it is a >> discussion on github, not on a major mailing list involving the >> operators and folks doing independent implementations. > for cabals which like a bubble, this is a feature, not a bug Are you telling me that Flag Day 2020 got too little publicity in here and similar circles? (its web, linked to GitHub, the plans, etc.) I rather thought we've pushed it everywhere often enough to make anyone sick of the topic, but perhaps my perception is biased. I'm really sorry if anyone feels excluded from the discussion. To be clear, we've had multiple "Flag Day 2020" threads just on this list. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS Flag Day 2020
Hello. On 2/8/20 8:33 AM, Viktor Dukhovni wrote: > Unfortunately, I don't see a way to separately configure the *upstream* > and *downstream* EDNS buffer sizes. It's been long but for Knot Resolver we now merged that split, so since the first post-flag-day release you can specify both values separately: net.bufsize(down, up) (equal if you only pass one number) https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1026 Separating IPv4 from IPv6 towards upstream would be complicated for us, as one packet can be re-transmitted over both transports (and even TCP), and so far I don't see that much motivation for it. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS Flag Day 2020 will become effective on 2020-10-01
On 9/9/20 10:39 AM, Petr Špaček wrote: > The reason is that the effective EDNS buffer size is the minimal value from > (client, server) pair. [...] Hopefully the auths deployed in practice (almost) always respect the upper bound sent by client. Unfortunately it's harder to test that against arbitrary zone/server, because you need some answer of the appropriate large size... --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Cloudflare public DNS sometimes forwards incomplete subset of NSEC RRs
On 9/1/20 9:58 AM, Stephane Bortzmeyer wrote: > AFAIK, Cloudflare uses Knot Resolver. I tested with another Knot > resolver and it works: I think they originally started the service quite close Knot Resolver code, but they've apparently diverged quite a bit since then (I don't know). To be sure, I had tested this report today and failed to get any problem with our current code. A related difference between 1.1.1.1 and Knot Resolver I now noticed: they don't seem to be doing aggressive NSEC caching, whereas Knot Resolver has it since January 2018 (it it could never be turned off on signed names). --Vladimir (Knot Resolver) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Cloudflare Rose and Rick in .com authoritative Nameserver
On 4/20/20 12:24 PM, Raffaele Sommese wrote: > So, why these records are in the .com authoritative server? Is it > optimization for Cloudflare? Let me add resolver point of view. As noted, these records are not required but are in bailiwick of .com, so it's reasonable to trust their value and speed up resolution that way. I believe there's nothing CloudFlare-specific in there. (For example, Knot Resolver trusts these by default.) --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] At least 3 CloudFlare DNS-hosted domains with oddball TLSA lookup ServFail
On 4/19/20 6:49 PM, Viktor Dukhovni wrote: >>> I believe that's normal for CloudFlare authoritatives, and so far I've >>> noticed no real problems from that, apart from effects like less >>> efficient caching. Description: >>> https://blog.cloudflare.com/black-lies/#dnsshotgun > It can't be "normal", because the auth servers ServFail when I request > the promised TLSA RRs. I only meant that those NSECs are normal (for them), not the ServFails or timeouts which they most likely have to debug themselves. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] At least 3 CloudFlare DNS-hosted domains with oddball TLSA lookup ServFail
(I don't react to the SERVFAIL from CloudFlare auth.) On 4/19/20 8:55 AM, Viktor Dukhovni wrote: > the NSEC RR promises TLSA records, among a rather oddball mix of > other rrtypes I believe that's normal for CloudFlare authoritatives, and so far I've noticed no real problems from that, apart from effects like less efficient caching. Description: https://blog.cloudflare.com/black-lies/#dnsshotgun At least they lie in the better direction - some servers actually deny types they do want served: https://github.com/dns-violations/dns-violations/blob/master/2018/DVE-2018-0003.md ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Cloudflare considered harmful?
On 4/16/20 10:04 PM, Viktor Dukhovni wrote: > Any chance you're also fixing the (likely DNAME-related) issue that's > breaking resolution of: "Right now" I'm finishing the support for DNAMEs in Knot Resolver at https://gitlab.labs.nic.cz/knot/knot-resolver/-/merge_requests/965 Perhaps Cloudflare could utilize that work, but the changes turned out relatively complicated and I don't know how far they've forked off, so I'm personally not keeping my hopes very high. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] question on query to DNS server's IPv6 interface
On 3/31/20 6:29 AM, Tessa Plum wrote: > When making a DNS query (giving the type is A) to an authorized > nameserver to its IPv6 address, will the value in answer are also IPv6 > addresses? If the host doesn't have an IPv6 address, how will DNS > server return? No, A always means IPv4 address. Even if you ask over whatever transport. is for the IPv6 equivalent. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Any DNAME usage experience?
On 3/31/20 6:47 AM, Brian Somers wrote: > One useful thing I could say (If you haven’t hit delete yet) is that I *HAVE* > seen RRSIGs with compressed signers in the wild, so never assume that, just > because RFCs say MUST NOT, you’ll never see these horrible things. Sure, validators MUST NOT crash on those, etc... but does that mean they SHOULD accept such signatures? I don't think so. (unless there's some additional motivation) --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Any DNAME usage experience?
Hello. On 3/29/20 1:23 PM, Meir Kraushar via dns-operations wrote: > If any compatibility issues, client side problems, resolvers etc?.. If the DNAME should reside in a signed zone, you may expect some resolver issues, though probably not too often (I'm unable to really estimate how much). I know about breakage of that case in Knot Resolver and Cloudflare's 1.1.1.1. Support in Knot Resolver has been on my todo list for a long time, and I'm quite sad we still don't provide it (though demand seems relatively low). https://gitlab.labs.nic.cz/knot/knot-resolver/issues/234 Cloudflare's service shares ancestry with us - perhaps they're more interesting for you, as I expect their "market share" is higher. (Estimates I've seen were on the order of 1% but I've only seen estimates for providers, not for implementations.) --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Algorithm but no signature in .in?
Hello. On 3/27/20 6:44 AM, Stephane Bortzmeyer wrote: > Some resolvers protest on .in. It seems they have a RSASHA256 key but > no RSASHA256 signatures, thus violating RFC 4035, section 2.2 "There > MUST be an RRSIG for each RRset using at least one DNSKEY of EACH > ALGORITHM". Note that in this case the mistake is on *both* sides, so it's an opportunity to also fix these validators. See > This requirement applies to servers, not validators. Validators SHOULD > accept any single valid path. https://tools.ietf.org/html/rfc6840#section-5.11 > (Cannot show a nice DNSviz picture, DNSviz seems broken at this time.) Seems to work for me at this moment, e.g.: https://dnsviz.net/d/registry.in/XnzgYw/dnssec/ (Thanks for this restored feature again!) --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS flag day 2020: The OpenDNS/Cisco perspective
Hello. On 2/26/20 11:51 PM, Brian Somers wrote: > - Servers (nameservers or resolvers) do their best to reply as asked > > The client wants the data and can decide on what risk the chosen > bufsize implies in their environment. Servers can apply practical > limits to bufsize to avoid large buffers or huge amplifications > etc. The client can limit the bufsize, but *if* something close to the client is obstructing fragments (say in ISP's network), I believe this DNS client typically isn't clever enough to "know/notice" and directly request smaller bufsize. The RFC recommended default 4096, so it's not surprising to often see that in practice. Here I think it will actually help the reliability if the server caps the bufsize under 1.5k even if its client signals that it can handle more. Incidentally, I think that never sending RRSIGs in answers considerably reduces the probability of fragmentation happening in real-life cases :-) --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNSViz Status?
Hello. For me personally, the old historical data isn't much interesting. What I'm missing most is the feature of sending a link to a recent measurement (and keeping the data for, say, a week at least). Thanks for the service anyway :-) --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] .ORG still using SHA-1 DNSKEYs
On 2/7/20 10:51 AM, James Stevens wrote: >> - You would be surprised how slow UDP packet processing in kernel can >> be ;-) > > Often UDP slowness is due to the fact that each packet requires a > context-switch from kernel to user-space, and back for the reply. > > So the bottleneck on a DNS server is generally how fast the CPU can > context switch, and this often had a hardwired limit. In that you can > top out the packet throughput with the CPU still showing %idle. > > I believe there is (or has been) a dev going on in the kernel to fix > this. > > I might be behind the curve, I've not looked into it for a bit. Actually the multi-packet API (sendmmsg + recvmmsg) did not help that much in our benchmarks (with Knot DNS and Knot Resolver), though it seems worth using. "Bypassing" the kernel's networking stack did help way more - incidentally Libor Peltan is presenting about that at tomorrow's OARC :-) --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] validation problem on 1.1.1.1
On 2/4/20 9:57 PM, Vicky Shrestha wrote: > We have identified the bug in a new version that was released to a > subset of colos. We have rolled out a fix. > > how does it look now from your vantage point? The problem got fixed from my vantage point. I had also re-checked against fresh Knot Resolver on Friday, just in case it could be related, but I wasn't able to reproduce the problem there. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Resolvers, DNSKEY queries and zone apex CNAMEs?
Hello, apex CNAME is inherently incompatible with forwarding, as I see the standards *now*. I wonder if such special-casing of some types like DNSKEY could solve (almost) all issues with CNAME at apex. (additional candidates off the top of my head: NS, SOA, DNAME?) I didn't think it through sufficiently at this moment, but there have been efforts to standardize CNAME at apex in some sensible way, and all of them have failed so far (with hope of getting addressed soon in other ways - currently HTTPSSVC). If this approach does not solve "sufficiently large" fraction of the issues (or does not eventually get standardized via dnsop), I'm afraid the additional complexity won't be worth it, along with encouraging apex CNAMEs. https://dnsflagday.net comes into mind. I'd hope that eventually we make apex CNAMEs either always work or always fail; this in-between state for commonly desired features is unhealthy. > Even if the CNAME enters an iterative resolver's data cache, the DNSKEY > should be served from in preference to any CNAME learned at some point > later, i.e. at a signed zone apex, the CNAME should be ignored when > responding to DNSKEY queries. Detail: if I did this, I would ignore any CNAME *regardless* of the existence of DNSKEY on the name (all conditioned by QTYPE == DNSKEY). Maybe that was your intention, I'm not sure. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] root? we don't need no stinkin' root!
On 11/26/19 9:58 PM, Tony Finch wrote: > Mirror zones (validated zone transfers) fall on the wrong side of the > cost/benefit equation for me. But I might change my mind if there were > better security for unauthenticated records (NS and glue) These are why we only implemented the mechanism over HTTPS for now (in addition to validating signatures). https://knot-resolver.readthedocs.io/en/stable/modules.html#cache-prefilling Still, I believe that a small resolver instance only needs a few DNS queries to root (per TTL), so switching everyone to always transferring the whole root should increase the total traffic considerably, and HTTPS and XoT are probably more expensive than DNS-over-UDP given the same traffic amount. That's where the aggressive-cache-only approach seems nice, but (additionally) having full root would also avoid leaking any of those garbage queries. (Except for those that hit an existing TLD, but those can't be helped at the root level, and TLDs are generally too big+dynamic for mirroring.) --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS over TCP query uptick with iOS 13?
On 10/9/19 8:53 AM, Xavier Beaudouin wrote: I saw that DNS over TLS (not TCP) eg port 853/TCP is more and more used. I expect that's due to newer Androids getting to more people? (i.e. it seems unrelated to OP) https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
