[DNSOP]DNS-OARC 43 - moved to Prague, CZ - 2024 October 26-27
DNS-OARC 43 Workshop has moved to Europe. New location: Prague, Czech republic New date: 2024 October 26-27 (before RIPE 89) Details: https://www.dns-oarc.net/oarc43 Call for presentations is open until 2024-07-23 23:59 UTC You can also look forward to DNS Community day which will happen in the original location and date. See https://indico.dns-oarc.net/e/SMR2024 for more details. -- Petr Špaček, for the DNS-OARC Programme Committee ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: draft-ietf-dnsop-avoid-fragmentation-17.txt - implementer notes
On 07. 05. 24 2:54, C. M. Heard wrote: On Mon, May 6, 2024 at 6:59 AM Petr Špaček wrote: Warren asked implementers to provide feedback on the current text, so I'm doing just that. [ ... ] 3.1. Recommendations for UDP responders R1. UDP responders SHOULD NOT use IPv6 fragmentation [RFC8200]. Operational impact of this recommendation is unclear. Why? Because clients belong to several sets: - One set clients cannot receive fragmented answers, - another set of clients cannot use TCP to overcome unfragmented UDP size limitations, - yet another set of clients actually depend on large answers to function (say because they DNSSEC validate, or need to follow huge NS sets generated by MS AD, or they need large RRs to deliver e-mail, or ...). It's unclear what proportion of clients belong to intersection of these three sets. Banning fragmentation on the **outgoing** side might break these clients, and it's extremely hard to measure and debug from the server side. This complaint is really unclear. The recommendation is specifically for responders, i.e., servers. It's not a priori whether the term "outgoing" means the requestor to responder direction or the responder to requestor direction. I presume the latter, but it would be better if this was made obvious by using the same terminology as the draft. What I think you are saying is that clients that cannot re-send truncated queries using TCP will be hurt by the recommendation. Aren't such clients non-conformant with current DNS standards? If so, are they sufficiently prevalent that it is necessary to continue using workarounds to accommodate them? I said: "Operational impact of this recommendation is unclear." That means that answer to your question is unknown. This recommendation is not backed with data. If the data exist they are not linked. To the best of my knowledge there is no significant operational experience with it. If the experience exists I have not seen it published. On paper the recommendation does not sound bad. Maybe it's good enough as aspirational, forward-looking recommendation... But that's not what the document does. Version 17 currently says it's: - Best - Current - Practice As I implementer I claim these three words are either not supported by data or outright incorrect: - Best - impact is unknown, experience is lacking - Current - not deployed at scale - Practice - well, not even implementable with current OS APIs! > Wasn't the whole point of DNS Flag Day to break what was broken and get it fixed? There was not a flag day for TCP support (yet?). If you are up for organizing one I'm happy to share first-hand experience from organizing previous two DNS Flag Days! [ ... ] R6. UDP requestors SHOULD drop fragmented DNS/UDP responses without IP reassembly to avoid cache poisoning attacks. AFAIK this is impossible to do using normal socket API. The application has no access to information about UDP reassembly. Having said that, even if it was implementable it's IMHO not the best advice for requestor. IF the requestor is able to detect that a fragment was received then it would be MUCH better to trigger retry using different protocol right away. Just dropping the packet: a] causes timeouts b] leaves a time window open for another attack attempt I wondered about this after I read the draft (which was after WG last call, or I would have commented). I'm not aware of any stack that allows the application to disable IP reassembly, nor any that indicates whether a received UDP datagram was received in a single IP datagram or in multiple IP fragments. If that is indeed the case, this recommendation should be removed, since it is not actionable. Additionally, my understanding of the motivation for this is to prevent off-path cache poisoning attacks. If I correctly understand what I have read, these are a problem for IPv4 (which has only a 16-bit datagram ID) or for IPv6 stacks that emit predictable datagram IDs. It seems to me that the advice to avoid reassembly would need to be more nuanced, even if it were actionable. Generally I agree. Having said that, paradoxically I think R6 advice is much better than R1... **if** it were practically implementable. Again, this can be aspirational forward-looking recommendation. If we can get API to detect fragmented (even partial) datagrams we can harden the client side and most of other recommendations will be moot. Example: The requestor could treat any fragmented answer as equivalent to TC=1 answer with no data inside. That should take care of all known fragmentation-based attacks (I think) and it does not depend on responder side at all. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] draft-ietf-dnsop-avoid-fragmentation-17.txt - implementer notes
rrent text with: DNS responses may be dropped by IP fragmentation. Requestors are RECOMMENDED to try alternative transport protocols eventually. (Heh, and now someone need to rewrite this into a proper English.) Hope it helps. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] OARC 43 - Call for Contribution
The Programme Committee is seeking contributions from the community. This workshop will be a hybrid event. Date - likely in the week of 23-27 September 2024, details will be confirmed later Location - South America, exact location will be confirmed later Time zone - approximately 09:00-17:00 UTC-5 Co-located with - related industry events, will be confirmed later Deadline for Submissions - 2024-06-23 23:59 UTC For further details please see https://indico.dns-oarc.net/event/51/abstracts/ Petr Špaček, for the DNS-OARC Programme Committee ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-qdcount-is-one
On 19. 03. 24 7:15, Joe Abley wrote: Hi Chris, Thanks for the review! On 19 Mar 2024, at 03:28, Chris Box wrote: It is a little cart-before-horse in having the reasoning occur after the conclusion. But I can see the benefit in having a very clear statement up front in the document. Some people only read the beginning. The document was changed to be like this because the working group found the survey of current standards to be a bit of a distraction from the advice. The purpose is after all to clarify the standards, not to enjoy a voyage through them. I have one suggestion for improvement, which you can modify or ignore as you wish. Some people only read the title, particularly if they see it as part of a citation. And if that's all you see, it's not a clear message at all. "In the DNS, QDCOUNT is (usually) One" tells me nothing I don't already know. Yes it is usually one. However if you were to change the title to something like "In DNS queries, QDCOUNT must be <= 1" then I learn all I need to know from simply the title. To me, this is a win. Personally I think we do need people to read a little bit beyond the title if they are going to extract useful meaning from the document. If we accept that to be a reasonable goal then perhaps having a title that seems slightly intriguing is better than a title that is 100% spoiler. IMHO intriguing != incorrect. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] About key tags
On 16. 02. 24 15:51, Shumon Huque wrote: On Thu, Feb 15, 2024 at 4:37 AM Petr Špaček <mailto:pspa...@isc.org>> wrote: On 14. 02. 24 16:45, Shumon Huque wrote: > > What colliding keytag limits are other resolver implementers placing? Right now BIND tolerates 1 validation failure before hard-failing. This counter is not limited to colliding key tags. You didn't quite answer my specific question - does BIND now have a limit on keytag collisions, and if so, what is it? It does not handle collisions in any special way. It simply does not validate and the resolver has no way to tell if the crypto thingy is wrong or if it just tried a wrong key. Any such failure is counted towards fail-budget (1 allowed). For your more general answer, I want to make sure I clearly understand what you are saying. Does "hard-failing" mean blacklisting only the authoritative server that gave the bad response that caused any validation failure, and re-trying other available servers for the zone (to some limit)? Hard-failure is probably a wrong term, sorry about that. Reaching either limit stops the current validation attempt and treats that specific answer as bogus. All the rest (retries, caching and whatnot) is the same as it was. Resolvers need to have robust re-try behavior in the face of attacks (or misconfigurations, or unavailability). This all of course has to be balanced with the requirement to bound the amount of work (but as I pointed out in my earlier email, this was known in 1987, though implementers seem to have forgotten that fundamental principle sometimes). Oh yes, and that advice is forgotten about way more often than in this single case. See (definitely incomplete) list here: https://www.isc.org/blogs/2024-bind-security-release/ Based on the list above I claim that statement "KeyTrap vulnerabilities are fundamental" is either nonsense OR we have to declare all the other vulnerabilities "fundamental" as well ... -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] work limits - RFC 5155 section 8.3 (NSEC3 closest encloser proof)
Hi again, this thread is NOT related to KeyTrap CVE. This thread focuses on CVE-2023-50868 "NSEC3 closest encloser proof can exhaust CPU" and lack of caveat about work limits in RFC 5155 section 8.3. Please note this attack is not described in the KeyTrap technical paper linked in the other thread (because it was discovered by a different team). Observation === BCP in RFC 9276 says that we should use sensible limit for NSEC3 iterations. Most implementations at the time went with 150. What the RFC does not mention is that NSEC3 closest encloser proof algorithm multiplies that number of iterations by **number of labels** it needs to try, so for most attack-purposes the effective value is: (125 labels) * (NSEC3 RR iterations value - usually capped at 150) Hardware limits === To put things in perspective, try this command: $ openssl speed sha1 On hardware I have it shows ~ between 9 - 4 _million_ operations per second for block size between 16 and 256 bytes. That's a lot! ... or not so much. Say we go with the middle value: 6 500 000 / 150 iterations as common limit / 125 labels = 346 closest encloser proofs per second **Now** divide by number of NSEC3 RRs in the answer you are trying to validate as well! Let's start with 3: 346 / 3 = 115 QPS If we consider also answers which contain CNAME into another zone hosted on the same server we are at half of this value. Of course the resulting QPS is _upper bound_ because it does not allow of RRSIG validation and any other overhead in the resolver. Impact == Depending hardware and NSEC3 iterations limits in place, attacker can exhaust CPUs with QPS somewhere in order of small hundreds. The Question What work limits you consider sensible for RFC 5155? Feel free to propose your own variables to be used, and don't forget to include back-of-envelope example to support your proposal (using say 6 500 000 SHA1 operations per CPU/second as a base). -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] work limits - RFC 4035 section 5.3.3
Hello, let me start a new thread because the "About key tags" is getting out of hand. Intro = The so-called KeyTrap CVE has technical report available here: https://www.athene-center.de/fileadmin/content/PDF/Keytrap_2401.pdf TL;DR is: RFC 4035 section 5.3.3. Checking the Signature has a MUST loop doing crypto operations over product of #DNSKEY * #RRSIG set (for matching key tags), and this can be damn expensive. Of course we should have listened to RFC 1034 page 35 "limit amount of work" advice ... Hardware limits === To put things in perspective, try this command: $ openssl speed ecdsap384 On hardware I have it shows ~ 2000 verify operations per second. This defines an upper bound on number of combinations a resolver can try per second (and completely waste its CPU budget while doing so). BIND's approach at the moment = BIND versions released on 2024-02-13 use limit of 16 (successful) validations per message and limit of 1 allowed validation failure per message, with no special handling for keytag collisions. I.e. colliding key will cause validation failure which counts towards fail-budget. This has already caused breakage on half-broken domain paste.debian.org which had half signatures broken & uses 3-step CNAME chain, but does not use colliding key tags. Even these relatively strict limits allow the attacker to eat 1 whole CPU by doing ~ 2000 / 16 = 125 QPS causing cache misses To mitigate this BIND also offloads (depending on version) either validation work or all of cache miss handling into separate threads. Sensible thread scheduler in the OS should split the available capacity among validating & non-validating threads. In our tests it indeed allows an attacker doing PRSD against a signed zone to cause cache hit QPS to drop to 1/2 of the pre-attack QPS, but not significantly less than that. The Question What work limits on RFC 4035 sec. 5.3.3 on you consider sensible? Feel free to propose your own variables to be used, and don't forget ot include back-of-envelope example to support your proposal (using say 2000 validations per CPU/second as a base). -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] About key tags
On 16. 02. 24 16:19, Joe Abley wrote: Hi Jim, On 16 Feb 2024, at 14:50, Jim Reid wrote: The latest patches to mitigate the keytrap vulnerability are welcome and much appreciated. Though IMO they’re a short-term fix. A long-term solution would be implementation guidelines as outlined above or to hard-fail validation whenever there’s a key tag collision. I'm not sure why this is true. Resolvers are routinely managed in order to safeguard local resources, harden themselves against attacks, etc. Not every query gets answered. Seems to me that limiting the time a validating resolver spends churning its organs over a particular RRSIG and causing it to fail to validate if the indigestion gets too bad is just another example of sensible local policy. While I think some centralised guidance about how to harden your resolver against this attack (or any attack) is useful (and similarly guidance to avoid duplicate key tags seems like a great idea for signers) I am struggling to see any of this as a problem with the protocol or a fundamental weakness in DNSSEC that needs a "long-term solution". If a zone's signatures and keys are constructed and published in such a way that it causes indigestion in validators, and as a consequence validators fail to return responses for data in that zone, that's a self-inflicted problem and the zone administrator surely has every incentive to fix the problem. If the tools the zone administrator is using make the problem hard to make, then so much the better. The DNS is filled with misconfigurations and junk. Things get fixed if they need to when things break. Sometimes things break in painful ways and so we make changes to mitigate or avoid the pain. How is this not just another day on the Internet? I think you describe it accurately, but people who implement resolvers in this thread (me, Ralf, Brian W.) apparently disagree where the pain should land - should resolvers suffer from more complex code & work, or should signers suffer if they do something very unusual? -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] About key tags
On 14. 02. 24 15:49, Shumon Huque wrote: On Wed, Feb 14, 2024 at 8:54 AM Petr Špaček <mailto:pspa...@isc.org>> wrote: On 14. 02. 24 14:37, Joe Abley wrote: > Op 14 feb 2024 om 13:46 heeft Edward Lewis mailto:edward.le...@icann.org>> het volgende geschreven: > >> On 2/14/24, 04:40, "DNSOP on behalf of Petr Špaček" mailto:dnsop-boun...@ietf.org> on behalf of pspa...@isc.org <mailto:pspa...@isc.org>> wrote: >> >>> In my mind this is good enough reason to outlaw keytag collisions - >>> without them it would be _much_ easier to implement reasonable limits >>> without risk of breaking legitimate clients. >> >> That would make key tags meaningful. ;--) >> >> The question is how, in a multi-signer friendly way. > > To be honest it feels like there as many opportunities for accidents by imposing restrictions on publishing duplicate keytags as there are by consuming them. Your text summarised a few of them quite nicely, Ed, without even considering the new opportunities for failure due to the interplay between systems following any new rules that might be imposed and those that don't. > > Is the triggering incident not just another cautionary note that we learn from? > > Why is this particular incident a sign that we need to change the protocol when so many others have not been? > > These seem like questions that deserve convincing answers before jumping ahead to how a new restriction might be structured. Let me turn the question around: How many keytag collisions are you willing to allow & at the same time protect validators from 2023-50387? Does the KeyTrap vulnerability exploit colliding keytags? The paper isn't public yet and the CVE does not mention this. Obviously, resolvers need to sensibly bound the work they are willing to do to resolve queries, especially so in the face of misconfigurations (or malicious configurations). And that basic principle should apply to keytag collisions too. In fact, bounding work is the documented top priority of a resolver from RFC 1034 (published 1987). "The recommended priorities for the resolver designer are: 1. Bound the amount of work (packets sent, parallel processes started) so that a request can't get into an infinite loop or start off a chain reaction of requests or queries with other implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED SOME DATA. ..." (My usual addendum to this paragraph is that the resolver should also bound the time spent too). Oh yes, this is basically what https://www.isc.org/blogs/2024-bind-security-release/ tries to explain at length. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] About key tags
On 14. 02. 24 16:45, Shumon Huque wrote: On Wed, Feb 14, 2024 at 7:46 AM Edward Lewis <mailto:edward.le...@icann.org>> wrote: On 2/14/24, 04:40, "DNSOP on behalf of Petr Špaček" mailto:dnsop-boun...@ietf.org> on behalf of pspa...@isc.org <mailto:pspa...@isc.org>> wrote: > In my mind this is good enough reason to outlaw keytag collisions - > without them it would be _much_ easier to implement reasonable limits > without risk of breaking legitimate clients. That would make key tags meaningful. ;--) The question is how, in a multi-signer friendly way. Yes, enforcing non-colliding keytags in a multi-signer configuration is more challenging, since coordination across multiple independent parties may be needed. But a process could be developed to deal with that. But I'm not sure how worried I am about it, as a practical matter. Even if by some remarkable coincidence all keys collided in a 2 party KSK+ZSK multi-signer configuration, Unbound with its 4-keytag limit would still be able to deal with it.( I guess some additional room for pre-published rollover keys may be needed if they also collided). What colliding keytag limits are other resolver implementers placing? Right now BIND tolerates 1 validation failure before hard-failing. This counter is not limited to colliding key tags. In generic terms, the amount of work scales like: #DNSKEYs * #RRSIGs (for matching key tags) Ed's example in the other thread with 1 DNSKEY and 10 bad RRSIGs is certainly a problem - thus the limit on number of validation failures. The high-level trouble is that (currently legally) colliding keys make it hard to find a nice threshold which does not break legal setups and at the same time prevents resolvers from doing excessive work. Of course even with perfectly valid RRSIGs and just one key the amount of work can be large - CNAME chains etc. etc. For that reason we currently also limit number of validations to 16 per fetch. And that leaves us more or less with basic random subdomain attack, so we are back where we started :-) If you think colliding keys should be allowed, please propose your own limits for sensible behavior. I will take popcorn and watch. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] About key tags
On 14. 02. 24 14:37, Joe Abley wrote: Op 14 feb 2024 om 13:46 heeft Edward Lewis het volgende geschreven: On 2/14/24, 04:40, "DNSOP on behalf of Petr Špaček" wrote: In my mind this is good enough reason to outlaw keytag collisions - without them it would be _much_ easier to implement reasonable limits without risk of breaking legitimate clients. That would make key tags meaningful. ;--) The question is how, in a multi-signer friendly way. To be honest it feels like there as many opportunities for accidents by imposing restrictions on publishing duplicate keytags as there are by consuming them. Your text summarised a few of them quite nicely, Ed, without even considering the new opportunities for failure due to the interplay between systems following any new rules that might be imposed and those that don't. Is the triggering incident not just another cautionary note that we learn from? Why is this particular incident a sign that we need to change the protocol when so many others have not been? These seem like questions that deserve convincing answers before jumping ahead to how a new restriction might be structured. Let me turn the question around: How many keytag collisions are you willing to allow & at the same time protect validators from 2023-50387? -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] About key tags
On 14. 02. 24 2:57, Mark Andrews wrote: On 13 Feb 2024, at 00:56, Edward Lewis wrote: On 2/9/24, 22:05, "Mark Andrews" wrote: The primary use of the key tag is to select the correct key to validate the signature from multiple keys. Yes - which is great if 1) you need to pare down the potential set of keys into something you can handle (like, from 10's to 3) and 2) if you have somewhat to request only those keys. Operators generally only publish 2 keys outside of rolls, 3 when rolling the ZSK or the KSK, maybe more if they aren't optimizing. There's no need to specify a subset. I say this with complete highsight. I would still argue that there is still a need even if there is only 2 keys. Verification is expensive. It always has been. I think CVE-2023-50387 listed on https://www.nlnetlabs.nl/projects/unbound/security-advisories/ is nice demonstration how dangerous it can be when resolver has to implement try-and-see approach. In my mind this is good enough reason to outlaw keytag collisions - without them it would be _much_ easier to implement reasonable limits without risk of breaking legitimate clients. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] starting in 3 minutes - dnsop WG Virtual Meeting: 2024-01-30
Dear WG, this is a reminder that the virtual meeting is about to start in 3 minutes! The agenda URL will guide you to document with links for Meetecho etc. Petr Špaček On 24. 01. 24 21:54, Benno Overeinder wrote: Dear WG, We have published an updated agenda for the interim, see https://datatracker.ietf.org/doc/agenda-interim-2024-dnsop-01-dnsop-01/ ## Agenda ### Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ### New Business * Presentation on state of DELEG draft - https://datatracker.ietf.org/doc/draft-dnsop-deleg/ - 15 minutes * Legacy resolver compliance testing results - 5 minutes * Open discussion points in the draft - 10 minutes * Initial reflections on DELEG - Paul Wouters - 15 minutes * Open discussion: discussion and reflection on interim - 10 minutes * IETF Process Time - BoF? New WG? Another hour needed at next IETF On 19/01/2024 18:13, IESG Secretary wrote: The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam (17:00 to 18:00 UTC). Agenda: # DNS Operations (DNSOP) Working Group ## interim-2024-dnsop-01 ### Chairs * Benno Overeinder [be...@nlnetlabs.nl](be...@nlnetlabs.nl) * Suzanne Woolf [suzworldw...@gmail.com](suzworldw...@gmail.com) * Tim Wicinski [tjw.i...@gmail.com](tjw.i...@gmail.com) ### IESG Overlord * Warren Kumari [war...@kumari.net](war...@kumari.net) ### Document Status * [Github](https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-document-status.md) * [Datatracker](https://datatracker.ietf.org/wg/dnsop/documents/) * [Propose Slides](https://datatracker.ietf.org/meeting/interim-2024-dnsop-01/session/dnsop) ## Session interim-2024-dnsop-01 * Date: 30 January 2024 * Time: 17:00-18:00 UTC * [MeetEcho](https://meetings.conf.meetecho.com/interim/?group=3d47363c-d68e-46b7-aedf-094716d4d64f) * [Jabber](dn...@jabber.ietf.org) * [Zulip](https://zulip.ietf.org/#narrow/stream/dnsop) * [Minutes](https://notes.ietf.org/notes-ietf-interim-2024-dnsop-01-dnsop) ## Agenda ### Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ### New Business * Presentation on state of DELEG draft. - 15 minutes * Legacy resolver compliance testing results. - 5 minutes * Open discussion points in the draft: - 10 minutes * Open Discussiontime for discussions - 20 minutes * IETF Process Time * BoF? New WG ? Another Hour Needed at next IETF Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=3d47363c-d68e-46b7-aedf-094716d4d64f -- A calendar subscription for all dnsop meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-qdcount-is-one-01
On 17. 01. 24 21:42, Matt Brown via Datatracker wrote: The proposal has been discussed in the dnsop group and previous meetings and my observation of the discussion is that there is both broad agreement that QDCOUNT > 1 is not used in practice and at least some supporting evidence presented that it is not observed in the wild either. I can attest that it _is_ seen in the wild every day in several customer's networks, but only in form of garbage queries and/or answers. To the best of my knowledge nothing depends on it. I wholeheartedly support the draft. The only piece missing to make it *perfect* is "MUST use QDCOUNT=1", or in other words, banning QDCOUNT=0 usage with DNS COOKIES. It's unnecessary complexity. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Resolver behaviour in the presence of unrequested answer records
On 11. 01. 24 18:34, Bellebaum, Thomas wrote: Hello, We have been looking at some DNS resolvers and encountered a question: When a DNS response contains (in the answer section) records which were not requested, how should the resolver react to those and what should it return to the requesting client? For example: QUESTION: example.com IN A ANSWER: example.com IN CNAME www.example.com www.example.com IN A 3600 1.2.3.4 google.comIN A 3600 5.6.7.8 Tangentially related is very recent (two weeks old!) experiment which looked at handling unsolicited RRs in the AUTHORITY section. See https://chat.dns-oarc.net/community/pl/iyw9znj4wbgdfbbwwz1jjezt6o and the discussion following it. In case you don't have DNS-OARC chat login yet see https://www.dns-oarc.net/oarc/services/chat HTH. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Followup One Week Working Group Last Call for draft-ietf-dnsop-avoid-fragmentation
On 29. 09. 23 9:15, Peter van Dijk wrote: On Tue, 2023-09-19 at 14:27 -0400, Tim Wicinski wrote: In the case of the DF bit, the wording is changed from "UDP responders are RECOMMENDED" to "UDP responders MAY" With this change, the document appears to in fact document Best Current Practice. The added note in the Security Considerations about DF makes sense to me - we will have to see if anybody is willing to do the DF experiment for real, of course. I agree. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] IETF 118 hackaton: Does Not Scale: Rethinking DNS
Hello all! I would like to invite you to a "round table" planned during IETF 118 hackathon [1] - Saturday and Sunday before IETF 118. We plan to have an open and friendly brainstorming session with people who work on the DNS protocol, write implementations, and operate networks. The purpose is to brainstorm and think about DNS without being bound by current protocol constraints. Where are we hitting limits? What can we do about them? Do you want to put your protocol pet peeve out of its misery? If you want to join, please list yourself here: https://doodle.com/meeting/participate/id/azXrrv7d. This will allow us to secure a large enough workspace. Participants are expected to come with their homework done. Bring a list of limitations you can see in the current protocol with you, and don't hesitate to think big. Hate the duplicate TTLs in DNS messages? Please write it down. Want secure & flexible transport protocol specification? Never liked the compression method? Put it on the list. As a teaser, here are a couple of real-world motivating questions just to get us started. How do we make DNS: ... scalable so it can transfer millions of zones? And how do we monitor it? [2] ... handle humongous post-quantum crypto keys and signatures, in both protocol and transport? [3] ... support distributed multi-master setups? ... extensible to new wire format & at the same time, maintain a single namespace? ... simpler to operate? What if we rethink basic assumptions? [4] (see the talk starting at 33:40) [1] https://wiki.ietf.org/en/meeting/118/hackathon [2] https://indico.dns-oarc.net/event/47/contributions/1017/ [3] https://indico.dns-oarc.net/event/46/contributions/985/ [4] https://icann.zoom.us/rec/share/PUZu_QsO_rdY0gavMatzFOSVpZY1oNahNYnPBuy6pgTUJARw-YIOEzWEV11aqaHW.4Cwr3dGRlunUwhD9?startTime=1693897245000 It's unlikely we will produce running code, but hopefully we'll generate some good ideas and possibly proto-I-Ds. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Publication has been requested for draft-ietf-dnsop-avoid-fragmentation-14
On 18. 08. 23 17:33, Peter van Dijk wrote: Hello Tim, On Wed, 2023-08-16 at 15:45 -0700, Tim Wicinski via Datatracker wrote: Tim Wicinski has requested publication of draft-ietf-dnsop-avoid-fragmentation-14 as Best Current Practice on behalf of the DNSOP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ In https://mailarchive.ietf.org/arch/msg/dnsop/lrPbp6B8Mkz2S7HBXlxSPoIhTOw/ I pointed out that zero of the implementers honour item 2 in section 3.1. In https://mailarchive.ietf.org/arch/msg/dnsop/QOxTZHG03UVLom9E-y6iYG5s6po/ you said "good point, we need to address this". After that I have seen no communication on the list about addressing this, so I'm very surprised to see this publication request. FTR I agree that this document does not describe Best _Current_ Practice, and to underline the point I add that > D.1. BIND 9 > BIND 9 does implement recommendation 2 of Section 3.2. ... does not seem to be correct. None of the values is used, and none of the MAY methods is employed by BIND (in current versions). -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)
On 23. 05. 23 7:03, Ralf Weber wrote: Moin! On 23 May 2023, at 4:44, Tommy Pauly wrote: Thanks, Mark. For what it's worth, I just ran two other tests, and for both of these cases, all of the resolvers I tried did accept the request: - Choose a new EDNS option code point (I just tested 50, randomly) - Use EDE but set the length to 2 and the error to 0 (other error), rather than a length of 0 I don’t think we need a new code point. Just having a valid opt record without a further option will work as RFC8914 states: The Extended DNS Error (EDE) option can be included in any response (SERVFAIL, NXDOMAIN, REFUSED, even NOERROR, etc.) to a query that includes an OPT pseudo-RR [RFC6891]. This document includes a set of initial codepoints but is extensible via the IANA registry defined and created in Section 5.2. and as the mechanism in draft-ietf-dnsop-structured-dns-error just defines a special format for the EDE EXTRA-TEXT field the most backward compatible solution IMHO is just to rely on the mechanism defined in RFC8914, and not to define any special handling. So I would propose 5.1 to be: When generating a DNS query, the client includes the OPT pseudo-RR [RFC6891] to elicit the Extended DNS Error option in the DNS response. I agree. Sending empty EDE in requests seems superfluous to me. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPRFC 8914 EDE code for filtered rrtype
On 21. 03. 23 18:05, Wes Hardaker wrote: Petr Menšík writes: I have made a proposal to mark all filtered out queries with EDE code Filtered (17). However codes 15-18 all describe themselves as per-domain rules. I agree that none of these look appropriate based on re-reading the text. I actually think your desire to filter by qtypes is not anywhere in the purpose of the original list. Thus... you need to write a draft with a new EDE code allocated I think. In fact full-blown draft is not needed. The EDE registry policy is FCFS so you can have it with mere link to "something", see e.g. code 25 here. https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#extended-dns-error-codes -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnssd] Solicit feedback for the DNS behavior for workloads hosted in Cloud DCs described in draft-ietf-rtgwg-net2cloud-problem-statement
On 25. 01. 23 20:17, Michael Richardson wrote: I strongly agree with you recommendation: Globally unique names do not equate to globally resolvable names or even global names that resolve the same way from every perspective. Globally unique names can prevent any possibility of collisions at present or in the future, and they make DNSSEC trust manageable. Consider using a registered and fully qualified domain name (FQDN) from global DNS as the root for enterprise and other internal namespaces. Oh yes please. I 100% support this. FTR the DNS protocol folks, myself included, were saying this for a long time. Advice like this can also be seen in even in enterprise-oriented docs, e.g. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/ch-configure_host_names#sec-Recommended_Naming_Practices (That's from ~ 2015, so also not brand new.) If you can make somehow amplify this advice I might end up owing you lots and lots of beverages :-) -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation
On 14. 09. 22 16:56, Kazunori Fujiwara wrote: From: Petr Špaček On 15. 08. 22 12:18, Kazunori Fujiwara wrote: I assume section 3.2 means the EDNS bufsize in the request when it says "their payload size", but I am not sure. The text could be clearer on that. * UDP requestors MAY probe to discover the real MTU value per destination. How? For example, recent BIND 9 starts small EDNS requestors maxiumum DNS/UDP payload size (512), and increases gradually. Correction: Recent BIND starts with EDNS buffer size 1232 bytes, and it does not rise the value to "probe" the destination address by to "probe". FTR I'm testing on 9.19.5-dev commit b13d973, but I believe it is like that for a long time already. THanks very much. commit bb990030d344dafe40a62fe5ed2741de28b8ca66 removed the probing heuristics. BIND 9.17.6 and later 5516. [func] The default EDNS buffer size has been changed from 4096 to 1232 bytes, the EDNS buffer size probing has been removed, and named now sets the DF (Don't Fragment) flag on outgoing UDP packets. [GL #2183] I think the draft as it is currently does not have enough information for implementers to be followed in safe way. I'm against publication as it is. There should be running code, experiments, and measurements to back up data in this draft. I can't see them at the moment. Then, do you agree the following requirements ? (as DNS software developpers) 1. SHOULD set DF bit on outgoing UDP packets on IPv4, and SHOULD not use FRAGMENT header on IPv6. Theoretically yes, but it might not be achievable depending on OS API. We tried many iterations in BIND, and discovered that APIs (at least in Linux) are horrible and there are traps everywhere. Here we _also_ need to protect against "old" PMTU discovery attacks with spoofed ICMP messages which cause fragmentation on the source host (as opposed to fragmentation along the path), which are potentially more dangerous because an off-path attacker can mount them more easily. For reasons I cannot remember now BIND currently uses socket option IP_PMTUDISC_OMIT defined in tools/include/uapi/linux/in.h as 132 #define IP_PMTUDISC_PROBE 3 /* Ignore dst pmtu */ 133 /* Always use interface mtu (ignores dst pmtu) but don't set DF flag. 134 * Also incoming ICMP frag_needed notifications will be ignored on 135 * this socket to prevent accepting spoofed ones. 136 */ 137 #define IP_PMTUDISC_INTERFACE 4 138 /* weaker version of IP_PMTUDISC_INTERFACE, which allows packets to get 139 * fragmented if they exeed the interface mtu 140 */ 141 #define IP_PMTUDISC_OMIT5 I _think_, and I might be easily wrong, that this was done to eliminate impact of spoofed "path MTU exceeded" ICMP messages. Personally I got lost several times when attempting to understand history of this, so I hesitate to formulate an universal advice or even say how we ended up here. 2. limit DNS payload size 1232 without path MTU discovery. (After DNSFlagDay2020, many implementations use 1232) As Paul wrote down thread, it is random number - and so far it works for us. 3. If path MTU discovery works, UDP responders can send larger (>1232) responses fit in the path MTU. Possibly, but I think it is kind of moot advice without knowing how it can be done. Right now there is no such thing as RFC 8899-equivalent for DNS, so we don't even know if it would work for DNS as we know it. Quick glance at RFC 8899 section 3 is not encouraging in that regard, e.g. point 3, as a single example, shows that 8899 does not match the current state of DNS (because auth does not get answer from a resolver if the large response got through or not). 4. TCP implementations SHOULD set DF bit / not use FRAGMENT header. (many TCP implementations already set DF bit) I doubt we have control over this from the application. Is there even API to control that on TCP sockets? # If there is a link whose MTU is smaller than 1260 (on IPv4), # the link may be a blackhole. Definitely. If the default is "too wrong" the whole thing falls apart. I'm sorry for not being more informative. The only I know for certain is that we had multiple iterations in BIND, are not happy with any of them, and and it is order of magnitude more complex than we thought. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Representing DNS Messages in JSON (RFC 8427): ugly EDNS
On 14. 09. 22 16:02, Viktor Dukhovni wrote: On Wed, Sep 14, 2022 at 10:42:26AM +0200, libor.peltan wrote: Dne 13. 09. 22 v 18:21 Viktor Dukhovni napsal(a): The "OPT-RR" is message metadata, and so should not be confused with other sorts of additional records. (TSIG would also fall into that bucket). Thank you for this point. So we should invent a way how to convert OPT record into properties of the JSON-represented message structure. That could be useful. Someone would have to invest the energy to push this forward. Do you have the cycles? I should also note that in terms of presentation forms, the SVCB record is particularly challenging, since it also sports extensible options of arbitrary types, and requires both a generic presentation form (for not known options) and a type-specific form for known options. It seems that SVCB will be standardized soon, which makes me think that we may inspire ourselves. Well, there is presently no specification of a JSON representation of SVCB records. The wire forms in combination with the presentation names of the options generally suggest somewhat natural encodings, but the larger picture is IMHO somewhat murky. The RRtype in question has elements of an "open" type (new field schemata can be added as we go along). We specify wire forms and (zone file) presentation forms, but neither is sufficient for an interoperable and natural JSON form. Just capturing the presentation form is unappealing, since it represents lists and other structured elements poorly. It might be possible to invent a presentation format for EDNS (despite it does not appear in zonefiles, it should be still useful for other purposes), which would use the same tricks as SVCB presentation format. What do you think? Sure, but is there enough "energy" (enthusiasm) to do this? I agree that full structured JSON is lots of work, and honestly I don't see the need for it. From my perspective more useful is to standardize unambiguous presentation formats for all EDNS options first. Maybe we will find out that it is enough. Or maybe not, but the presentation formats could be a corner stone, and are useful by itself. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation
On 15. 08. 22 12:18, Kazunori Fujiwara wrote: I assume section 3.2 means the EDNS bufsize in the request when it says "their payload size", but I am not sure. The text could be clearer on that. * UDP requestors MAY probe to discover the real MTU value per destination. How? For example, recent BIND 9 starts small EDNS requestors maxiumum DNS/UDP payload size (512), and increases gradually. Correction: Recent BIND starts with EDNS buffer size 1232 bytes, and it does not rise the value to "probe" the destination address by to "probe". FTR I'm testing on 9.19.5-dev commit b13d973, but I believe it is like that for a long time already. I think the draft as it is currently does not have enough information for implementers to be followed in safe way. I'm against publication as it is. There should be running code, experiments, and measurements to back up data in this draft. I can't see them at the moment. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-03.txt
On 07. 09. 22 3:28, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Delegation Revalidation by DNS Resolvers Authors : Shumon Huque Paul Vixie Ralph Dolmans Filename: draft-ietf-dnsop-ns-revalidation-03.txt Pages : 7 Date: 2022-09-06 Abstract: This document recommends improved DNS [RFC1034] [RFC1035] resolver behavior with respect to the processing of Name Server (NS) resource record sets (RRset) during iterative resolution. When following a referral response from an authoritative server to a child zone, DNS resolvers should explicitly query the authoritative NS RRset at the apex of the child zone and cache this in preference to the NS RRset on the parent side of the zone cut. Resolvers should also periodically revalidate the child delegation by re-quering the parent zone at the expiration of the TTL of the parent side NS RRset. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/ I wonder about this Datatracker line: Intended RFC status (None) What do authors plan, or WG leans to? Speaking with my BIND hat on, I would prefer Informational. Protocol in this draft is pretty complex, and so far the sky did not fall despite resolvers not implementing it. Based on this observation I think it should not be mandatory, and also that parent-centric DNS resolver implementations should not be "outlawed" by this (to-be) RFC. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Representing DNS Messages in JSON (RFC 8427): ugly EDNS
On 13. 09. 22 10:33, libor.peltan wrote:
Hi all, especially Paul,
while implementing RFC 8427 in Knot DNS, we found that this RFC does not
say anything about EDNS option. This results in general rules for RR
being applied, resulting in very ugly:
"additionalRRs": [
{
"NAME": ".",
"TYPE": 41,
"TYPEname": "OPT",
"CLASS": 1232,
"TTL": 32768,
"rdataOPT": "\\# 24
00030014646E732D7669782D646E7330312E6E69632E637A",
"RDLENGTH": 24,
"RDATAHEX": "00030014646e732d7669782d646e7330312e6e69632e637a"
}
It seems interesting to me, that this RFC is single-authored,
Informational and non-WG.
Do you think we should improve this, making the JSON representation of
OPT anyhow more useful?
If so, how do you think we should proceed? Writing a new RFC draft
updating this?
I think this is a sign of a more generic problem: EDNS options sometimes
do not have standardized and well described "presentation" format.
If we were to fix that I think we should have one catch-all RFC to
define missing presentation forma(s) for all known EDNS options [11]
(it's not that many) and then require new RFCs to specify it.
Besides JSON format it would also help with other text representations,
e.g. in test systems which need to describe queries and answers in some
human-readable format.
[11]
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-11
--
Petr Špaček
Internet Systems Consortium
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation
On 17. 08. 22 17:09, Daisuke HIGASHI wrote: Peter van Dijk <mailto:peter.van.d...@powerdns.com>>: Thank you for reviewing my implementation. Note that the function called "probe_pmtu" does not really probe. At best, it finds some data the kernel cached recently. At worst (i.e. usually), it tells you the MTU of your local networking interface. That's correct. > - A first response (to requester with small PMTU) can be lost because > nobody knows PMTU for destination that a large packet was never sent. > It slows down name resolution - Fortunately this is not a big problem > because 1) will be recovered by retransmission by the requestor (a) why would a requestor retransmit? (b) why would the retransmit help? 1) Responder receives first request and makes response (DF=1) that size is exceeding PMTU and it was not received by requester. 2) Responder should receive ICMP NEEDFRAG and knows PMTU. And at this step we opened the attack window to ICMP-based fragmentation attacks again. 3) Requester (resolvers) _would_ retransmit same request after timeouts if none of response is received. Possibly. Or it can retransmit to another address, or possibly routed to another node in anycast cloud. Or via another path. Or just fallback to TCP and don't bother with UDP anymore. 4) Responder composes DNS message fitting in PMTU or TC=1 (if does not fits in). I admit that my current implementation (responder's behavior which the I-D describes, in my understanding) relies on requester's timeout / retransmission strategy and when PMTU cache information expires same timeout event would occurs again. This is completely unreliable, I'm afraid. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp
On 02. 08. 22 22:29, Edward Lewis wrote: On 8/2/22, 11:02 AM, "DNSOP on behalf of Paul Hoffman" wrote: I would rather mention NSEC/NSEC3 so the reader gets an idea for the mechanism in RFC 8198. I left off NSEC3 because I thought that basically all use of NSEC3 was with opt-out, but if I'm wrong, I could put it in the text. Just as a data point, there are two gTLDs over 1 million delegations that use NSEC3 / no-opt out. I have no data on ccTLDs, nor lower in the namespace. In ccTLD space e.g. CZ has 1.4 million delegations and uses NSEC3 without opt-out: https://stats.nic.cz/dashboard/en/DNSSEC.html -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)
On 28. 07. 22 22:05, Edward Lewis wrote: On 7/26/22, 3:05 PM, "DNSOP on behalf of Petr Špaček" wrote: Interesting history lesson, thank you. Can you elaborate on > therefore only one can be signed. please? What is the reasoning behind it? There were a few iterations in the development of DNSSEC. RFC 4033-4035 are the third iteration. Part of the "reason" is that the DNSSEC definition evolved over a period of years. In the first two iterations, the rules for signing (or not) the cut points were set. NS and glue, carrying information "reported" to the parent were not "from" the parent, hence not signed. The NSEC (and later NSEC3) record did indicate the presence/absence of a zone cut as the presence of the cut was determined by the parent. This design was deemed to be the most backwards-compatible approach (anticipating it would be a very long road to adoption). FWIW, these iterations toyed with having a key set from the child up or something from the parent sent down, none it worked. The DS record was added in the third(?maybe the count is different to others) iteration. Although it contains a hash of what is reported to it by the child it is signed. This is in some sense historically inconsistent. It was felt that the signature here was needed, there had to be some signed statement from the parent to an iterator as it left for the child. Given the DS was "new" there was no backwards compatibility to be maintained, although having this record be authoritative above the cut (well, so was the NSEC/3) was new - yet only seen when "doing" DNSSEC. There was never any sympathy for signing the parent-side NS set at the time. It wouldn't add to the security goals of DNSSEC and potentially lead to confusing case - when the NS sets are out of alignment, which happens when name servers are changed (or where someone makes a mistake). The decision to leave the parent-side NS set unsigned was never completely accepted, there were many thoughts on "fixing" the delegation in the DNS. But doing so was thought to be too disruptive the current running system. Thank you for detailed response! I will continue my quest to understand reasoning behind the current protocol and ask a bit more. By any chance, do you remember in what iteration the DO=1 in query was introduced? I wonder what sort of disruption was anticipated/feared. In hindsight is seems that DO=1 requirement for "new" behavior (like, say, adding RRSIG to delegations sent from the parent zone) could be enough. Thank you for your time. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-01.txt
On 15. 07. 22 14:36, George Thessalonikefs wrote: Hi Libor, Thanks for the time and feedback! If you prefer the dry-run DS to have a static length maybe then you are more interested in the dry-run equivalent algorithm per actual algorithm timeline? It would be interesting to know if your concern for static length arises from a registry point of view (as also mentioned in section 5.1.1), or something else. Although security is unlikely to be an issue currently, it still means that whichever number we choose today may not work in the future. If collisions could happen then a dry-run zone could be spoofed. Although that would not matter for the DNSSEC adoption case as the zone was unsigned in the first place, the other cases (sections 3.1.2 and 3.1.3) would weaken the security of an already DNSSEC signed zone. But apart from security, I am also worried about the extra steps needed to handle the contents of the DS record and using it for DNSSEC (need to also crop/stretch the key digests while validating). I would prefer the DNSSEC part to be mostly intact when dry running so that there is confidence on the reported results and expect the same behavior when advancing from a dry-run state. Do my concerns make sense? They do make sense to me. I think constant DS length is not worth the trouble doing it _this_ "crazy" way. Burning one bit in DS type field sounds more sensible to me and it also solves problem "Registry supports only fixed sized hashes per hash algorithm". It's not like we are forever bound to 8 bits here: E.g. we can easily use a magic value 255 to signal that next octet is continuation of the type field, if the need ever comes. Every new codepoint requires new code anyway so I can't see a problem with this approach. If burning one bit does not have consensus I'm not totally opposed to the variable length approach but see 5.1.1. Aside from that, here is my feedback: 3. Overview Validating resolvers that don't support the DS Type Digest algorithm ignore it as per [RFC6840], Section 5.2. Validating resolvers that support dry-run DNSSEC are signaled to treat the zone as a dry-run zone. Validating resolvers that support dry-run DNSSEC MUST support [DNS-ERROR-REPORTING]. I would like to get rid of this requirement. First, having support for error reporting != feature being enabled so this MUST does nothing useful anyway. Secondly, there is no technical reason for this. There might be other ways to instrument the client side. 3.2. Opt-in end-to-end DNSSEC testing Out of curiosity, do you have an implementation for Unbound? I'm bit worried about complexity of this... 4.1.1. Hash is created from DNSKEY (or CDNSKEY) * Feedback from Gavin Brown from CentralNIC. * DNSKEYs do have space for flags which are ignored. There was a suggestion to use the flags in the DNSKEY to signal Dry-run, but we do not like it, because it makes the move to actual DNSSEC impossible without also changing the DNSKEY RRset. Unfortunately this does not work. Unknown DNSKEY flags are ignored, so resolvers not aware of DRY-RUN will just use them as if the flag was not present. 4.1.3. Idea from Petr: Normalize the different DS hacks Well, if you are ready to push more parent-side RRs count me in! Petr Špaček Best regards, -- Yorgos On 13/07/2022 13:26, libor.peltan wrote: Hi Willem, Yorgos, Roy, dnsop, I dare to repeat my support for the ideas in dry-run-dnssec draft. However, I still don't like the suggested format of dry-run DS record. Another alternative idea: how about putting the Digest Type into the first octet of Digest field like in the draft, but cropping (or stretching) the rest of the actual digest in a way that the overall size of the resulting Digest field is something "normal" (e.g. 32 octets), and does not differ based on actual Digest Type? I assume that for dry-run, the weakened actual security of cropped Digest is not a big deal. Please consider my thought and employ/deny it as needed. Best, Libor ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation
On 26. 07. 22 23:13, Suzanne Woolf wrote:
Dear colleagues,
This message starts the Working Group Last Call for
draft-ietf-dnsop-avoid-fragmentation
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/). The
requested status is BCP.
Since we're starting the Last Call during the IETF week, and many folks are on
holidays in the next few weeks, the WGLC will end in three weeks (instead of
the usual two), on August 16.
Substantive comments to the list, please. It’s fine for minor edits to go
direct to the authors. We need to hear positive support to advance it, or your
comments on what still needs to be done.
Given the fact that most open-source implementations already avoid
fragmentation in one way or another, there is no harm in publishing
"don't fragment" as a RFC, but there is also only limited benefit.
Attacks and problems were years ahead and implementers had to patch
software years ago.
After a quick re-read I agree with the idea but there are implementation
details which are not as simple as laid out in the current text.
This document proposes to set IP_DONTFRAG / IPV6_DONTFRAG in DNS/UDP
messages in order to avoid IP fragmentation, and describes how to
avoid packet losses due to IP_DONTFRAG / IPV6_DONTFRAG.
IP_DONTFRAG and its interaction with networking stack and socket
interface is complex and possibly OS-dependent.
I don't remember all the gory details but BIND went through several
iterations of this and currently we use:
- IP_DONTFRAG - socket option disabled (i.e. fragmentation allowed)
- IP_MTU_DISCOVER = IP_PMTUDISC_OMIT (which is woefully undocumented in
man pages, see https://lists.openwall.net/netdev/2014/02/26/4)
State in other resolvers is somewhat summarized here:
- https://github.com/PowerDNS/pdns/pull/7410/files#r250252209
- https://www.yadifa.eu/archives/yadifa-users/2019-March/000133.html
(From a quick glance it seems we all do the same, or at least try.)
IIRC this was needed to protect from attacks using spoofed Path MTU.
This risk really should be mentioned in the document and discussed. RFC
8201 section 6 is not theoretical, we have seen weird things happen in
real networks. CVE-2021-25218 is my witness :-)
Maybe the currently empty section 8. Security Considerations needs to
copy RFC 8201 section 6 and then conclude that it is insecure anyway, so
don't do it?
I'm not sure how to proceed. On one hand IP_DONTFRAG sounds like a good
idea. On the other hard it does weird things when combined with
IP_MTU_DISCOVER IP_PMTUDISC_OMIT/_DONT. Maybe DNS is even the right
place to start and we should be poking OS people to fix/improve it? I
don't know.
Except for the fundamental problem mentioned above I have just smaller
things:
3.2. Recommendations for UDP requestors >* DNS responses may be dropped
by IP fragmentation. Upon a timeout,
UDP requestors may retry using TCP or UDP, per local policy.
To avoid name resolution fails, UDP requestors need to retry using
TCP, or UDP with smaller maximum DNS/UDP payload size.
The last sentence does not have a normative language and which is IMHO
good, but it slightly errs on side of working around brokenness. ("need
to retry ...")
I think the document should not have the last sentence at all and leave
it with up to implementations to do handle timeouts as they like it.
4. Incremental deployment
I'm not sure if it belongs here to a new "Implementation Status"
section, but I think it's worth mentioning that this document is almost
no-op after https://dnsflagday.net/2020/ .
The default EDNS buffer size have been changed to, sometimes, even lower
values so the fragmentation should not happen anymore.
6.1. Protocol compliance
+1 (or all votes I can possibly hands on!)
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-00.txt
On 27. 07. 22 19:42, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Negative Caching of DNS Resolution Failures Authors : Duane Wessels William Carroll Matthew Thomas Filename: draft-ietf-dnsop-caching-resolution-failures-00.txt I think this is an important clarification to the protocol and we should adopt it and work on it. I like the document up until end of section 2. After that I have reservations about the specific proposals put forth in the section 3. I hope this will kick off discussion, please don't take points personally. I'm questioning the technical aspects. 3. DNS Negative Caching Requirements 3.1. Retries and Timeouts A resolver MUST NOT retry more than twice (i.e., three queries in total) before considering a server unresponsive. This document does not place any requirements on timeout values, which may be implementation- or configuration-dependent. It is generally expected that typical timeout values range from 3 to 30 seconds. I'm curious about reasoning about this. My motivation: Random drop or temporarily saturated/malfunctioning link should not cause resolver to fail for several seconds. As an extreme case, think of validating resolver on a laptop forwarding elsewhere. Should really two packet drops cause it to servfail for several seconds? Related to this, I have a principal objection: IMHO we should NOT be inventing flow control from scratch ourselves. On the contrary - we should be borrowing prior art from existing flow control algorithms and adapt them if necessary. 3.2. TTLs Resolvers MUST cache resolution failures for at least 5 seconds. Resolvers SHOULD employ an exponential backoff algorithm to increase the amount of time for subsequent resolution failures. For example, the initial TTL for negatively caching a resolution failure is set to 5 seconds. The TTL is doubled after each retry that results in another resolution failure. Consistent with [RFC2308], resolution failures MUST NOT be cached for longer than 5 minutes. My motivation: Rapid recovery. Why 5 seconds? Why not 1? Or why not 0.5 s? ... I would like to see reasoning behind specific numbers. IMHO most problems is caused by unlimited retries and as soon as _a_ limit is in place the problem is alleviated, and with exponential backoff we should be able to start small. I'm not sure that a specific number should be mandated. 3.3. Scope Resolution failures MUST be cached against the specific query tuple . Why this tuple was selected? Why not for, say, timeouts? Or why not for timeouts? What about transport protocol and its parameters? (TCP, UDP, DoT...) etc. My motivation: - Simplify cache management. - Imagine an attacker attempting to misuse this new cache. The cache has to be bounded in size. It has to somehow manage overflow etc. Generally I think this MUST is too prescriptive. It should allow for less specific caching if an implementation decides it is fit for a given type of failure and configuration, or depending on operational conditions. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)
On 26. 07. 22 20:59, Paul Vixie wrote: Petr Špaček wrote on 2022-07-26 06:21: On 28. 06. 22 16:20, Bob Harold wrote: > But the parent NS set is not covered by DNSSEC, and thus could be spoofed?? > (Wish we could fix that!) I share your wish. Does anyone else want to contribute? only to fight such a change. Can people here share their memories of why it is not signed? I wasn't doing DNS when this was designed and I think it would be good to understand the motivation before we start proposing crazy things. it exists in two places. only one can be authoritative. therefore only one can be signed. as olafur said down-thread, RFC103x ought to have used different rr types for delegation vs. apex nameserver list. now we live with it. Interesting history lesson, thank you. Can you elaborate on > therefore only one can be signed. please? What is the reasoning behind it? -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)
On 28. 06. 22 16:20, Bob Harold wrote: > But the parent NS set is not covered by DNSSEC, and thus could be spoofed?? > (Wish we could fix that!) I share your wish. Does anyone else want to contribute? Can people here share their memories of why it is not signed? I wasn't doing DNS when this was designed and I think it would be good to understand the motivation before we start proposing crazy things. Thank you for your time. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
On 24. 05. 22 18:21, Wes Hardaker wrote: ** Section 2.2. In general, NSEC3 with the Opt-Out flag enabled should only be used in large, highly dynamic zones with a small percentage of signed delegations. Operationally, this allows for fewer signature creations when new delegations are inserted into a zone. This is typically only necessary for extremely large registration points providing zone updates faster than real-time signing allows or when using memory-constrained hardware Qualitative scales such as “large … dynamic zones” and “extremely large registration points” used. Can the operational experience informing these statements be cited to suggest the scale? That's both a fair point but hard to fix. In early versions of this document, we used more strict wording in places (but not for this case). But in the end we're trying to address a sliding problem, and there is no perfect line to be drawn. How about if we end the paragraph with this: Operators considering the use of NSEC3 are advised to fully test their zones deployment architectures and authoritative servers under both regular operational loads to determine the tradeoffs using NSEC3 instead of NSEC. Sorry for being so late on this ... I think we cannot really do better than "large" because definition of "large" changes every year with new a new CPU model or software optimization (e.g. better parallelization). For that reason I believe Wes's proposal is a good one, albeit very generic. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt
On 07. 04. 22 20:31, Hugo Salgado wrote: On 17:30 07/04, Petr Špaček wrote: On 07. 04. 22 15:47, Paul Vixie wrote: Petr Špaček wrote on 2022-04-06 23:54: Hello, ... From my perspective, these systems are not rare, quite the contrary: - PowerDNS with a database backend - Multi-master flavors of BIND - Various "cloud" auths with dynamic backends - Windows DNS with Active Directory (I think) because IXFR and NOTIFY and UPDATE use serial numbers, the DNS protocol itself is aware of serial numbers. i hope that any recognition of non-traditional serial numbers will be an optional addition to the RRSERIAL response, and that if a zone has no actual serial number (so, it cannot participate in IXFR, NOTIFY, and UPDATE) the RRSERIAL value will just be a magic number like zero, or just missing altogether. I fail to understand what you mean, can you elaborate? I will try to rephrase myself for clarity: "Let's make this draft _also_ usable for debugging e.g. PowerDNS and multi-master BIND." Hi Petr, thank you for your suggestions. The way we see RRSERIAL extension is just as a copy of the SOA serial value. I think what you’re trying to describe on PowerDNS and multi-master BIND, is that the value contained there doesn’t offer any meaning; I assume it could be either 0 or 1 or any custom other value (and here, we can all agree there is a value). In such cases I would still expect an RRSERIAL answer with that specific value, irrespective if it has a meaning, and also, those implementations can just avoid to answer RRSERIAL queries (which BTW it is allowed). Did we understand that correctly, right? Yes, that's exactly what I meant. So, maybe there's another way of accomplish this need: we can drop entirely this RRSERIAL option, and create a new "ZONEVERSION" EDNS option, that has a new meaning of... well... zone versioning :) So, this ZONEVERSION value would be the SOA serial number in classic zones (like this RRSERIAL proposal) but it would also add a new opaque meaning for the other server implementations. If this new value has another structure, then maybe we need a new field inside ZONEVERSION to differentiate it. If it's just a 32 bits unsigned number just like RRSERIAL, then it's a number, just not the same as the SOA serial value. Yes, that's basically what I meant. Let's sketch a wire format for ZONEVERSION option: - 1 byte - flags - 2 bytes - length L - L bytes Flags: - bit 0 - is the value in fact SOA serial? What do you think? -- Petr Špaček P.S. I'm going to be AFK for a week or so. Silence from my side does not mean I intentionally ignore responses. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt
On 07. 04. 22 15:47, Paul Vixie wrote: Petr Špaček wrote on 2022-04-06 23:54: Hello, ... From my perspective, these systems are not rare, quite the contrary: - PowerDNS with a database backend - Multi-master flavors of BIND - Various "cloud" auths with dynamic backends - Windows DNS with Active Directory (I think) because IXFR and NOTIFY and UPDATE use serial numbers, the DNS protocol itself is aware of serial numbers. i hope that any recognition of non-traditional serial numbers will be an optional addition to the RRSERIAL response, and that if a zone has no actual serial number (so, it cannot participate in IXFR, NOTIFY, and UPDATE) the RRSERIAL value will just be a magic number like zero, or just missing altogether. I fail to understand what you mean, can you elaborate? I will try to rephrase myself for clarity: "Let's make this draft _also_ usable for debugging e.g. PowerDNS and multi-master BIND." I cannot see any technical reason not to support it. Moreover this draft does not touch notify or transfer protocol in any way - which is why your e-mail confuses me. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt
Hello, I think this is useful in a very limited way. The reason of this limitation is already stated in section 1: > The RRSERIAL EDNS extension doesn't offer much relevance for zones served by an Authoritative server that don't use the SOA serial versioning as a meaning to its content. There are cases where nameservers use different backends for its data sources, like relational databases or by using a different off-DNS synchronicity. In such cases this extension has no benefit or utility to use in debugging or analysis of a response. From my perspective, these systems are not rare, quite the contrary: - PowerDNS with a database backend - Multi-master flavors of BIND - Various "cloud" auths with dynamic backends - Windows DNS with Active Directory (I think) To handle the traditional SERIAL together with more "modern" backends I propose simple modification to extend this draft to handle both. Say that wire format could look like: This allows the auth server to either send (length=2,data=4) with SOA serial as usual, or return any other identification suitable for a given backend. If we _really_ wanted we could add also type field to distinguish "traditional" SERIAL vs. backend-specific blob, but I think it is not really needed. To me this is very simple addition which increases value of the proposed protocol. Opinions? Petr Špaček On 06. 04. 22 16:26, Hugo Salgado wrote: Dear DNSOP. The authors have just reactivated the draft after its expiration, with no changes. After some time waiting for other more urgent documents, we believe that we can now reactivate it in the WG and ask for your opinions. The last comments and suggestion were acknowledged, and we think we could be close to Last Call. As this document indicates where I have tried to keep track of work (https://github.com/huguei/rrserial) there's a new implementation in NSD and a couple of clients (dig and perl Net::DNS). Currently we're working in an infrastructure for a public testbed that we'll make available for implementers. Thanks, Hugo On 07:08 06/04, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : The "RRSERIAL" EDNS option for the SOA serial of a RR's zone Authors : Hugo Salgado Mauricio Vergara Ereche Filename: draft-ietf-dnsop-rrserial-01.txt Pages : 6 Date: 2022-04-06 Abstract: The "RRSERIAL" EDNS option allows a DNS querier to request a DNS authoritative server to add an EDNS option in the answer of such query with the SOA serial number field of the origin zone which contains the answered Resource Record. This "RRSERIAL" data allows to debug and diagnose problems by helping to recognize the data source of an answer in an atomic single query, by associating the response with a respective zone version. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rrserial/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-rrserial-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rrserial-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping
On 25. 03. 22 16:27, Benno Overeinder wrote: As announced during the DNSOP meeting this week at the IETF 113, we are starting a Call for Adoption for the draft-thomassen-dnsop-dnssec-bootstrapping. With the survey we conducted before the last IETF 112, this draft was a clear candidate. With this email we start a period of two weeks for the call for adoption of draft-thomassen-dnsop-dnssec-bootstrapping on the mailing list. The draft is available here: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 8 April 2022 I think this draft is suitable for adoption. I'm willing to contribute reviews. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More private algorithms for DNSSEC
On 23. 03. 22 10:45, Peter van Dijk wrote: So, Paul, I support the idea behind your draft, but not the current wording. While more 253-like points might be somewhat useful, what we really need are experimental code points with non-253 semantics. I agree. IMHO experiment codepoint which does not get any special treatment would be good enough. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-04.txt
On 22. 03. 22 14:02, Ralf Weber wrote: Moin! So to follow up on my comment in the working group on registries not having anything to do with it. I understand that this drafts is for authoritative name server implementers, however I think that we should make clear that an authoritative name server not answering correct by this draft might do so because it does not have sufficient data. So we currently have in the introduction: Note that this document only clarifies requirements of name server software implementations. It does not place any requirements on data placed in DNS zones or registries. how about adding: However missing data might make it impossible for a name server to answer with the correct (referral) glue data. And maybe add some encouragement or referral ;-) to work that has to be done elsewhere. Sounds reasonable to me. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-05.txt
On 08. 03. 22 15:51, Willem Toorop wrote: Dear dnsop, This draft describes a mechanism for automatic provisioning of zones among authoritative name servers by way of distributing a catalog of those zones encoded in a regular DNS zone. This version's focus was getting ready for WGLC. Filename: draft-ietf-dnsop-dns-catalog-zones-05.txt FTR during IETF 113 hackaton we have tested basic interoperability of NSD, Knot DNS, and the very last work-in-progress version of BIND with success: The basic zone de/provisioning worked as specified without using any extensions. BIND currently does not support the optional "group" property a Knot DNS and NSD do not support he optional "coo" property, so we did not really test these. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IANA Policy for SVCB
On 21. 03. 22 10:37, Jim Reid wrote: On 21 Mar 2022, at 09:19, Ben Schwartz wrote: Personally, I favor #3. What do you think? Ben, I think 2 (Expert Review) is the right approach. This would hopefully ensure any specifications are complete/valid and raise the threshold to discourage bad or frivolous SrvParamValues "registrations". An Expert Review seems right to me. It's culturally compatible with how we handle the allocation of new RRtypes. +1 for Expert Review for reasons stated by Jim. I don't see #3 as really needed. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-06.txt
On 07. 03. 22 17:51, internet-dra...@ietf.org wrote: Filename: draft-ietf-dnsop-nsec3-guidance-06.txt I have no nits to report. Such thing have not happened to me for a long time - well done! -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-ietf-dnsop-nsec3-guidance-03.txt
On 28. 02. 22 18:11, Viktor Dukhovni wrote: On Mon, Feb 28, 2022 at 03:43:59PM +0100, Petr Špaček wrote: Keep this: >>> 3.2. Recommendation for validating resolvers >>> Note that a validating resolver MUST still validate the signature >>> over the NSEC3 record to ensure the iteration count was not altered >>> since record publication (see [RFC5155] section 10.3). And here add this as continuation of the previous sentence? ... because the invalid signature might have additional implications. E.g. EDE code, or insecure validation status if an implementation chose to treat certain range of NSEC3 iteration values as DNSSEC-insecure etc. (modulo grammar fixes etc., of course) I think this makes the reason clear to everyone and also makes it somewhat legal to ignore signature validation it IF "visible outcome" does not change by doing so. What do you think? I don't understand this comment, the reason for the signature check is that otherwise we get trivial downgrade attacks. NSEC3 replies from a signed zone with an invalid signature MUST be treated as "bogus". What did you have in mind? What does "visible outcome" mean? I'm just trying to rephrase what Vladimir already said. His Knot Resolver has a single threshold and treats anything with iteration count value > XXX as bogus (by ignoring the NSEC RR with high iteration count), so why should he be validating the signature before declaring it SERVFAIL anyway? There are only two options: - Iteration count is too big and signature valid -> visible outcome = SERVFAIL - Iteration count was modified and signature is invalid because of the modification -> visible outcome = SERVFAIL The only reason to validate would be to set EDE code, but if that is not being done by the implementation then "MUST validate" is unnecessary as it is busy work which does not change the visible outcome. In the hypothetical scenario where the resolver had three ranges, "low enough to validate", "middle range to treat as insecure", "too high treat as SERVFAIL" then the MUST validate makes sense for the middle range where validity of the signature distinguishes between insecure/bogus states. Does it make sense? -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-ietf-dnsop-nsec3-guidance-03.txt
On 26. 02. 22 0:40, Wes Hardaker wrote: Petr Špaček writes: First, I perceive a "problem" with the current document structure: 2. Recommendation for zone publishers . . . . . . . . . . . . . 3 2.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Salt . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Recommendations for deploying and validating NSEC3 records . 6 3.1. Best-practice for zone publishers . . . . . . . . . . . . 6 3.2. Recommendation for validating resolvers . . . . . . . . . 7 3.3. Recommendation for Primary / Secondary relationships . . 7 It seems odd to have "2. Recommendation for zone publishers" followed by "3.1 Best-practice for zone publishers". You bring up a good point.When looking at it though, 3.1 really does look written for zone publishers but actually maybe we should change the title of 2 is actually what's wrong. How about "NSEC3 parameter value considerations": 2. NSEC3 parameter value considerations . . . . . . . . . . . . 3 2.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Salt . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Recommendations for deploying and validating NSEC3 records . 5 3.1. Best-practice for zone publishers . . . . . . . . . . . . 6 3.2. Recommendation for validating resolvers . . . . . . . . . 6 3.3. Recommendation for Primary / Secondary relationships . . 7 Sounds good to me. Either my understanding of relationship between terms "recommendation" vs. "best practice" is wrong, or these should be somehow renamed. Say "Background information about NSEC3 parameters" as name of section 2? Also there is now a SHOULD vs. MUST inconsistency between _content_ of sections 2.3. Iterations and section 3.1. Best-practice for zone publishers: Good catch; I took your suggestion about dropping that half-sentence. Okay, that clarifies things. Thank you! The only other thing worth mentioning is a nit which I don't feel strongly about: 3.2. Recommendation for validating resolvers Note that a validating resolver MUST still validate the signature over the NSEC3 record to ensure the iteration count was not altered since record publication (see [RFC5155] section 10.3). Technically RRSIG validation is needed only if the resolver treats some combination of parameters as insecure. If it is going to SERVFAIL for e.g. large iteration value anyway then there is no point in validating the RRSIG, I think. I think the reason is the error is different (eg EDE). You're right that the processing may be an overload (but if it is, you can always just drop it per the other thread too). Anyway, if others support this change we can discuss it further, but it's been discussed before. So to the others: please chime in if you agree and we want to revert the existing consensus based on this new thinking. Maybe there is an option to keep the current MUST if we add an additional clarification? Keep this: >>> 3.2. Recommendation for validating resolvers >>> Note that a validating resolver MUST still validate the signature >>> over the NSEC3 record to ensure the iteration count was not altered >>> since record publication (see [RFC5155] section 10.3). And here add this as continuation of the previous sentence? ... because the invalid signature might have additional implications. E.g. EDE code, or insecure validation status if an implementation chose to treat certain range of NSEC3 iteration values as DNSSEC-insecure etc. (modulo grammar fixes etc., of course) I think this makes the reason clear to everyone and also makes it somewhat legal to ignore signature validation it IF "visible outcome" does not change by doing so. What do you think? -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-ietf-dnsop-nsec3-guidance-03.txt
On 09. 02. 22 23:28, Wes Hardaker wrote: internet-dra...@ietf.org writes: A new version of I-D, draft-ietf-dnsop-nsec3-guidance-03.txt has been successfully submitted by Wes Hardaker and posted to the IETF repository. Name: draft-ietf-dnsop-nsec3-guidance Revision: 03 Sorry the delay in resolving the discussions in December and getting a new version out. January was a very long deadline-month for me. I believe I've acted on all the recent suggestions (thank you!), and the document is now pretty much ready for WG last call. IMHO. I'm happy with values mentioned in the document, thank you! I gave it full re-read and there are two more edit proposals, hopefully non-controversial: First, I perceive a "problem" with the current document structure: 2. Recommendation for zone publishers . . . . . . . . . . . . . 3 2.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Salt . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Recommendations for deploying and validating NSEC3 records . 6 3.1. Best-practice for zone publishers . . . . . . . . . . . . 6 3.2. Recommendation for validating resolvers . . . . . . . . . 7 3.3. Recommendation for Primary / Secondary relationships . . 7 It seems odd to have "2. Recommendation for zone publishers" followed by "3.1 Best-practice for zone publishers". Either my understanding of relationship between terms "recommendation" vs. "best practice" is wrong, or these should be somehow renamed. Say "Background information about NSEC3 parameters" as name of section 2? Also there is now a SHOULD vs. MUST inconsistency between _content_ of sections 2.3. Iterations and section 3.1. Best-practice for zone publishers: 2.3. Iterations ... Although Section 10.3 of [RFC5155] specifies upper bounds for the number of hash iterations to use, there is no published guidance for zone owners about good values to select. Because hashing provides only moderate protection, as shown recently in academic studies of NSEC3 protected zones [GPUNSEC3][ZONEENUM], this document recommends that zone owners SHOULD use an iteration value of 0 (zero), indicating that only the initial hash value should be placed into a DNS zone's NSEC3 records. vs. 3.1. Best-practice for zone publishers First, if the operational or security features of NSEC3 are not needed, then NSEC SHOULD be used in preference to NSEC3. NSEC3 requires greater computational power (see Appendix B) for both authoritative servers and validating clients. Specifically, there is a non trivial complexity in finding matching NSEC3 records to randomly generated prefixes within a DNS zone. NSEC mitigates this concern. If NSEC3 must be used, then an iterations count of 0 MUST be used to alleviate computational burdens. Please note that extra iteration counts other than 0 increase impact of resource CPU- exhausting DoS attacks, and also increase risk of interoperability problems. My proposal to fix that inconsistency is to remove last part of 2.3, specifically: , this document recommends that zone owners SHOULD use an iteration value of 0 (zero), indicating that only the initial hash value should be placed into a DNS zone's NSEC3 records. and be done with it. Section 3.1 repeats the same thing, so no need to duplicate it and risk inconsistencies. The only other thing worth mentioning is a nit which I don't feel strongly about: 3.2. Recommendation for validating resolvers Note that a validating resolver MUST still validate the signature over the NSEC3 record to ensure the iteration count was not altered since record publication (see [RFC5155] section 10.3). Technically RRSIG validation is needed only if the resolver treats some combination of parameters as insecure. If it is going to SERVFAIL for e.g. large iteration value anyway then there is no point in validating the RRSIG, I think. Additionally I've submitted PR#6 with purely editorial nits. Thank you for your persistence! -- Petr Špaček @ Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-dwmtwc-dnsop-caching-resolution-failures-00.txt
Hello everyone, it seems that we now have two drafts about the same topic - this new one and draft-moura-dnsop-negative-cache-loop. Perhaps authors could discuss if they are in agreement and could pick one? Petr Špaček @ Internet Systems Consortium On 14. 01. 22 19:14, Wessels, Duane wrote: Dear DNSOP, In light of some recent events and research, we feel that it could be beneficial to strengthen the requirements around negative caching of DNS resolution failures. Please see the recently submitted Internet Draft referenced below and let us know if you have any feedback. DW Begin forwarded message: *From: *mailto:internet-dra...@ietf.org>> *Subject: **[EXTERNAL] New Version Notification for draft-dwmtwc-dnsop-caching-resolution-failures-00.txt* *Date: *January 13, 2022 at 1:28:00 PM PST *To: *Duane Wessels <mailto:dwess...@verisign.com>>, Matthew Thomas <mailto:mtho...@verisign.com>>, William Carroll mailto:wicarr...@verisign.com>> A new version of I-D, draft-dwmtwc-dnsop-caching-resolution-failures-00.txt has been successfully submitted by William Carroll and posted to the IETF repository. Name:draft-dwmtwc-dnsop-caching-resolution-failures Revision:00 Title:Negative Caching of DNS Resolution Failures Document date:2022-01-13 Group:Individual Submission Pages:13 URL: https://www.ietf.org/archive/id/draft-dwmtwc-dnsop-caching-resolution-failures-00.txt <https://www.ietf.org/archive/id/draft-dwmtwc-dnsop-caching-resolution-failures-00.txt> Status: https://datatracker.ietf.org/doc/draft-dwmtwc-dnsop-caching-resolution-failures/ <https://datatracker.ietf.org/doc/draft-dwmtwc-dnsop-caching-resolution-failures/> Htmlized: https://datatracker.ietf.org/doc/html/draft-dwmtwc-dnsop-caching-resolution-failures <https://datatracker.ietf.org/doc/html/draft-dwmtwc-dnsop-caching-resolution-failures> Abstract: In the DNS, resolvers employ caching to reduce both latency for end users and load on authoritative name servers. The process of resolution may result in one of three types of responses: (1) a response containing the requested data; (2) a response indicating the requested data does not exist; or (3) a non-response due to a resolution failure in which the resolver does not receive any useful information regarding the data's existence. This document concerns itself only with the third type. RFC 2308 specifies requirements for DNS negative caching. There, caching of type (1) and (2) responses is mandatory and caching of type (3) responses is optional. This document updates RFC 2308 to require negative caching for DNS resolution failures. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] How Slack didn't turn on DNSSEC - is there an appetite for Clarifications RFC?
On 30. 11. 21 19:38, John Levine wrote: This blog post has been making the rounds. Since it is about a sequence of DNS operational failures, it seems somewhat relevant here. https://slack.engineering/what-happened-during-slacks-dnssec-rollout/ tl;dr first try was rolled back due to what turned out to be an unrelated failure at some ISP second try was rolled back when they found they had a CNAME at a zone apex, which they had never noticed until it caused DNSSEC validation errors. third try was rolled back when they found random-looking failures that they eventually tracked down to bugs in Amazon's Route 53 DNS server. They had a wildcard with A but not records. When someone did an query, the response was wrong and said there were no records at all, not just no records. This caused failures at 8.8.8.8 clients since Google does aggressive NSEC, not at 1.1.1.1 because Cloudflare doesn't. They also got some bad advice, e.g., yes the .COM zone adds and deletes records very quickly, but that doesn't mean you can unpublish a DS and just turn off DNSSEC because its TTL is a day. Their tooling somehow didn't let them republish the DNSKEY at the zone apex that matched the DS, only a new one that didn't. It is clear from the blog post that this is a fairly sophisticated group of ops people, who had a reasonable test plan, a bunch of test points set up in dnsviz and so forth. Neither of these bugs seem very exotic, and could have been caught by routine tests. Can or should we offer advice on how to do this better, sort of like RFC 8901 but one level of DNS expertise down? During DNS OARC 36, there were talks about an opportunity to write "Clarifications" RFC. Personally I think the current RFC are clear how NSEC(3) bitmaps should look like, but I can also see that making sense various types of "NSEC lies", "type shotguns", etc. and their consequences requires way more research then reading RFC 4034. Are there people on this list interested working on this? I can contribute ideas and some proto-text, but as you can see for yourself someone needs to translate my texts to proper English so I should not be a document editor. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] How Slack didn't turn on DNSSEC
On 01. 12. 21 12:07, Tim Wicinski wrote: What I noticed in reading this nice write up was the warning image they missed in the Route53 console because of the automation they use. But most folks use automation/tooling/etc in their workflow, and catching those warnings via automation is a bit tricky. Right after this happened several different teams looking to sign their zones got a little nervous. This writeup helps to show people how things can break, but also, there is a great set of testing methods to assist others. Mark's comments about adding tests in DNSVIZ would be pretty great. It is already implemented in DNSViz since December 2020 (so a year+ before the Slack outage), but it is not shown by default: https://github.com/dnsviz/dnsviz/issues/76#issuecomment-985331543 -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
On 27. 11. 21 7:12, Viktor Dukhovni wrote: On Fri, Nov 26, 2021 at 12:32:19PM +0100, Petr Špaček wrote: Also, when we are theorizing, we can also consider that resalting thwarts simple correlation: After a resalt attacker cannot tell if a set of names has changed or not. With a constant salt attacker can detect new and removed names by their hash. (I'm not sure it is useful information without cracking the hashes.) Actually, no. If one has previously been mostly successful at cracking extant names in a zone, rehashing of a small set (much smaller than the full dictionary one use) of known names is rather quick. So old names can be quickly identified even after a salt change. Leaving just the hashes of new names. To be clear: I was talking about attacker who does not cracked the zone. You are right that rehashing know names is very cheap. Mind you, for cracking the new names, one would still rehash the entire dictionary when the salt changes, the number of new names to check is not a scaling factor in the cost. Just a table join. So periodic resalting does raise the cost of ongoing tracking of a zone's content, if that's the sort of thing one cares enough about. Rarely worth it, but mostly harmless if the salt is not too long and rotated say on each ZSK rollover. Plus all the mess with large zone transfers, which often can cause issues, especially when done in huge batches (like rotating ZSK/salt shared for 100 000 zones on a shared hosting.) -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
On 26. 11. 21 11:49, Vladimír Čunát wrote: On 25/11/2021 13.00, Petr Špaček wrote: IMHO in the context of NSEC3 the salt would make sense _only_ if it were rotated faster than attacker was able to walk the zone. Once attacker has list of hashes available for offline cracking the salt does not do anything useful anymore. I disagree; you don't need to rotate so fast. At a moment when a particular salt won't be contained in future answers, there's no point in creating a dictionary anymore as it's cheaper to crack the gathered hashes individually. The only value of dictionary is (possibly) speeding up attacks on names that will appear in future - and the only value in re-salting is in making this technique more expensive. Resalting interval is the period when a particular dictionary is useful, so basically by halving the interval you double the price of this. [all IMHO] You are right right, I did not consider "crack names which do not exist yet" scenario and focused only on dictionary reuse across zones. Do you have specific proposals for draft text? Also, when we are theorizing, we can also consider that resalting thwarts simple correlation: After a resalt attacker cannot tell if a set of names has changed or not. With a constant salt attacker can detect new and removed names by their hash. (I'm not sure it is useful information without cracking the hashes.) -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
On 26. 11. 21 9:43, Matthijs Mekking wrote: On 25-11-2021 13:00, Petr Špaček wrote: On 25. 11. 21 9:33, Matthijs Mekking wrote: 3.2. Recommendation for validating resolvers I understand why the new text is here, but I think this now actually gives too little advice for operators and vendors. I know, this is a vague comment, I need to think about it a bit more. Honestly I can't see anything more specific which will not get out of date quickly. Can we make use of the keyword MAY? This allows I think for text that will not get out of date: Validating resolvers MAY return an insecure response when processing NSEC3 records with iterations larger than 0. Validating resolvers MAY also return SERVFAIL when processing NSEC3 records with iterations larger than 0. This significantly decreases the requirements originally specified in Section 10.3 of [RFC5155]. See the Security Considerations for arguments on how to handle responses with non-zero iteration count. Having text that says "MAY do this at value X" is more quantifiable and IMO a stronger signal that zone publishers really should not use value X. Yes, I like this! Maybe your proposed text can be prepended/appended to the current content of 3.2. Recommendation for validating resolvers, so we can keep the "vendors are encouraged to continue evaluating NSEC3 iteration count deployments" part? -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
as been completed. As a result, re-salting a is very complex operation, with significant CPU time, memory, and bandwidth consumption. This makes very frequent re-salting unpractical, and renders the additional salt field almost useless. Operators are encouraged to forget the salt entirely by using a zero-length salt value instead (represented as a "-" in the presentation format). I'm tempted to put the last paragraph first, because all the rest is justification and I don't want to drown the important piece of information in it. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-01.txt
Hello dnsop folks,
Discussion with Manu Bretelle in the other thread got me thinking about
the subset of codes operators want to hear about. Let's think a bit
about this part of spec:
On 09. 11. 21 23:59, internet-dra...@ietf.org wrote:
Filename: draft-ietf-dnsop-dns-error-reporting-01.txt
6.1.1. Constructing the Reporting Query
The QNAME for the reporting query is constructed by concatenating the
following elements, appending each successive element in the list to
the right-hand side of the QNAME:
o A label containing the string "_er".
o The Extended DNS error, presented as a decimal value, in a single
DNS label.
o The QTYPE that was used in the query that resulted in the extended
DNS error, presented as a decimal value, in a single DNS label.
o The QNAME that was used in the query that resulted in the extended
DNS error. The QNAME may consist of multiple labels and is
concatenated as is, i.e. in DNS wire format.
o A label containing the string "_er".
o The reporting agent domain. The reporting agent domain consists
of multiple labels and is concatenated exactly as received in the
EDNS option sent by the authoritative server.
4.2. Example
_er.7.1.broken.test._er.a01.reporting-agent.example
Using RFC 8020 ("there's nothing below NXDOMAIN") or RFC 8198 (DNSSEC
aggressive cache) an operator can effectively cut out some parts of the
"reporting subtree" and dampen queries for it. This enables various
tricks, depending on how we construct the query name:
_er..._er.
_er..._er.
A) Variant A (current draft):
- I'm operating domain "petrs.example"
- subtree "dnssec-failed.petrs.example" is a playground which
intentionally fails DNSSEC validation (sorry Manu :-))
- error reporting agent domain is "agent.test"
I use domain dnssec-failed.petrs.example in a piece of Javascript which
renders "DNSSEC validation does (not) work" text on my web front page
page, so it gets queried fairly often, and I do not want to hear about
failures in this subtree.
Within the current draft it can be done with agent.test zone file like this:
$ORIGIN _er.agent.test.
* TXT "tell me!"
dnssec-failed.petrs.example TXT "silence"
Wildcard expansion rules & RFC 8020 & query name minimization will cut
out the whole subtree, saving traffic and also noise in data received by
the reporting agent.
B) Variant B:
- My domain "petrs.example" hosts a really nasty political satire, and
it gets censored a lot
- I don't care about reports of EDE "Censored" because there is nothing
I can do about them anyway
- I still _do_ care about technical issues.
To make use of the same technique as in the previous example (wildcard),
we would have to switch order of elements in the reporting query to:
_er..._er.
This structure allows to use the same trick on per-EDE code basis:
$ORIGIN _er.agent.test.
* TXT "tell me!"
16 TXT "silence" ; 16 = EDE Censored
The question is: Which variant is better?
I don't remember from our previous discussions if the current ordering
in draft was a conscious choice or not, sorry if I forgot.
Have a great weekend everyone!
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01
Hello everyone, let me try to to restart the discussion about "Structured Data for Filtered DNS" draft. See below. On 14. 10. 21 19:36, Dan Wing wrote: > We recently published -01 of Structured Data for Filtered DNS based on WG feedback from IETF 111. We also incorporated both motivational and normative text from draft-reddy-dnsop-error-page. New version at: https://datatracker.ietf.org/doc/html/draft-wing-dnsop-structured-dns-error-page-01 On 10. 11. 21 17:17, Petr Špaček wrote: Let's start from the hardest questions: 1. Input from browser vendors - I believe we really really _really_ need input from end-client vendors, most importantly Google Chrome and Safari. Is there any indication that they might be interested? If not, why? In my experience browser people have much better idea about UX design and HTTP ecosystem security than we DNS people do, and they might have different requirements on the data we plan to send back to clients, or reasons why the idea cannot be implemented in browsers as is. I'm CCing known Google and Mozilla people on this e-mail. Please kindly ask Safari people if you know any to contribute here as well. So, to really start again, I think we need to make step back and ask what browsers are willing to work with. Currently the user experience with any sort of blocking follows. This is what user sees if: - blocking is done via forged NXDOMAIN - the the site has a DNS outage - there is a typo in the domain name Chromium: This site can’t be blockedsite.example’s server IP address could not be found. Try: Checking the connection Checking the proxy, firewall, and DNS configuration ERR_NAME_NOT_RESOLVED Firefox: Hmm. We’re having trouble finding that site. We can’t connect to the server at blockedsite.example. If that address is correct, here are three other things you can try: Try again later. Check your network connection. If you are connected but behind a firewall, check that Firefox has permission to access the Web. Safari: Safari Can't Find the Server Safari can't open the page "blockedsite.example" because Safari can't find the server "blockedsite.example". This is what happens if blocking is done with forged A RR answer pointing to a web server serving "this is blocked" web page: Chromium: Your connection is not private Attackers might be trying to steal your information from blockedsite.example (for example, passwords, messages, or credit cards). Learn more NET::ERR_CERT_COMMON_NAME_INVALID Firefox: Warning: Potential Security Risk Ahead Firefox detected a potential security threat and did not continue to blockedsite.example. If you visit this site, attackers could try to steal information like your passwords, emails, or credit card details. What can you do about it? The issue is most likely with the website, and there is nothing you can do to resolve it. You can notify the website’s administrator about the problem. Safari: This Connection Is Not Private This website may be impersonating "blockedsite.example" to steal you personal or financial information. You should go back to the previous page. Finally, The Question for web browser vendors is: Do you have an interest in improving this user experience? If the answer is yes, what extra information from the resolver you need? Thank you for your time. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01
On 12. 11. 21 15:26, Stephane Bortzmeyer wrote: On Thu, Nov 11, 2021 at 12:59:42PM +0100, Vittorio Bertola wrote a message of 24 lines which said: I don't want to speak for them (I don't know if they are on this list, but they definitely are on ADD) but in past discussions around this concept they recognized its potential usefulness (apart maybe from a specific browser which seems to have a principle stance against DNS filters) but were concerned about the security of the mechanism, i.e. the risk that it could be used to present to the user a phishing or misleading page, Moreover, I have serious doubts that DNS configuration errors could be meaningfully reported to end users. It would be very difficult to make them understandable and, since we deal with errors in authoritative servers, the client could not do anything, anyway. I have nothing against informing users (some will find that useful) but we should focus on reporting to the zone manager, not to the client. Seems like you are talking about a different document? Or are you suggesting the document to be dropped entirely because it goes in a completely wrong direction? -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Status of draft-ietf-dnsop-dns-error-reporting
ing feature completely ... Having said that, we can have _some_ text in Security considerations section, but someone needs to write a sensible description - which I'm not capable of. Have a great day. Petr Špaček Thanks, Manu There was a request to put the markdown version of the document in GitHub. This has now been placed here: https://github.com/RoyArends/draft-ietf-dnsop-dns-error-reporting <https://github.com/RoyArends/draft-ietf-dnsop-dns-error-reporting> New version: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-01.txt <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-01.txt> Diffs: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-error-reporting-01 <https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-error-reporting-01> Warm regards, Roy Arends ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Deprecating infrastructure .INT domains
On 11. 11. 21 17:56, Joe Abley wrote: Hi Kim, I like the idea of cleaning this up. Choosing nsap.int as an example, I think it would be useful to either update RFC 1706 to make it clear that the advice in section 6 of that document no longer applies, and that no reverse mapping for NSAP is provided in the DNS. I don't think this is a great operational necessity since I imagine the number of people who expect this to work is approximately zero but it seems good to be tidy. [I'd suggest reclassifying 1706 to historic but that'd also affect the specification for the NSAP RRType; maybe that's a good idea too, but it seems outside the scope of what you are trying to achieve, and I don't know how we would confirm that it's a good idea.] Similar comment for other domains where there's similar existing advice. FTR I can't see any problems with that, and suggest to do that in one go in this document. We have enough RFCs already and wasting more numbers (and work) on simple deprecation does not sound useful to me. Petr Špaček Happy to offer actual text if that seems useful. Joe On 11 Nov 2021, at 11:38, Kim Davies wrote: Colleagues, I wanted to draw your attention to an Internet Draft we’ve developed, its goal is to formally deprecate a number of historic “.int” domains that were designated for Internet infrastructure purposes decades ago and appear for all intents and purposes obsolete. After some limited consultation on developing the approach so far, it would be useful to get some additional eyes on it so we have greater confidence there is nothing we’ve missed. Datatracker link: https://datatracker.ietf.org/doc/draft-davies-int-historic/ It’s a short document, but at its heart we’ve identified the following domains that are referenced in places but seem to be obsolete: atma.int, ip4.int, nsap.int, rdi.int, reg.int, tpc.int Most of these are not delegated in the int zone any longer, but there are lingering references to them. Thanks in advance for any insight, and apologies if you get this message in duplicate, ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01
quot;r" fields, and also detect undesired forwarding of EDNS(0) options. This field is mandatory. I think it is grave mistake to conflate name of DNS responder and domain "base" domain for HTTPs error pages. Especially for DoT there is typically no HTTPS running on the host, and IMHO it is pretty bad idea to require that on the protocol level. Security considerations section hints there might be reasons for this I did not find in the archives, but then please spell them out explicitly. j: (justification) the textual justification for this particular DNS filtering. This field is mandatory. I don't think that text field "justification" needs to be mandatory. Even if the field is technically mandatory it can be just an empty string, so ... In any case we should get feedback on this field browsers. Is it even useful without translations? etc. Ad proposed DNS protocol itself: 3. Structured Error EDNS(0) Option Code 5. Protocol Operatio Protocol-wise, I think it would be better to do this: 1. Client can optionally send a new option to request structured errors - this option should always be empty. (= No change.) 2. If the new option was present in query, then DNS responder sends back Extended DNS Errors option (EDE, RFC 8914) with INFO-TEXT field formatted according to structured JSON specified in this draft. This IMHO has several advantages: a) It completely eliminates protocol corner cases like structured error option being present without an allowed EDE option being present (currently forbidden by section 5.3. Client Processing Response anyway). b) It offers a way to add data to other EDE codes as we see fit, now or in the future. It is conceivable to send URI of an informational page for EDE 22 - No Reachable Authority happens. I guess lots of operators would love ability to show a page "facebook.com is down for everyone, this is not our fault, so don't bother calling our support line". Sure, it does not fit into complain/regulation categories, but we could simply add a new URI field "extra-info" for cases like this. 7. Security Considerations This very much needs feedback from browser vendors. First part about isolated environment looks okay to my HTTP-inexperienced eyes, but I think there might be some important details. E.g. is Accept-Language HTTP header permissible? I would say it should be otherwise we cannot meaningfully show errors in language understood by the user etc. For this part I need some clarification: Although the "d" value is validated, an attacker who is able to inject the Structured Error EDNS(0) option so that a DNS proxy or DNS forwarder, unaware of the option, will forward it and pass the validation checks described in Section 5.3. This means the other JSON fields can be controlled by the attacker. The "j" and "o" fields are, perhaps, the most interesting for an attacker to modify for nefarious purposes, because the "d" field has to match the encrypted DNS server's name and the expanded URIs from the "c" and "r" will point at the DNS resolver not under the attacker's control. What attack scenario is this describing? DNS proxy which accepts encrypted connections but then blindly forwards via insecure channel upstream? Seriously? Congratulations if you made it this far - have a great day! -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-moura-dnsop-negative-cache-loop
On 10. 11. 21 10:31, Giovane C. M. Moura wrote:
Ad the draft content:
2. Past solutions
This section somehow does not mention RFC 2308 section 7.1 which solves
most of the problem if implemented. In fact BIND has an implementation
of it and is not vulnerable to the TsuNAME attack (or at least I was not
able to reproduce it).
Yep, but 7.1 was unfortunately (for this case) optional, and a MAY.
But when we privately disclosed tsuname at OARC34, we tested only if
BIND and others would loop in the presence of a single client query.
They don't. That covers only one source of loop: resolvers looping.
But what happens when a client sends non-stop queries to the same
resolver? Does bind answer from cache (7.1 RFC2308) OR will trigger new
queries again? (we did not test for that, if you did, could you please
share the findings)?
This is an interesting question. In case of BIND there are two (or
three...) things which prevent it from generating queries to
authoritatives when queried repeatedly:
1] First stage is RFC 2308 section 7.1-style "SERVFAIL cache". It is by
default configured with a 1 second TTL ("servfail-ttl" option in
named.conf).
Identical queries which resulted in SERVFAIL are responded from this
cache without doing anything else.
Please note that this is an "output" cache, i.e. it stores SERVFAILs
generated by the resolver itself - which happens when query fails for a
number of reasons, including resource limits.
2] If the answer is not in SERVFAIL cache, the resolver starts
recursing, but naturally consults its RR cache for each step. While
processing the second query, the resolver will find delegations from the
authoritative servers in RR cache and use these instead of re-querying
servers again. I.e. no queries will be generated until TTL in RR cache
expires (or cache eviction kicks out delegation RRs for other reasons).
3] The third reason is a bug in older versions of BIND :-D A subtle bug
caused mishandling of queries with cyclic dependencies in delegations,
causing BIND to _delay_ responding with SERVFAIL by roughly 10 seconds
(an another internal timeout).
All two/three mechanism dampen amount of outgoing queries. Of course we
need to look at it with attacker's mindset and probe for holes in it,
but with this infrastructure in place I think it will not be much worse
than regular TTL=0 query/answer flood, and that's only possible if
attacker has control over delegation TTL (which is AFAIK not the case
for most TLDs).
Because if does not cache, clients recurrent queries would force the
resolver to send many queries to the authoritative servers, and it would
seem they'd be looping. See fig3(b) in [0], where we show that only
some of Google resolvers would be aggressive -- and those were the ones
that had these impatient clients.
That's the second root cause: clients/forwarders looping.
Sure, that boils down to generic problem "clients evading cache in
resolvers", which is always PITA. We should declare TTL=0 illegal :-)
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
On 09. 11. 21 18:57, Viktor Dukhovni wrote On 9 Nov 2021, at 4:11 am, Petr Špaček wrote: I don't see need to specify _a_ value here. I think better approach is acknowledge current state of things. What about something like this? --- As for November 2021, the limit of 150 iterations for treating answer as insecure is interoperable without significant problems, but at the same time it makes DoS attacks based on exhausting CPU resources three times cheaper when compared to 0 iterations. For this reason software vendors are expected to evaluate NSEC3 iteration counts seen in wild and lower their limits over time. --- What do you think about this approach? I have no objections to setting the limits to essentially zero, but would suggest: - Authoritative servers employing NSEC3 SHOULD set the (additional) iteration count to 0. Higher values may run into interoperability problems with validating resolvers and secondary servers. - Validating resolvers MAY over time reduce the maximum NSEC3 (additional) iteration count they support to as low as 1. NSEC3 iteration counts of 0 and 1 MUST continue to be supported. The reason I'd prefer that validators allow 1 as well as zero, is that: * We're then probably looking at just ~1% performance impact (extrapolated from the posted perf numbers) * It is I think not obvious to naive operators that 0 iterations really means 0 *additional* iterations, and the initial hashing step is still performed. Thus 1 is a fairly popular setting, and I'm inclined to require that it be tolerated in validators, even if we're telling auth zone operators to use 0. Agreed, 1 is probably what we will have to live with in spec for validators. All that said, after the RFC is done, we'll need to do another round of outreach to TLD zone aand customer domain hosting operators as well as independent self-hosting auth zone operators, this time to ask for a reduction to 0 (as opposed to 100 or less). I hope that won't be principally (or alone) up to me. +1 Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-moura-dnsop-negative-cache-loop
On 08. 11. 21 8:49, Giovane C. M. Moura wrote: Folks, Loops in DNS are an old problem, but as our tsuname[0,1] disclosure last May shows, they are still a problem. We wrote a new draft that adds a new requirement to existing solutions: recursive resolvers must detect and negative cache problematic (loop) records. It would be nice to hear what folks have to say. I generally support the direction, 22+ years after RFC 2308 was published it's time to have a look at it again. If I understand this correctly, TL;DR summary essentially is """ make https://datatracker.ietf.org/doc/html/rfc2308#section-7.1 mandatory """ (even though your version is a bit stronger). Is that correct? If it is the case, then the document needs to clearly update 2308 section 7.1 and go through standards track. Right now this might not be clear. Ad the draft content: 2. Past solutions This section somehow does not mention RFC 2308 section 7.1 which solves most of the problem if implemented. In fact BIND has an implementation of it and is not vulnerable to the TsuNAME attack (or at least I was not able to reproduce it). 3. Current Problem Nitpick: Maybe this should go to Appendix as there is no protocol description in here? 4. New requirement I think section 4 should not require full blown _loop_ detection, but any sort of limit should be good enough for compliance. I mean, implementing a loop detection algorithm in hot path might not be a good idea, mainly because most of the time it just wastes resources - compared to a simple resource limit like, say, number of delegation steps per query. To be clear: I don't think the resolver _has to_ stop resolution at the earliest moment it has data to potentially detect the cycle. If the cycle has length 2, it should be okay to allow the resolver to do 4,6,8,... steps before giving up. For compliance it should be good enough to stop within "a" reasonable limit (not necessarily specified by a number). An additional nitpick: I think section 4. New requirement sound avoid term "negative" caching. In my eyes it is a bit misleading because "negative" is typically used for different kinds of answers. I hope this early feedback helps a bit. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
On 08. 11. 21 14:41, Wes Hardaker wrote: Petr Špaček writes: Thanks for the detail notes Petr, very helpful. From my point of view the RFC does not need to stick to the value currently implemented in resolvers. Good point, and maybe the right phrasing I should have used should have been "what value would implementations refuse to switch to"? Well, the answer is the same: For validators it's a moving target. A high value which was "necessary" yesterday might not be needed today because a large hoster moved on. In part, I worry that code authors would object to having just changed something and refused to change again. It seems like reports are overcoming that problem though :-) [I'm not sure we're at zero yet...] Sure, but that's not the point. The value is ever-changing. As I see it, we can either: a) Specify _a_ value valid for November 2021 and produce a RFC with values not reliable beyond November 2021. b) Specify _the_ ultimate target which guarantees interoperability in future, and make it really clear in the text. I think the second option is much better, so let me try this approach. I'm proposing text along those lines: Addition for section 3.1. Best-practice for zone publishe Please note that any number of iterations larger than 0 carries risk of interoperability problems. Any zone using higher iterations counts is willingly signing up for problems. The reason for this is that DNSSEC responders and validators have to limit resource usage caused by excessive iteration values, and even very small numbers of iterations impose significant overhead, which motivates software vendors to drive the limit down to 0. - If we really wanted we could add an appendix with an illustrative table (with disclamer about being just ilustrative for one software version, point in time, hardware etc. etc.): | Iterations | QPS [% of 0 iterations QPS] | ||-| | 0 | 100 % | | 10 | 89 %| | 20 | 82 %| | 50 | 64 %| | 100| 47 %| | 150| 38 %| If we wanted a simpler example we could say something like "at the time of this writing, mere 10 iterations caused over 10 % QPS drop on two popular authoritative server implementations". (As a sanity check I just tested Knot DNS and the impact there is very similar to what we see in the table about for BIND.) Honestly I don't think it's necessary. As for 3.2. Recommendation for validating resolvers I don't see need to specify _a_ value here. I think better approach is acknowledge current state of things. What about something like this? --- As for November 2021, the limit of 150 iterations for treating answer as insecure is interoperable without significant problems, but at the same time it makes DoS attacks based on exhausting CPU resources three times cheaper when compared to 0 iterations. For this reason software vendors are expected to evaluate NSEC3 iteration counts seen in wild and lower their limits over time. --- What do you think about this approach? -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
On 08. 11. 21 9:34, Matthijs Mekking wrote:
I concur with Benno.
For Bind 9, there is no technical challenge to set the iteration cap at
a lower value.
We prefer the value to be as low as possible, because it adds no real
value at a real resource cost.
But we will likely not implement blindly a maximum that will cause lots
of operational problems.
TL;DR
I say we should go for 0 and acknowledge in the text we are not there yet.
A longer version, With Measurement Inside (tm):
From my point of view the RFC does not need to stick to the value
currently implemented in resolvers.
IMHO the technically "hard" part is implementing limits at all, and
understanding their impact. I would loudly object to publishing the text
before the mechanism have been implemented and tested in wild, but we
are now past this phase. I.e. we already now it is feasible to
implement, and that reasonably high values work well in practice.
The specific value is quite obviously a moving target, so I think it is
appropriate to acknowledge that in the text. I propose to say something
along those lines:
- resolvers use 150 iterations as insecure limit as of November 2021
- resolvers are expected to gradually lower the limit to 0 over time, so
don't do stupid things and use 0 right away
That's factually correct and also provides us with a stick to beat outliers.
To make this debate more informed, let's have a quick glance on real
performance impact of NSEC3 iterations.
This is measured against BIND 9.17.19 as an authoritative server. In all
cases the server was CPU-bound and we compare average QPS
| Iterations | QPS [% of 0 iterations QPS] |
||-|
| 0 | 100 % |
| 10 | 89 %|
| 20 | 82 %|
| 50 | 64 %|
| 100| 47 %|
| 150| 38 %|
That's means that even 100 iterations is a huge waste of resources,
where half of the QPS is sacrificed to mindless NSEC3 iterations.
So again, I say we should go for 0 and acknowledge in the text we are
not there yet.
--
Here is my crude test setup so people can reproduce it themselves,
possibly with different software:
* $ cat named.conf
zone "." {
type primary;
file "root.zone.signed";
};
* input zone: root zone SOA serial 2021012701
* keys:
dnssec-keygen -K . -a ECDSAP256SHA256 .
dnssec-keygen -K . -a ECDSAP256SHA256 -f KSK .
* signed with:
# example with no salt, 0 iterations
dnssec-signzone -u -3 - -H 0 -S -o . root.zone
* BIND started with:
named -g -c named.conf -n 1
* numbers below are from a far-from-perfect laptop setup, so some
instability is to be expected; here are some basic tweaks for Intel
hardware:
echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
cpupower frequency-set -g performance
cpupower frequency-set --min 2.4G --max 2.4G
* perf tested with:
yes 'blabla. A' | dnsperf -D -s localhost -l 20 -S 1
A crude measurement script is attached. To get raw numbers run:
fgrep -H 'per second' iter* | sed -e 's/:[^:]*nd:/:/'
More detailed results in a table:
| Iterations | Min - qps | Median - qps | Average - qps | Max - qps |
StDev - qps | stdev [% of avg] | % of 0 iterations qps avg |
||---|--|---|---|-|--|---|
| 0 | 19 910| 22 289 | 21 881| 22 937|
994 | 5 % | 100 % |
| 10 | 18 078| 19 333 | 19 367| 20 278|
843 | 4 % | 89 % |
| 20 | 16 947| 18 167 | 17 982| 18 289|
419 | 2 % | 82 % |
| 50 | 13 483| 14 225 | 14 021| 14 385|
395 | 3 % | 64 % |
| 100| 9 922 | 10 426 | 10 371| 10 573|
212 | 2 % | 47 % |
| 150| 7 962 | 8 315| 8 270 | 8 320 |
112 | 1 % | 38 % |
Now I can only hope the tables survive transit.
--
Petr Špaček @ ISC
measure.sh
Description: application/shellscript
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt
On 26. 10. 21 11:14, Vladimír Čunát wrote: Hello. DNS Error reporting SHOULD be done using DNS Query Name Minimization [RFC7816 <https://datatracker.ietf.org/doc/html/rfc7816>] to improve privacy. It's just a detail and "SHOULD" isn't strong, but I expect it might be worth elaborating here. The name used in the reporting query adds a few labels to the failing QNAME and the whole reporting agent domain, so together that's lots of labels, and expending a packet for *each* of those labels would seem quite wasteful. Perhaps we could agree on some boundary (e.g. around the "_er" label) under which minimization isn't recommended anymore, and put that as a suggestion into the text? We need to consider & document interaction between Query Name Minimization and NXDOMAIN processing as per RFC 8020. If minimization & RFC 8020 are on default then it might very easily happen that most of _er subtrees (which are presumably empty) will be cut out by cache and nothing will be sent out when an error is detected. All in all, I think the text should warn about this interaction instead of mandating query name minimization on/off. The reporting resolver MUST NOT report about queries and responses from an encrypted channel (such as DNS over TLS [RFC7858 <https://datatracker.ietf.org/doc/html/rfc7858>] and DNS over HTTPS [RFC8484 <https://datatracker.ietf.org/doc/html/rfc8484>]). I believe this needs some explanation at least (in the text, ideally). The failing query triggering the report is towards an authoritative server (i.e. unencrypted), and the reporting queries do not really carry more information. They may travel by a different path, but on the whole I can't see significant motivation for the paragraph, especially in "MUST NOT" form. I will use stronger language: This is under-specified to the point where it starts causing confusion. * Is the paragraph considering channel from stub to resolver? * From resolver to auth? * Both? * What to do with queries executed by resolver on its own (prefetch)? * What if multiple clients are waiting for the same query, using different channels? (query deduplication in the resolver) etc. I think this should go to Security Considerations section and be left for implementations to decide. MUST mandate is way too strong and does not accommodate implementation- and deployment- specific circumstances. This method MUST NOT be deployed by default on reporting resolvers and authoritative servers without requiring an explicit configuration element. I'm not so sure about forbidding this on resolvers so strongly, but certainly OK if the WG prefers it that way. (On auths it wouldn't make sense to enable by default; what agent?) If the error-reporting is meant really seriously, I'd rather improve the mechanism to never induce significant overhead and encourage enabling it by default on resolvers (at some point). To make the error-reporting work, you need noticeable commitment to deploy on both sides, because otherwise the perceived benefit from deploying might be quite low. On resolver side, I believe that it will be quite rare for operators to tweak such highly technical options[*]. So if this MUST be off by default, you at least need commitment from some significant operators - say, I'm not even sure if Quad9 by themselves would suffice to bootstrap this. I agree. Mandating "disabled by default" configuration on _resolvers_ sounds like a way to get to a working-but-never-deployed protocol. -- Petr Špaček @ ISC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Real world examples that contain DNSSEC secure `Wildcard Answer` or `Wildcard No Data`
On 22. 10. 21 4:34, Joey Deng wrote: Hello folks, On [RFC4035 3.1.3. Including NSEC RRs in a Response](https://datatracker.ietf.org/doc/html/rfc4035#section-3.1.3), it describes four different cases when NSEC records should be included in a response: 1. No Data 2. Name Error 3. Wildcard Answer 4. Wildcard No Data. I am trying to find real world examples to help me better understand the cases above, I found some examples for case 1 and case 2: 1. No Data ``` dig www.ietf.org.cdn.cloudflare.net. MX +dnssec +cdflag +tcp Beware, DNS responses from Cloudlare are not exactly "canonical" because Cloudflare is using so-called black-lies: https://blog.cloudflare.com/black-lies/ It is a valid approach, but not the thing you read about in the RFC 403x series. For responses "as usual" have a look at these answers: > 1. No Data isc.org WKS > 2. Name Error surelynonexistentname.isc.org A > 3. Wildcard Answer surelynonexistentname.blog.root.cz A > 4. Wildcard No Data. surelynonexistentname.blog.root.cz WKS Here is another another set of examples for NSEC3 (RFC 5155): > 1. No Data nic.cz WKS > 2. Name Error surelynonexistentname.nic.cz A > 3. Wildcard Answer surelynonexistentname.pages.nic.cz A > 4. Wildcard No Data. surelynonexistentname.pages.nic.cz WKS I hope it helps. -- Petr Špaček @ ISC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Genart last call review of draft-ietf-dnsop-dns-tcp-requirements-12
On 07. 09. 21 18:46, Wessels, Duane wrote: Dan, thanks for the review. Responses are inline. On Sep 1, 2021, at 3:12 AM, Dan Romascanu via Datatracker wrote: Minor issues: 1. In Section 4.1: DNS clients MAY also enable TFO when possible. Maybe I do not fully understand the intent here, but 'MAY ... when possible' sounds like a SHOULD to me. Originally this was "SHOULD ... when possible" (meaning when implemented/supported) but after conversations with tcpm this was changed to MAY. To avoid confusion with "when possible" I suggest we just drop it so it will just say "DNS clients MAY also enable TFO." 2.In Section 4.2 DNS server software SHOULD provide a configurable limit on the total number of established TCP connections. If the limit is reached, the application is expected to either close existing (idle) connections or refuse new connections. Operators SHOULD ensure the limit is configured appropriately for their particular situation. DNS server software MAY provide a configurable limit on the number of established connections per source IP address or subnet. This can be used to ensure that a single or small set of users cannot consume all TCP resources and deny service to other users. Operators SHOULD ensure this limit is configured appropriately, based on their number of diversity of users. The lack of recommendations about how these limits should be set would leave less experienced operators in the dark. There is not even a sentence like 'This document does not offer advice on particular values for such a limit' as for other parameters in the same section. From an operators point of view I would prefer a recommendation or one or more examples of how these limits can be set in real life cases. Other reviewers called this out as well so I have added some recommended values. For the limit on total number of connections: "Absent any other information, 150 is a reasonable value for this limit in most cases." I think this "150" value is fine for plain/unencrypted DNS-over-TCP because UDP is still the main transport, but IMHO it is not applicable to recursives offering DNS-over-TLS. Recursives with DoT should allow much more to avoid costly TCP handshakes and session resumption. It's perfectly possible to handle hundreds of thousands of DoT clients on one resolver (when configured appropriately, and yes, I did test this claim.) Maybe this could use a clarification that 150 is good advice only if you _don't_ have any "TCP-only" clients, like e.g. DoT stubs? Petr Špaček For the limit on connections per source address: "Absent any other information, 25 is a reasonable value for this limit in most cases." For the timeout on idle connections: "Absent any other information, 10 seconds is a reasonable value for this timeout in most cases." Nits/editorial comments: 1. Sections in the document that are obviously for informational pursposes should be clearly marked so (like 'This section is included for informational purposes only'). For example Section 2. Done. 2. In Section 3: Regarding the choice of limiting the resources a server devotes to queries, Section 6.1.3.2 in [RFC1123] also says: "A name server MAY limit the resources it devotes to TCP queries, but it SHOULD NOT refuse to service a TCP query just because it would have succeeded with UDP." This requirement is hereby updated: A name server MAY limit the resources it devotes to queries, but it MUST NOT refuse to service a query just because it would have succeeded with another transport protocol. Similar alignment of the old and new text is desirable. Even using the OLD / NEW format. Good point. Section 3 now looks like this: Section 6.1.3.2 in [RFC1123] is updated: All DNS resolvers and servers MUST support and service both UDP and TCP queries. o Authoritative servers MUST support and service all TCP queries so that they do not limit the size of responses to what fits in a single UDP packet. o Recursive servers (or forwarders) MUST support and service all TCP queries so that they do not prevent large responses from a TCP- capable server from reaching its TCP-capable clients. Furthermore, the requirement in Section 6.1.3.2 of [RFC1123] around limiting the resources a server devotes to queries is hereby updated: OLD: A name server MAY limit the resources it devotes to TCP queries, but it SHOULD NOT refuse to service a TCP query just because it would have succeeded with UDP. NEW: A name server MAY limit the resources it devotes to queries, but it MUST NOT refuse to service a query just because it would have succeeded with another transport protocol. FYI we are tracking this in github at https://github.
Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis
On 14. 07. 21 5:13, Brian Dickson wrote: On Tue, Jul 13, 2021 at 10:01 AM Viktor Dukhovni <mailto:ietf-d...@dukhovni.org>> wrote: > On 13 Jul 2021, at 6:22 am, Petr Špaček mailto:pspa...@isc.org>> wrote: > > As Viktor pointed out in https://mailarchive.ietf.org/arch/msg/dnsop/w7JBD4czpGKr46v-DlycGbOv9zs/ <https://mailarchive.ietf.org/arch/msg/dnsop/w7JBD4czpGKr46v-DlycGbOv9zs/> , it seems that this problem plagues roughly tens out of 150k domains he surveyed. I think this makes further discussion about _necessity_ of the workaround kind of moot. The plural of anecdotes is not data... unfortunately. So, I don't recall who presented it, where, or when, but it was some time in the last couple of years, maybe at an IETF or OARC meeting. But, the gist of the presentation was that the presenters studied query sources from a number of vantage points, over a period of years, and concluded there are approximately 3 million resolvers. Those resolvers are not all directly connected to the Internet, and some/many are configured as forwarders (with potentially multiple forwarders in chains/trees). The point here is, that Viktor represents one out of three million vantage points, which undoubtedly have different characteristics in terms of resolver software and version, and intermediate servers (e.g. forwarding to resolvers, or forwarding to forwarders). Additionally, Viktor's data set was TLSA, which is already a niche set that is self-selected to be on DNSSEC-signed zones, meaning relatively new and mainstream code bases (possibly over-generalizing admittedly.) Examining larger data sets on domains that are not DNSSEC-signed, may show a different prevalence of the ENT problem. The other distinction is that the problems leading to bad ENT results, may not be on the authoritative servers, but may be in front of them (close to the authoritatives), or may be other middle-boxes closer to the resolvers, or between forwarders and resolvers, etc. Thus the scope of the ENT problem may vary based on the vantage point being used to collect results. Thus, in the absence of any statistically meaningful data, I disagree with the mootness of the issue. That doesn't mean we can't reach consensus, of course, and given that this is a -bis document, and we are discussing how to handle the corner case of underscore ENTs, some focus should be given to the impact rather than the prevalence. This includes both the impact on code paths, and on the effects to client apps affected by ENT broken-ness. It may be helpful to note that the draft itself already differentiates behavior by the number of labels, in section 2.3 (in a MAY context) using the MAX_MINIMIZE_COUNT logic. Thus, if an implementation is already doing that work, adding underscore handling might not be a large burden (and might mesh nicely in terms of coding). For example, in evaluating the break-points when partitioning the labels to limit the total number of queries, the sequence COULD treat any contiguous sequence of underscore labels as if it were a single label, and then do its partitioning of labels using the same relative logic. The main point being, if the implementer is already doing anything other than literally iterating over all the labels one at a time, under all circumstances, then adding underscores into its handling isn't likely significantly burdensome. Maybe, or maybe not. We cannot know for sure until it's implemented in a real resolver. In my experience, major resolver implementations contain little but important details that make even seemingly simple tweaks way harder to implement than it looks on paper. Not having running code to support this proposal this late in publication process is IMHO another reason why it should stay at MAY level. Petr Špaček The difference between the many-labels problem and the underscore situation, is the difference between weakness against attacks and inefficiency (many labels), versus actual brokenness (for some indeterminate fraction of the namespace from some indeterminate portion of the resolvers on the Internet). I'm hoping to advance the discussion even if no one is persuaded. Brian Full disclosure, I only tested TLSA records. I can't speak to what one might expect with SRV or other record types. Yes, failures are not that common, for what is worth another example: https://dnsviz.net/d/_tcp.mail.ncsc.de/YO3DpQ/dnssec/ <https://dnsviz.net/d/_tcp.mail.ncsc.de/YO3DpQ/dnssec/> https://dnsviz.net/d/_25._tcp.mail.ncsc.de/YO3Bsw/dnssec/ <https://dnsviz.net/d/_25._tcp.mail.ncsc.de/YO3Bsw/dnssec/> Here the "A" query for the ENT was unexpectedly "REFUSED". :-( If implementations at least seriously consider the advice to treat special-use labels *specially*, I'll declare victory... -- Viktor.
Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis
On 13. 07. 21 0:13, Brian Dickson wrote:
On Mon, Jul 12, 2021 at 2:20 AM Petr Špaček <mailto:pspa...@isc.org>> wrote:
On 08. 07. 21 18:15, Brian Dickson wrote:
>
>
> On Thu, Jul 8, 2021 at 7:29 AM Petr Špaček mailto:pspa...@isc.org>
> <mailto:pspa...@isc.org <mailto:pspa...@isc.org>>> wrote:
>
> On 07. 07. 21 19:54, Warren Kumari wrote:
> > Hi there all,
> >
> > I wanted to check the consensus on a point brought up
during IETF
> LC /
> > OpsDir review of draft-ietf-dnsop-rfc7816bis.
> >
> > Please see:
> >
>
https://mailarchive.ietf.org/arch/msg/last-call/fuDyx2as6QsK8CT_7Nvci5d7XQQ/
<https://mailarchive.ietf.org/arch/msg/last-call/fuDyx2as6QsK8CT_7Nvci5d7XQQ/>
>
<https://mailarchive.ietf.org/arch/msg/last-call/fuDyx2as6QsK8CT_7Nvci5d7XQQ/ <https://mailarchive.ietf.org/arch/msg/last-call/fuDyx2as6QsK8CT_7Nvci5d7XQQ/>>
> > and
> >
>
https://mailarchive.ietf.org/arch/msg/dnsop/_H4aM5AquCSRlz0Pz3ncwl7Plpk/
<https://mailarchive.ietf.org/arch/msg/dnsop/_H4aM5AquCSRlz0Pz3ncwl7Plpk/>
>
<https://mailarchive.ietf.org/arch/msg/dnsop/_H4aM5AquCSRlz0Pz3ncwl7Plpk/ <https://mailarchive.ietf.org/arch/msg/dnsop/_H4aM5AquCSRlz0Pz3ncwl7Plpk/>>
> >
> > If resolving " _ldap._tcp.ad.example.com
<http://tcp.ad.example.com>
> <http://tcp.ad.example.com <http://tcp.ad.example.com>>",
once you hit the _tcp label
> > you are quite likely in ENT territory, and some
implementations
> > (especially those behind firewalls / middleboxes) are
still broken.
> > There is also a performance hit.
> >
> > Version 10 of the document added:
> > "Another potential, optional mechanism for limiting the
number of
> > queries is to assume that labels that begin with an
underscore (_)
> > character do not represent privacy-relevant administrative
> > boundaries. For example, if the QNAME is
> "_25._tcp.mail.example.org <http://tcp.mail.example.org>
<http://tcp.mail.example.org <http://tcp.mail.example.org>>"
> > and the algorithm has already searched for
"mail.example.org <http://mail.example.org>
> <http://mail.example.org <http://mail.example.org>>", the
> > next query can be for all the underscore-prefixed names
together,
> > namely "_25._tcp.mail.example.org
<http://tcp.mail.example.org> <http://tcp.mail.example.org
<http://tcp.mail.example.org>>"."
> >
> > (unsurprisingly the document does a much better job of
explaining the
> > issue than I did :-))
> >
> > Viktor is suggesting that QNAME Minimization should be
stopped when
> > you run into an underscore ("_") label, instead of this
being worded
> > as a potential, optional mechanism.
> >
> > Obviously there is a tradeoff here -- privacy vs deployment.
> > 1: while it's **possible** that there is a delegation
point at the
> > underscore label, (IMO) it is unlikely. If there is no
> delegation, you
> > will simply be coming back to the same server again and
again, and so
> > you are not leaking privacy sensitive information.
> >
> > 2: some recursives are less likely to enable QNAME
minimization
> > because of the non-zero ENT and slight performance issues.
> >
> > What does the WG think? Does the privacy win of getting
this deployed
> > and enabled sooner outweigh the potential small leak if
there *is* a
> > delegation inside the _ territory of the name?
> >
> > Should the advice above be strengthened to SHOULD /
RECOMMENDED?
>
> With my implementer hat on, I say "no", I don't see a
compelling reason
> to "mandate" it.
>
>
> Did you actually read what Viktor wrote?
Of course, I did, and I'm not too fond of the tone you used above.
Let's
skip to the constructive part, please.
Let me start by apologizing to you (and the group) for the tone (whether
intended or not).
(I was literally inquiring as opposed to intending to having tone.)
Re: [DNSOP] [Ext] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis
On 13. 07. 21 0:28, Warren Kumari wrote: On Mon, Jul 12, 2021 at 6:18 PM Viktor Dukhovni wrote: [ Resending complete message, previous draft was incomplete... ] On 12 Jul 2021, at 11:18 am, Paul Hoffman wrote: The current text is sufficient to tell resolver developers, and resolver operators, why they should even think about underscore labels when they create a QNAME minimisation strategy. Elevating such a strategy to a SHOULD as a work-around for broken middleboxes that might (hopefully!) be fixed in the future seems like a very wrong direction for the WG. If this were just a work-around for breakage, I'd be more inclined to agree, but it is also a solid opportunity to improve performance, because privacy-relevant changes of administrative control across special-use labels should be very rare to non-existent. I hear you Viktor, but I fail to see why performance optimization cannot be optional. Why this specific optimization is so important that it cannot be left to vendors to decide? So short-circuiting qname minimisation when a special-use label is encountered seems like a win-win. Measuring qname minimisation for TLSA RRs I see that today breakage of qname minimisation is rare. An example is: https://dnsviz.net/d/_tcp.u24.altospam.com/YOx4nQ/dnssec/ https://dnsviz.net/d/_25._tcp.u24.altospam.com/YOx4IA/dnssec/ In which many (but not all) of the nameservers return NXDOMAIN for the ENT. Out of 150k RRsets, O(10) have ENT-related issues. So one might reasonably neglect the breakage, but it is not clear that we need to go looking for it, just to "punish" the operators in question. There's an opportunity here to make qname minimisation more performant for SRV, TLSA, ... lookups, speeding up Domain Control and LDAP server lookups, email delivery, ... Please note I do not object to the method by itself - I agree it might be useful. My disagreement is limited to using stronger requirement than MAY. Let vendors have some leeway, please. Petr Špaček Of course if the WG cannot come to consensus on "SHOULD"/"RECOMMENDED", I'll gratefully settle for the current "MAY" (thanks for the document update)... Another option would be to keep the current text, and simply add another sentence describing why implementations may want to do this; the current paragraph starts off with: " Another potential, optional mechanism for limiting the number of queries is to assume that labels that begin with an underscore (_) character do not represent privacy-relevant administrative boundaries." - the context around this is mainly around limiting the many labels attack, but it could also mention the ENT / other performance gain. Whatever the case, this conversation is still ongoing, so I'd like to keep it open for a few more days... W ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis
On 12. 07. 21 17:18, Paul Hoffman wrote: The current text is sufficient to tell resolver developers, and resolver operators, why they should even think about underscore labels when they create a QNAME minimisation strategy. Elevating such a strategy to a SHOULD as a work-around for broken middleboxes that might (hopefully!) be fixed in the future seems like a very wrong direction for the WG. Oh, thank you for summarizing my thoughts into concise yet easier to understand message! -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis
On 08. 07. 21 18:00, Viktor Dukhovni wrote: On 8 Jul 2021, at 10:28 am, Petr Špaček wrote: With my implementer hat on, I say "no", I don't see a compelling reason to "mandate" it. Keep it at MAY/optional level and leave it to implementers to decide what's best for their implementation and use-cases. Just wanted to check what you mean by *mandate*, I don't quite see RECOMMENDED as a mandate, my understanding is that SHOULD/RECOMMENDED means "do this unless you have good reason to do otherwise". So there is certainly enough rope to ignore the advice. How would you strongly suggest that stopping qname minimisation at the first special-use label is probably a good idea, more strongly than just mentioning as a possible optional optimisation? When I look at RFC 2119 ... 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. ... 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) I think MAY describes exactly what workarounds are: A completely optional hack which _nobody_ can rely on. When I read definitions SHOULD and MAY together, I believe the text implies problems caused by ignoring SHOULD lie on the party which choose to ignore that particular instance of SHOULD: IMHO this is very wrong when describing workarounds. Workarounds are temporary "crutches for broken implementations", and anything stronger than MAY is just wrong. As a resolver implementer, I do not want to get into a position when a broken auth vendor uses the SHOULD requirement in RFC as an argument to keep their auth-brokenness because "resolvers SHOULD implement the workaround!" -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis
On 08. 07. 21 18:15, Brian Dickson wrote:
On Thu, Jul 8, 2021 at 7:29 AM Petr Špaček <mailto:pspa...@isc.org>> wrote:
On 07. 07. 21 19:54, Warren Kumari wrote:
> Hi there all,
>
> I wanted to check the consensus on a point brought up during IETF
LC /
> OpsDir review of draft-ietf-dnsop-rfc7816bis.
>
> Please see:
>
https://mailarchive.ietf.org/arch/msg/last-call/fuDyx2as6QsK8CT_7Nvci5d7XQQ/
<https://mailarchive.ietf.org/arch/msg/last-call/fuDyx2as6QsK8CT_7Nvci5d7XQQ/>
> and
>
https://mailarchive.ietf.org/arch/msg/dnsop/_H4aM5AquCSRlz0Pz3ncwl7Plpk/
<https://mailarchive.ietf.org/arch/msg/dnsop/_H4aM5AquCSRlz0Pz3ncwl7Plpk/>
>
> If resolving " _ldap._tcp.ad.example.com
<http://tcp.ad.example.com>", once you hit the _tcp label
> you are quite likely in ENT territory, and some implementations
> (especially those behind firewalls / middleboxes) are still broken.
> There is also a performance hit.
>
> Version 10 of the document added:
> "Another potential, optional mechanism for limiting the number of
> queries is to assume that labels that begin with an underscore (_)
> character do not represent privacy-relevant administrative
> boundaries. For example, if the QNAME is
"_25._tcp.mail.example.org <http://tcp.mail.example.org>"
> and the algorithm has already searched for "mail.example.org
<http://mail.example.org>", the
> next query can be for all the underscore-prefixed names together,
> namely "_25._tcp.mail.example.org <http://tcp.mail.example.org>"."
>
> (unsurprisingly the document does a much better job of explaining the
> issue than I did :-))
>
> Viktor is suggesting that QNAME Minimization should be stopped when
> you run into an underscore ("_") label, instead of this being worded
> as a potential, optional mechanism.
>
> Obviously there is a tradeoff here -- privacy vs deployment.
> 1: while it's **possible** that there is a delegation point at the
> underscore label, (IMO) it is unlikely. If there is no
delegation, you
> will simply be coming back to the same server again and again, and so
> you are not leaking privacy sensitive information.
>
> 2: some recursives are less likely to enable QNAME minimization
> because of the non-zero ENT and slight performance issues.
>
> What does the WG think? Does the privacy win of getting this deployed
> and enabled sooner outweigh the potential small leak if there *is* a
> delegation inside the _ territory of the name?
>
> Should the advice above be strengthened to SHOULD / RECOMMENDED?
With my implementer hat on, I say "no", I don't see a compelling reason
to "mandate" it.
Did you actually read what Viktor wrote?
Of course, I did, and I'm not too fond of the tone you used above. Let's
skip to the constructive part, please.
> It is a known fact that there ARE implementations where ENT handling (on
> the authoritative side) are broken.
I agree that there are some, but anecdotal evidence of existence tells
us nothing about
a) prevalence
b) significance of these broken auths and domains hosted on them.
AFAIK both of these are parameters taken into account by resolver
vendors when deciding what types of non-compliance need to be worked around.
I'm arguing against mandating workarounds. The recommendation might be
sound in 2021, but that's not a good enough reason for me to mandate it
as it might change next month when one major player fixes its deployment.
Historical context:
Based on experience with Knot Resolver, various workarounds present in
older resolver implementations were not "needed" by the time Knot
Resolver came about. Multiple types of formerly-prevalent protocol
non-compliance became so marginal that it was not worth the complexity
to implement and maintain workarounds for them anymore.
> Given that the vast majority of the first underscore queries would be
> hitting ENTs, this would seem to me, at least, to be compelling.
>
> Why would you not strongly suggest to other implementers to avoid this
> problem (by stopping the QNAME minimization)?
When you reach this line, I think it should be clear that I consider
this a wrong question. We should be asking why RFC should mandate a
workaround that might get obsolete in an inestimable amount of time.
Need for workarounds changes, and for this reason I don't consider RFCs
to be a good place to _mandate_ workarounds which are by definition
dependent on current (and constantly changing) situation. (To be
Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis
On 07. 07. 21 19:54, Warren Kumari wrote:
Hi there all,
I wanted to check the consensus on a point brought up during IETF LC /
OpsDir review of draft-ietf-dnsop-rfc7816bis.
Please see:
https://mailarchive.ietf.org/arch/msg/last-call/fuDyx2as6QsK8CT_7Nvci5d7XQQ/
and
https://mailarchive.ietf.org/arch/msg/dnsop/_H4aM5AquCSRlz0Pz3ncwl7Plpk/
If resolving " _ldap._tcp.ad.example.com", once you hit the _tcp label
you are quite likely in ENT territory, and some implementations
(especially those behind firewalls / middleboxes) are still broken.
There is also a performance hit.
Version 10 of the document added:
"Another potential, optional mechanism for limiting the number of
queries is to assume that labels that begin with an underscore (_)
character do not represent privacy-relevant administrative
boundaries. For example, if the QNAME is "_25._tcp.mail.example.org"
and the algorithm has already searched for "mail.example.org", the
next query can be for all the underscore-prefixed names together,
namely "_25._tcp.mail.example.org"."
(unsurprisingly the document does a much better job of explaining the
issue than I did :-))
Viktor is suggesting that QNAME Minimization should be stopped when
you run into an underscore ("_") label, instead of this being worded
as a potential, optional mechanism.
Obviously there is a tradeoff here -- privacy vs deployment.
1: while it's **possible** that there is a delegation point at the
underscore label, (IMO) it is unlikely. If there is no delegation, you
will simply be coming back to the same server again and again, and so
you are not leaking privacy sensitive information.
2: some recursives are less likely to enable QNAME minimization
because of the non-zero ENT and slight performance issues.
What does the WG think? Does the privacy win of getting this deployed
and enabled sooner outweigh the potential small leak if there *is* a
delegation inside the _ territory of the name?
Should the advice above be strengthened to SHOULD / RECOMMENDED?
With my implementer hat on, I say "no", I don't see a compelling reason
to "mandate" it. Keep it at MAY/optional level and leave it to
implementers to decide what's best for their implementation and use-cases.
Thanks.
Petr Spacek @ ISC
This is after IETF LC, but as the question was raised during LC, I
think it needs to be discussed and addressed.
I'd like a **clear** input, on this question only, by Tuesday August 13th.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
On 27. 01. 20 16:08, Hugo Salgado wrote: Dear DNSOPers, as an operator I tend to have this need to couple an answer for a query to an auth server, with the actual "SOA zone version" used. So I think it'll be valuable to have an EDNS option for it. Here I'm proposing it with this new draft. The 'camel index' for its implementation/hack/proof-of-concept is about 37 lines in NSD 4.1 (more details in Appendix A). I've asked some operators and they see value on it. Is there any support for adoption in DNSOP? - Name: draft-salgado-rrserial Revision: 01 ... This "RRSERIAL" data allows to debug problems and diagnosis by helping to recognize the origin of an answer, associating this answer with a respective zone version. I think it needs more thought. Here's why: Extending TTLs == First, people in this thread have floated ideas about using SOA serial for extending TTLs. I think it's a bad idea because: a) It would be pretty complex to implement right. b) There are no guarantees that the SOA serial did not overflow in the meanwhile. As an extreme example, auth server can legally increment SOA value by 2^29 for each update, thus rolling SOA serial over very frequently. Debugging = Secondly, let's consider just the "debugging" use-case, which removes the requirement to make the proposed mechanism 100 % reliable: In practice, this RRSERIAL option is a specialized way to conflate two queries into one: - First query specified by the standard (qclass, qtype, qname) - Second query with hardcoded qtype=SOA, qclass derived from the primary qclass in question section, and SOA name derived from qname in the question section. To me, this sounds like a crude hack, and I think the proper solution should be a real multi-query option, which incidentally provides a superset of RRSERIAL capabilities. A multi-query option would also work multi-master architectures that cannot rely on SOA serial but on some other (presumably queriable) information. Epilogue Generally, I think SOA serial design was fine in 1985 but is ill-fitted for 2021. (I have to admit I'm biased because I'm implemented multi-master auth in topologies with tens of DNS servers, all accepting dynamic updates at the same time.) For this reason, I think the DNS protocol should be gradually getting rid of the dependency on SOA serial, not increasing it. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
On 21. 04. 21 19:00, Ben Schwartz wrote: On Wed, Apr 21, 2021 at 12:44 PM Wellington, Brian <mailto:40akamai@dmarc.ietf.org>> wrote: I’m not a fan of the new text in section 4.3: Recursive resolvers MUST be able to convey SVCB records with unrecognized SvcParamKeys or malformed SvcParamValues. It is perfectly reasonable for a recursive resolver to reject any malformed DNS record. There’s a significant difference between “malformed” and “unknown”. A recursive resolver should definitely allow records with unknown SvcParamKeys, but if the format of a record is known, a resolver should be allowed (encouraged, in fact) to check that it conforms to that format. The concern here was about differing interpretations of future standards. For example, if some SvcParamValue is defined as a URL (for some future key), implementations are likely to disagree about whether certain bytestrings are valid URLs. (There are several definitions and a zillion edge cases.) The resolver has no use for these values, so the most compatible behavior is to treat them as opaque bytestrings. We very deliberately chose the phrase "MUST be able to convey" to recognize that resolvers might be configured not to convey a record with a malformed value, but it should be possible. Do you think we should change this sentence? I can see the same ambiguity as Brian. What about this text as replacement? --- Recursive resolvers MUST be able to convey SVCB records with unrecognized SvcParamKeys if they conform to RDATA wire format (section 2.2). --- What I mean: Resolvers must be able to handle _unknown_ SvcParams as opaque byte strings. Various resolvers will do some sort of filtering on individual params, but such filtering is "local policy" and nothing we write into the RFC can change local policy anyway. For that reason I would not go to great lengths to explain what to do with unrecognized URLs etc. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-svcb-https
On 08. 04. 21 16:39, Ben Schwartz wrote:
Thanks for the feedback, Petr. I think the easiest solution is to relax
the requirement language. I've proposed a change here:
https://github.com/MikeBishop/dns-alt-svc/pull/313
<https://github.com/MikeBishop/dns-alt-svc/pull/313>
Copying the diff here:
- Recursive resolvers SHOULD treat the SvcParams portion of the SVCB RR
- as opaque and SHOULD NOT try to alter their behavior based
- on its contents.
+ Recursive resolvers MAY treat the SvcParams portion of the SVCB RR
+ as opaque. No part of this specification requires recursive resolvers
+ to alter their behavior based on its contents, even if the contents are
+ invalid.
This addresses my concern, thank you!
Petr Špaček
On Thu, Apr 8, 2021 at 3:55 AM Petr Špaček <mailto:pspa...@isc.org>> wrote:
On 18. 03. 21 21:53, Tim Wicinski wrote:
>
> This starts a Working Group Last Call for draft-ietf-dnsop-svcb-https
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
<https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/>
> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
<https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/>>
>
> The Current Intended Status of this document is: Proposed Standard
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please
> speak out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends
on: 2
> April 2021
I realize I'm already late, but I think this is worth raising with
the WG:
Version -04 contains this:
4.3. General requirements
Recursive resolvers SHOULD treat the SvcParams portion of the
SVCB RR
as opaque and SHOULD NOT try to alter their behavior based on its
contents.
When responding to a query that includes the DNSSEC OK bit
([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers
MUST accompany each RRSet in the Additional section with the same
DNSSEC-related records that they would send when providing that
RRSet
as an Answer (e.g. RRSIG, NSEC, NSEC3).
The catch is that this "SHOULD NOT ... alter behavior" goes against RPZ
and any other filtering technique employed by the resolver.
As a specific example, operators are already asking resolver vendors to
treat ipv4hint and ipv6hint the same way as A/ for purposes of the
"Response IP Address" Trigger in the context of RPZ filters.
(https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-rpz-00#section-4.3
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-rpz-00#section-4.3>)
Does WG want to say anything in the HTTPS draft or leave it to the
imagination of vendors?
In my eyes, 4.3 "SHOULD NOT ... alter behavior" is unnecessary for
interoperability, so I think clarification is needed to make it clear
that local policy on resolver overrides "SHOULD NOT alter" instruction
in section 4.3. General requirements _if_ resolver operator deems
necessary.
Let me be clear:
It would not be very reasonable to believe that HTTPS RR will be in
practice allowed to work as a loophole to A/ filtering on
resolvers,
so the question is if WG prefers to have it mentioned in the RFC
text or
not.
--
Petr Špaček
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-svcb-https
On 18. 03. 21 21:53, Tim Wicinski wrote: This starts a Working Group Last Call for draft-ietf-dnsop-svcb-https Current versions of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/> The Current Intended Status of this document is: Proposed Standard Please review the draft and offer relevant comments. If this does not seem appropriate please speak out. If someone feels the document is *not* ready for publication, please speak out with your reasons. This starts a two week Working Group Last Call process, and ends on: 2 April 2021 I realize I'm already late, but I think this is worth raising with the WG: Version -04 contains this: 4.3. General requirements Recursive resolvers SHOULD treat the SvcParams portion of the SVCB RR as opaque and SHOULD NOT try to alter their behavior based on its contents. When responding to a query that includes the DNSSEC OK bit ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers MUST accompany each RRSet in the Additional section with the same DNSSEC-related records that they would send when providing that RRSet as an Answer (e.g. RRSIG, NSEC, NSEC3). The catch is that this "SHOULD NOT ... alter behavior" goes against RPZ and any other filtering technique employed by the resolver. As a specific example, operators are already asking resolver vendors to treat ipv4hint and ipv6hint the same way as A/ for purposes of the "Response IP Address" Trigger in the context of RPZ filters. (https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-rpz-00#section-4.3) Does WG want to say anything in the HTTPS draft or leave it to the imagination of vendors? In my eyes, 4.3 "SHOULD NOT ... alter behavior" is unnecessary for interoperability, so I think clarification is needed to make it clear that local policy on resolver overrides "SHOULD NOT alter" instruction in section 4.3. General requirements _if_ resolver operator deems necessary. Let me be clear: It would not be very reasonable to believe that HTTPS RR will be in practice allowed to work as a loophole to A/ filtering on resolvers, so the question is if WG prefers to have it mentioned in the RFC text or not. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS Error Reporting
On 12. 03. 21 4:47, Brian Dickson wrote: On Fri, Oct 30, 2020 at 10:03 AM Roy Arends <mailto:r...@dnss.ec>> wrote: Dear DNS Operations folk, Matt Larson and I wrote up a method that warns a domain owner of an issue with their configuration. The idea is loosely based on DMARC (RFC7489), and on Trust Anchor signalling (RFC8145). The method involves an EDNS0 exchange, containing an “agent” domain, send by the authoritative server that the resolver can send reports to in case of a failure. Please see https://tools.ietf.org/html/draft-arends-dns-error-reporting-00 <https://tools.ietf.org/html/draft-arends-dns-error-reporting-00> I have a few comments (some were made in the jabber room at IETF-110), mostly suggestions. First, what about a "sampling" field, treated as 1/N for a field value of N. Do rand(N), and report only if you get a value of 0. A value of N=1 would always succeed (not sampled), and a value of N=0 is "don't send a report". No such field is needed, this can be done on auth side already. Auth side can already decide with single-answer granularity when to send the option, i.e. the sampling can be simply done by not/sending the option. (Keep in mind the option is not cached.) For example auth can send the option only on 1/100 of DNSKEY queries and nothing else (if desired). Or for 1/100 000 of all queries. Doing so on auth side is much more flexible and does not complicate the prototol so I do not think complexity is justified. Second, what about a "fire drill" field, which is applied with a similar 1/N logic, but triggers a report even if no error occurs. This would be useful for testing the reporting functionality without requiring deliberate errors be introduced. I feel the complexity (also in security analysis ...) is unwarranted. What use-case do you envision? Third, what about actually sending a response to the "report" query? If noerror, nodata, the reporting agent does nothing. However, if some particular response is received, use that in processing future errors. The idea is to have some value returned, with a TTL used for how long to ignore errors, or that specific error. (Maybe use logic similar to the class and type fields from UPDATE?) That way, if the authoritative server has a problem that can't or won't be fixed for some duration, it can suppress reports until that error is fixed. That's already part of the draft. The signaling query is normal (albeit asynchronous to the triggering query) so normal TTL rules for answers apply. The receiving side is expected to send back normal DNS answer and can freely use whatever SOA/TTL/whatever it desires. Finally, what about an optional field for resolver operator contact info (e.g. vCard or similar), so the authority operator can follow up with a human if appropriate? Interesting idea, but it leads to packet bloat caused by data which are unnecesary vast majority of the time. Are we (as dnsop WG) not concerned with packet bloat anymore? -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC Strict Mode
On 23. 02. 21 16:08, Ben Schwartz wrote: Inspired by some recent discussions here (and at DNS-OARC), and hastened by the draft cut-off, I present for your consideration "DNSSEC Strict Mode": https://datatracker.ietf.org/doc/html/draft-schwartz-dnsop-dnssec-strict-mode-00 <https://datatracker.ietf.org/doc/html/draft-schwartz-dnsop-dnssec-strict-mode-00> Abstract: Currently, the DNSSEC security of a zone is limited by the strength of its weakest signature algorithm. DNSSEC Strict Mode makes zones as secure as their strongest algorithm instead. The draft has a long discussion about why and how, but the core normative text is just three sentences: The DNSSEC Strict Mode flag appears in bit $N of the DNSKEY flags field. If this flag is set, all records in the zone MUST be signed correctly under this key's specified Algorithm. A validator that receives a Strict Mode DNSKEY with a supported Algorithm SHOULD reject as Bogus any RRSet that lacks a valid RRSIG with this Algorithm. Hi Ben, I would appreciate more information about threat model you work with. This Abstract Currently, the DNSSEC security of a zone is limited by the strength of its weakest signature algorithm. DNSSEC Strict Mode makes zones as secure as their strongest algorithm instead. is IMHO gravely imprecise: DNSSEC security is as strong as weakest link in (any permissible) chain of trust. In other words, if my parent TLD has 1024 bit RSA and my "secure" zone has 1024 bit RSA + a fancy ECC alg with the new bit set, it still means nothing security-wise. Attacker can get better return on investment by attacking the parent zone. I think it needs discussion if it is worth approaching this problem with single-zone granularity. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
Hello, I'm going to generalize Ben's questions: It is hard to see what benefits draft-ietf-dnsop-delegation-only brings without having description of "DNSSEC Trasparency" mechanism available. Please describe intended usage of the proposed mechanism, at the moment it is hard to see all the details and interactions. Petr Špaček @ CZ.NIC On 29. 07. 20 21:54, Ben Schwartz wrote: > I'm generally supportive of draft-ietf-dnsop-delegation-only, but I want to > make sure that the draft isn't overstating the achievable benefits. To that > end, I have some questions about the text of the -01 draft. > > (I recognize that these are issues I've raised before, but I still haven't > gotten answers that I understand.) > > Assuming the claims are correct, I think they need some clarifications for > naive readers like myself (and possibly deduplication, since some claims are > repeated in different sections). > >> Exposing such targeted attacks requires a transparency audit >> infrastructure similar to what is deployed for PKIX ([RFC6962]). >> However, a DNSSEC version would need to log significantly more data, >> as all signed DNS data used by a DNSKEY must be recorded in order to >> prove that data signed by a parent zone's DNSKEY was out of expected >> policy. The very distributed nature of the DNS combined with the >> typically frequent zone resigning rate makes such transparency logs >> prohibitively expensive and nearly impossible to operate. > > How does this draft alter that cost? For delegation-only zones that are in > compliance, it seems like the cost is not changed. Presumably violations > will be rare, so they won't contribute significantly to the cost. > >> Additionally, it would require zone owners to expose all their zone >> data to any public log operators, thereby introducing privacy >> implications and exposing all relevant DNS data to a public archive. > > I don't understand how this flag would alter that exposure. If my zone is > already delegation-only, how does adding this flag improve privacy? > >> At the time of this writing, the list of entries in the >> public suffix list contains over 8800 entries as well, with 73 wild- >> card entries (prefixed with a "*") indicating that all of their >> (unknown number of) children are public registration points. In the >> absence of an interoperable mechanism (like this draft provides), it >> is infeasible that a validating resolver or auditing log could know >> which of these zones are delegation-only without individual policy >> statements from each of them. > > Marking a zone delegation-only doesn't imply that it is suitable for logging, > so wouldn't participation in any logging scheme require an individual policy > statement anyway? > >> Finally, a DELEGATION_ONLY flagged DNSKEY for >> the root zone cannot be overridden easily, as it would require a >> trust anchor update in all validating resolvers. > > The preceding sentences deal with the lingering "false child key" problem, > which still applies here, so I don't understand the relevance of this > sentence. > > I also had some thoughts on the Security Considerations: > >> Care should be taken by resolvers to not >> unnecessarily empty their cache. This is specifically important for >> roaming clients that re-connect frequently to different wireless or >> mobile data networks. > > I believe this advice is counter to best practices for mobile clients for > both performance and privacy reasons. See e.g. http://dnscookie.com/. > > Also, I think it's worth mentioning that "delegation-only" zones can still > deny the existence of a DS for the child (if the child was signed to begin > with), and then generate deep unsigned records for the child. This limits > the direct impact of this flag to cases where DNSSEC is mandatory. (Logging > might be able to deter this attack, assuming NSEC records are logged.) > > Thanks, > Ben Schwartz ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS
On 23. 07. 20 3:41, Ben Schwartz wrote: > On Wed, Jul 22, 2020 at 9:20 PM Wellington, Brian > mailto:40akamai@dmarc.ietf.org>> > wrote: > > ok. So, what this means is that keys listed in the “mandatory” parameter > must be included as parameters, and are required to be understood by clients. > The set of “automatically mandatory” keys are required to be understood by > clients, but are not required in the RR. > > > From the client's perspective, "mandatory" means "if you don't understand all > of these keys, discard the RR". Each key on the list is "mandatory" in the > sense that it conveys information that is required to make correct use of the > RR. All other keys are optional: they can be ignored and the RR will still > "work" for connection establishment. > > "Automatically mandatory" means "this key is mandatory if it is present". > > If you can think of a clearer presentation, please send text! I'm not native English speaker and I personally find confusing that sequence of characters "mandatory" is used as verb and also as name of the key. "optional mandatory" sounds like a joke. To clarify this I propose to rename "mandatory" field to "critical", which terminologically aligns with X.509 and also LDAP. -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
On 16. 06. 20 13:00, Petr Špaček wrote: > On 12. 06. 20 17:12, Tim Wicinski wrote: >> >> All, >> >> As we stated in the meeting and in our chairs actions, we're going to run >> regular calls for adoptions over the next few months. We are looking for >> *explicit* support for adoption. >> >> >> This starts a Call for Adoption for draft-arends-private-use-tld >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-arends-private-use-tld/ >> >> Please review this draft to see if you think it is suitable for adoption by >> DNSOP, and comments to the list, clearly stating your view. >> >> Please also indicate if you are willing to contribute text, review, etc. >> >> This call for adoption ends: 26 June 2020 > > I support adoption but share opinion that the document should not be > published as is. > > Rationale: > - People are going to squat on global DNS no matter what IETF does. > - This document is an opportunity to: > a) Say "squating is a bad idea, see RFC 8244 and think it through" before you > decide to squat. > b) Highlight _already reserved_ (by ISO) TLD strings for people who ignored > warning in point [a] above. > c) I believe that side-effect of getting people _who insist on private TLD > anyway_ one of 40-something strings instead of "pick your > not-really-random-TLD" can lead to decrassing traffic to root and easier > monitoring in practice as caching should work better (either with query name > minimization or aggressive use of cache). An off-list reply indicates that I was not clear so I'll attempt to clarify my previous message. In my mind the document should say: 1. _If possible_ use a subdomain you own, it will save you headache later on (e.g. when you decide to set up VPN to your supplier, but I do not insist on this specific example). 2. If you think you need non-unique private subtree read list of problems listed in ... [link to some other document] and think again. 3. Never ever squat 4. If this document did not change you mind use one of /zz/ To me it seems that most dnsop people (me included) do not want to legitimize use unnecessary use of private names as it often causes unnecessary pain down the road - but at the same time I personally recognize the motivation for home.arpa. etc. In general I want discourage from using private namespaces _unless absolutely necessary_, and this document has potential to make this a conscious choice instead of just picking "lan" without thinking about long-term consequences. -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
On 12. 06. 20 17:12, Tim Wicinski wrote: > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular calls for adoptions over the next few months. We are looking for > *explicit* support for adoption. > > > This starts a Call for Adoption for draft-arends-private-use-tld > > The draft is available here: > https://datatracker.ietf.org/doc/draft-arends-private-use-tld/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 26 June 2020 I support adoption but share opinion that the document should not be published as is. Rationale: - People are going to squat on global DNS no matter what IETF does. - This document is an opportunity to: a) Say "squating is a bad idea, see RFC 8244 and think it through" before you decide to squat. b) Highlight _already reserved_ (by ISO) TLD strings for people who ignored warning in point [a] above. c) I believe that side-effect of getting people _who insist on private TLD anyway_ one of 40-something strings instead of "pick your not-really-random-TLD" can lead to decrassing traffic to root and easier monitoring in practice as caching should work better (either with query name minimization or aggressive use of cache). -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] questions about Signaling Cryptographic Algorithm Understanding (RFC 6975)
Hi dnsop, it seems that OpenDNS is the first to implement RFC 6975: https://lists.dns-oarc.net/pipermail/dns-operations/2020-June/020219.html This reminded me of its existence so I looked at definition for validating recursors: 4.2.1. Validating Recursive Resolvers A validating recursive resolver sets the DAU, DHU, and/or N3U option(s) when performing recursion based on its list of algorithms and any DAU, DHU, and/or N3U option lists in the stub client query. When the recursive server receives a query with one or more of the options set, the recursive server MUST set the algorithm list for any outgoing iterative queries for that resolution chain to a union of the stub client's list and the validating recursive resolver's list. For example, if the recursive resolver's algorithm list for the DAU option is (3, 5, 7) and the stub's algorithm list is (7, 8), the final DAU algorithm list would be (3, 5, 7, 8). If the client included the DO and Checking Disabled (CD) bits, but did not include the DAU, DHU, and/or N3U option(s) in the query, the validating recursive resolver MAY include the option(s) with its own list in full. If one or more of the options are missing, the validating recursive resolver MAY include the missing options with its own list in full. What is your opinion on: a) Sending RFC 6975 EDNS options with queries which target zone cuts which are not signed (DS provably not present in parent)? That sounds like waste of bytes, but maybe it is not worth optimizing. Opinions? b) It is not clear if/how authors took into account deduplication of queries: the recursive server MUST set the algorithm list for any outgoing iterative queries for that resolution chain to a union of the stub client's list and the validating recursive resolver's list. Multiple queries from stubs can translate to a single upstream query. Typically this happens for very frequently asked names on cache miss event. E.g. many stubs ask "www.google.com " but recursor can optimize traffic upstream and send only single query to auth. Of course stub queries will likely not arrive simultaneously so the first query to auth (possibly with union of algo sets) is already in flight when second stub query (possibly with diffent set) arrives. Now what? (Section 7. Traffic Analysis Considerations shifts the problem to oneone else, but I think deduplication trick + interaction with DNS cache should be pointed out because it significantly complicates analysis.) c) Is union of sets even a good idea? Why not copy ENDS options from stub and append _another_ "instance" of options so the auth can see there are multiple parties with different set of options? d) Is there a risk of inflating queries too much/new attack vector? What about stub sending EDNS option with all alg fields present (700+ bytes)? Should there be a limit on number of algs? (I cannot see any in the RFC.) e) What should happen if multiple options are present? Answer with FORMERR? (But see questions c,d above.) Thank you for opinions! P.S. Sorry for opening this topic again, but this seems like another example of RFC which would benefit from more implementation experience prior publication. -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses)
reasonably quickly in > parallel. Then again, if it's something like requesting an extra qtype that > we would be afraid to send in Classic DNS anyway (due to the ossification > issues), eg HTTPSVC, I suppose there's more value of just adding in the > additional qtype and using the response opportunistically when received. I agree - making it mandatory seems like reasonable approch (within certain limits, e.g. answer size etc.). Petr Špaček @ CZ.NIC > > On Thu, May 28, 2020 at 12:22 PM Vladimír Čunát <mailto:vladimir.cunat%2bi...@nic.cz>> wrote: > > Hello. > > On 5/28/20 10:00 AM, Shane Kerr wrote: > > As I have mentioned several times on microphone, I think this draft > > has huge potential, potentially cutting the number of queries handled > > by recursive resolvers almost in half - since they could ask for A and > > records in a single query. > > I'm not sure if it would be a net benefit if we consider the added > complexity (like the few unpleasant corner cases), the need to implement > on both sides, and other ways that are available. Is saving the number > of IP-layer packets the only significant motivation? > > For resolver-to-auth case I do suspect some potential. Plain UDP will > probably still stay popular there for some time. Though I'm afraid this > might _sometimes_ push the answer sizes too large to fit into one packet > (in signed zones), which in my eyes slightly reduces attractiveness of > the technique, now that we know that UDP over 1.5 kB is no good. > > For non-auth cases, you typically communicate with just one upstream > resolver (or very few), so if the number of packets is a concern, I'd go > for a long-lived TCP or TLS connection (there's e.g. privacy motivation, > too). That's all standardized already, and it naturally avoids those > extra corner cases. Sure, it's probably possible to improve > significantly on session timers and resuming, performance, usage of > Nagle's algorithm, etc. but ATM to me that feels a more worthwhile > investment than any of the multi-answer proposals. One advantage is > that many of the TCP/TLS improvements can be deployed one-sidedly with > some effect but multi-QTYPEs can't. > > --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses)
On 28. 05. 20 19:47, Joe Abley wrote: > On 28 May 2020, at 12:22, Vladimír Čunát wrote: > >> I'm not sure if it would be a net benefit if we consider the added >> complexity (like the few unpleasant corner cases), the need to implement >> on both sides, and other ways that are available. Is saving the number >> of IP-layer packets the only significant motivation? >> >> For resolver-to-auth case I do suspect some potential. [...] > > This is a tangent, and not directly related to the topic of packing extra > records into an answer section. > > This general separation of stub-to-resolver and resolver-to-auth use cases > seems like it's coming up more often. Another recent example is the question > of discovery of available transports (DoT, DoH, etc) for stub-to-resolver is > being examined as a separate problem from the same question for > resolver-to-auth, which I think is also reasonable. > > Architecturally, today, we treat those use cases (and others like > forwarder-to-resolver, or forwarder-to-forwarder) as all using the same > protocol in all the senses of that phrase. >From my resolver implementer view, these variants actually _are_ different >protocols which merely share the same wire format and port number. Differences between mentioned protocol manifest itself any time we encounter a network which silently redirects all traffic on port 53 to local resolver. Recursive resolution attempts in such networks fails horribly because the protocols are actually different and fields mean different things. Having said that ... > > Perhaps it's time to look at whether it would be useful to draw some > boundaries across what is currently one diagram describing how people look > stuff up. It seems to me that there are useful distinctions we could make in > response behaviour, for example, depending on whether it's auth-to-resolver > or resolver-to-stub. Access control, transport security and privacy and > amplification potential also seem like they might be considered differently > in different parts of the system. > > We already have some flags that only mean anything for particular use-cases, > like AD that is meaningless in a response from auth to resolver. Maybe we > could consider an evolution of the architecture to make it more clear that we > can imagine different optimisations being applied to different parts of it. I very much agree, we need to clean up this historical mess! Clear split between stub/forwarding/recursive would help a lot. -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft on delegation revalidation
On 25. 05. 20 5:23, Shumon Huque wrote:
> On Thu, May 21, 2020 at 8:24 AM Petr Špaček <mailto:petr.spa...@nic.cz>> wrote:
>
> >
> > https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01
>
> I would appreciate a practical example of changes envisioned in the
> following paragraph:
>
> > A common reason that zone owners want to ensure that resolvers place
> > the authoritative NS RRset preferentially in their cache is that the
> > TTLs may differ between the parent and child side of the zone cut.
> > Some DNS Top Level Domains (TLDs) only support long fixed TTLs in
> > their delegation NS sets, and this inhibits a child zone owner's
> > ability to make more rapid changes to their nameserver configuration
> > using a shorter TTL, if resolvers have no systematic mechanism to
> > observe and cache the child NS RRset.
>
> Could someone please post an example in steps? Something like:
> - time 0, NSSET parent = {P0}, NSSET child = {C0}
> - time 1, NSSET parent = {P1}, NSSET child = {C1}
> ... along with textual description what operator is hoping to achieve?
>
>
> I'll try to come up with a step by step example later. But in the example
> cited, what the operator is trying to achieve is to change their nameserver
> configuration (e.g. switch to another set of nameservers for their zone) in
> such a way that (1) they can make that change visible to resolvers
> reasonably quickly, and (2) to make sure they are able to backout that
> change quickly if things go wrong. They can do this by lowering the TTL
> in the child NS set which is under their control -- assuming that resolvers
> are
> preferentially caching the child NS set, in accordance with the data ranking
> rules of the DNS protocol (the child NS set is authoritative).
>
> Ad 4. Delegation Revalidation:
>
> I agree with author's note "we would prefer to discard the extensive
> mechanism" but the simple mechanism has simple description for me to
> understand consequences.
>
>
> I've heard the same from other implementers too. Paul V has mentioned that
> there are some subtle corner cases that are dealt with more precisely by the
> extensive algorithm (I can't recall the details right now, but maybe he will
> elaborate for us). Even if we end up on the simple path, it would be good to
> have a better understanding of those cases.
>
> > The simple mechanism:
> >
> > o Cap the time to cache the child NS RRset to the lower of child and
> > parent NS RRset TTL. The normal iterative resolution algorithm
> > will then cause delegation revalidation to naturally occur at the
> > expiration of the capped child NS TTL, along with dispatching of
> > the validation query to upgrade NS RRset credibility.
>
> So far so good, but it does not specify what should happen with RRsets
> other than NS. Even if nothing is prescribed please state that explicitly.
>
>
> Thanks, yes I agree we should discuss all of these. Some quick thoughts for
> now ..
>
> Most importantly:
> - Does the NS affect maximum TTL of _other_ data in the zone?
>
>
> I think there are probably different views on what should happen here. Folks
> who want very prompt takedown of "bad" domains, will probably prefer a
> complete pruning of the cache at the delegation point at the revalidation
> interval, if the NS set has changed or disappeared. When this topic has come
> up in the past, there has been pushback from some implementers that it's
> difficult to do this because they use a non-tree data structure for the cache
> (a hash table most commonly). Most resolvers these days already enforce a max
> cache TTL parameter, so that typically prevents too much abuse. But at the
> very least, they should probably use the revalidation interval as a signal to
> stop "pre-fetching" records below the cut.
>
> - If it does, doesn't it increase risk of thundering herd behavior?
>
>
> Possibly, depending on how popular the zone is, and what we decide is the
> answer to the previous question. At any rate, implementers should always
> employ strategies that bound how much work resolvers can be caused to do.
I'm not concerned about any single resolver instance, I'm more concerned about
large number of resolver instances doing the same thing at the same time.
E.g. if NS TTL was short (say 30 s) and it was used as cap on TTL of all other
records in the zone, then each resolver instance would clear zone from its
cache each 30 seconds. That might cause interes
Re: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses)
On 28. 05. 20 10:00, Shane Kerr wrote: > Ray and other DNS operations folks, > > On 27/05/2020 10.30, Ray Bellis wrote: >> >> >> On 27/05/2020 07:33, Petr Špaček wrote: >> >>> I would much rather spent time on >>> https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03 >>> >>> That would bring benefit to broader set of clients and has advantage >>> that server does not send back data nobody asked for (thus wasting >>> resources on unnecessary work). >> >> I'd be very happy to revive that work if there's interest. > > As I have mentioned several times on microphone, I think this draft has huge > potential, potentially cutting the number of queries handled by recursive > resolvers almost in half - since they could ask for A and records in a > single query. > > I wonder what work is left other than implementation? Most importantly we are missing buy-in (or more precisely _any communication_) with stub resolvers which are actually used by applications. If anyone from Android, iOS, Microsoft, glibc would like to comment here it would be ideal. Personally I: a) Very much like idea of this draft b) At the same time I'm against making this RFC until we have end-to-end implementation. If we do not have implementations on all ends this draft will simply end up as yet another item on my "list of dnsop failures" with drafts published but never implemented, and that's huge waste of everybody's time. > > Possibly it makes sense to describe client how stub or forwarding resolvers > may want to probe their full-service resolvers? I expect that normal behavior > would be: > > 1. Send a query with the Multi-QTYPE option and see if the resolver supports > it. > 2. If it does to send single queries for address lookups instead of parallel > /A queries. > 3. Fallback to parallel /A queries as soon as they get a response that > does not support Multiple-QTYPE. > > Similar description for recursive-to-authoritative might be helpful, since > resolvers cache information about authoritative servers. I guess we could > expect resolvers to ask for DNSKEY and NS together when it makes sense, for > example. Yes, certainly... but ideally this should be done in concert with stub resolver developers so they can tell us what they need from the protocol. Most famously glibc resolver might not have sufficient state to cache this information, or ... I don't know. Petr Špaček @ CZ.NIC > Of course, these use cases can be left as an exercise to the implementer. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] unsolicited HTTPSSVC responses
On 27. 05. 20 1:05, Paul Vixie wrote: > so, this way lies madness, and the solution we see most often is a host-level > cache of DNS results. the old INN (usenet net news) server had one of these, > and all modern browsers have one. many of us simply run a validating > iterative > caching recursive resolver on our hosts, since it's not much code by modern > standards. but in all such cases we don't have a good way to retrieve more > than one kind of data in a single upstream DNS round trip. QDCOUNT>1 is not > well defined and is broadly unimplemented. various other multiple-questions > proposals have been made but nothing gets traction. I would much rather spent time on https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03 That would bring benefit to broader set of clients and has advantage that server does not send back data nobody asked for (thus wasting resources on unnecessary work). I feel that nowadays web browsers have better communication with OS vendors/stub resolvers (Android and Chrome come to mind). Can we stub resolvers on board, pretty please? -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version submitted for draft-arends-private-use-tld
On 26. 05. 20 18:00, Roy Arends wrote: > >> On 26 May 2020, at 16:06, Petr Špaček wrote: >> >> On 02. 05. 20 16:09, Roy Arends wrote: >>> Hi, >>> >>> Ed and I just submitted a new version of our private-use TLD draft. >>> >>> https://www.ietf.org/id/draft-arends-private-use-tld-01.txt >>> >>> This draft has substantial more information than the first draft. It >>> explains that a private-use namespace does not exist, why it is needed, and >>> how a namespace aligned with the user-assigned alpha-2 code elements in the >>> ISO-3166-1 standard can be used as private-use namespace. >> >> I think this is clever hack and should be documented, thank you! > > Any time, thanks! > >> Personally I'm bit torn because I've spent my whole professional career >> explaining people how bad idea it is to use non-delegated/non-unique names >> so I would really like to people from overusing this... >> >> Would you be willing to add at least one paragraph with caution? Something >> along lines "private TLD should be used as _option of last resort_", or more >> verbose "these special TLDs should be used only when other options, e.g. >> private subtree under a properly delegated name, were considered and >> refused." > > I’m not sure about ranking different methods of deployment as each has its > own little idiosyncrasies that may be useful to the deployment scenario. > > How about I add a section that details the additional complexities and adds > caution in using this specific method, such as “Using a private use top level > domain is not ‘more secure’ or ‘more private’ than using a public domain; it > requires additional complexity in resolving and signing, etc, etc” > > Does that work for you? Yes, that would be ideal, I just did not want to delve into details so much. Basically the message I wanted to convey is "usually it is less work and more robust to use a delegated name instead of your own TLD". If you want to add longer explanation I'm happy to review it! -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version submitted for draft-arends-private-use-tld
On 02. 05. 20 16:09, Roy Arends wrote: > Hi, > > Ed and I just submitted a new version of our private-use TLD draft. > > https://www.ietf.org/id/draft-arends-private-use-tld-01.txt > > This draft has substantial more information than the first draft. It explains > that a private-use namespace does not exist, why it is needed, and how a > namespace aligned with the user-assigned alpha-2 code elements in the > ISO-3166-1 standard can be used as private-use namespace. I think this is clever hack and should be documented, thank you! Personally I'm bit torn because I've spent my whole professional career explaining people how bad idea it is to use non-delegated/non-unique names so I would really like to people from overusing this... Would you be willing to add at least one paragraph with caution? Something along lines "private TLD should be used as _option of last resort_", or more verbose "these special TLDs should be used only when other options, e.g. private subtree under a properly delegated name, were considered and refused." Thank you. -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft on delegation revalidation
On 10. 04. 20 15:45, Shumon Huque wrote:
> Hi folks,
>
> Paul Vixie, Ralph Dolmans, and I have submitted this I-D for
> consideration:
>
> https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01
I would appreciate a practical example of changes envisioned in the following
paragraph:
>A common reason that zone owners want to ensure that resolvers place
>the authoritative NS RRset preferentially in their cache is that the
>TTLs may differ between the parent and child side of the zone cut.
>Some DNS Top Level Domains (TLDs) only support long fixed TTLs in
>their delegation NS sets, and this inhibits a child zone owner's
>ability to make more rapid changes to their nameserver configuration
>using a shorter TTL, if resolvers have no systematic mechanism to
>observe and cache the child NS RRset.
Could someone please post an example in steps? Something like:
- time 0, NSSET parent = {P0}, NSSET child = {C0}
- time 1, NSSET parent = {P1}, NSSET child = {C1}
... along with textual description what operator is hoping to achieve?
It would help me to appreciate the value of the proposal.
Ad 4. Delegation Revalidation:
I agree with author's note "we would prefer to discard the extensive mechanism"
but the simple mechanism has simple description for me to understand
consequences.
>The simple mechanism:
>
>o Cap the time to cache the child NS RRset to the lower of child and
> parent NS RRset TTL. The normal iterative resolution algorithm
> will then cause delegation revalidation to naturally occur at the
> expiration of the capped child NS TTL, along with dispatching of
> the validation query to upgrade NS RRset credibility.
So far so good, but it does not specify what should happen with RRsets other
than NS. Even if nothing is prescribed please state that explicitly.
Most importantly:
- Does the NS affect maximum TTL of _other_ data in the zone?
- If it does, doesn't it increase risk of thundering herd behavior?
- If it does not, is it even worth the effort if attacker can put week long TTL
for A/ and keep using that?
- How should resolver handle RCODE=NXDOMAIN? Should it have different effect
than changing NS set to different set of servers? Or change in DS record value?
For me personally mixing two problems (GHOST domains and NS inconsistency) in
single proposal does not help me to understand reasoning behind the proposal
and its intended effects.
Take care.
--
Petr Špaček @ CZ.NIC
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind
Hi dnsop, I support adoption under condition that the envisioned "DNSSEC Transparency" mechanism is documented and somewhat tested before "powerbind" draft progresses into form of RFC. At the moment there are insufficient details published for the dnsop WG to judge whether powerbind+transparency proposals together fulfill intended purpose. I would hate to see "powerbind" published for vendors to implement before (at least!) proof-of-concept implementations of powerbind _and_ Transparency are done. That's the only way to make sure some little details are not preventing vendors from implementing practical proposals. RFCs 7901 (CHAIN extension) and 8094 (DTLS) should serve us as warnings. Petr Špaček @ CZ.NIC On 20. 04. 20 20:03, Tim Wicinski wrote: > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > > From the presentation during the last meeting, there was interest in > adtoping this document around the idea of DNSSEC transparency. This > interest comes the privacy side of things, more than the DNS side. > > This starts a Call for Adoption for draft-pwouters-powerbind > > The draft is available here: > https://datatracker.ietf.org/doc/draft-pwouters-powerbind/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > We are looking for *explicit* support for adoption. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 4 May 2020 > > Thanks, > tim wicinski > DNSOP co-chair ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Last-Call] Secdir last call review of draft-ietf-dnsop-extended-error-14
On 15. 04. 20 0:34, Wes Hardaker wrote: > Catherine Meadows via Datatracker writes: > >> Reviewer: Catherine Meadows >> Review result: Has Issues > > Hi Catherine, > > Thanks for the review of the dnsop-extended-error draft. [and sorry > for the delay in sending this] > >> The Security Considerations section mentions some valid points, but it >> is not made clear how they apply to extended DNS error messages (as >> opposed to DNS error messages in general). It first makes the >> non-obvious point that a significant number of clients, when receiving >> a failure message about a DNS validation issue from a validated >> resolver, will seek out an unvalidated server instead. It is not >> clear to me though whether you think that extending the types of DNS >> error messages available (thus giving more information to the client) >> would help address this problem. You should say something about this. >> Secondly, it discusses the security implications of the fact that DNS >> error messages are unauthenticated. >> >> In addition, in the paragraph about the security implications of DNS error >> messages being unauthenticated, you should say whether or not extending the >> types of DNS error messages would improve the situation, make it worse, >> have >> no effect, or is unclear. > > You're right that we don't specify what to do in the security > considerations section, though we do earlier in the document. > Specifically it says (at least): > > Applications MUST continue to follow requirements from applicable > specifications on how to process RCODEs no matter what EDE values > are also received. > > So maybe adding the following sentence to the security section addresses > your issue? > > EDE content should be treated only as diagnostic information for > network operators and MUST NOT alter DNS protocol processing. > > We could add a note as well about the scope of the document, though I > think it can be derived from the above sentence: > > EDE content is not attempting to address the lack security in DNS > error messages. I think both additions would be good and personally I think it is important enough to warrant some redundancy in the text. -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On Powerbind
Hello everyone, my impression from yesterday is that authors of Powerbind draft assume that everyone else has an idea how DNSSEC Transparency should be implemented, and this makes discussion much harder because IMHO this assumption does not hold. Could authors elaborate on proposed DNSSEC Transparency mechanism, so we can get better idea what role Powerbind has? Do you refer to https://tools.ietf.org/html/draft-zhang-trans-ct-dnssec-03 or some other document? Or are you talking about different idea? Having said that, Powerbind *seems* to be useful and cheap addition, but at the moment I do not have enough information to be sure. Petr Špaček @ CZ.NIC On 14. 04. 20 18:07, Ben Schwartz wrote: > If I understand correctly, the Powerbind draft is designed to reduce the > amount of data that must be logged in order to verify appropriate use of a > DNSKEY "K" for a delegation-only zone. I'm trying to compare the amount of > logging required with and without Powerbind. > > Here's my current best guess: > - With Powerbind, we need to log all DS records (to detect replacement) and > NSEC and NSEC3 records (to detect repudiation) that are signed by K, along > with their RRSIGs. Resolvers would reject any other records signed by K. > - Without Powerbind, we need to log any record signed by K that is not on the > apex, along with its RRSIG. > > But for a delegation-only zone, aren't these the same set? What else would a > delegation-only zone be signing beyond the apex, other than DS, NSEC, and > NSEC3? > > Thanks, > Ben Schwartz > > P.S. Hostile zones can spam the log either way, so that problem is out of > scope. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Consensus suggestion for EDE and the TC bit
On 21. 11. 19 9:49, Wes Hardaker wrote: > Wes Hardaker writes: > >>> I think our simplest and most appealing option would be to treat EDE >>> exactly like any existing EDNS Option (i.e. set the TC bit). >> >> For the record, I'm just fine with this. People that *want* a separate >> signal should speak up please and voice their reasons why having just >> the TC bit is unacceptable too. >> >> We need to come to a decision about this, and that will require everyone >> with an opinion to chime in. > > Actually, I forgot that one of the primary reasons for separating it was > that EDE can go forward and the need for TC/DP bits can be debated > longer if need be. > > So... anyone that thinks something like the DP bit is needed *and* > should be tied to EDE should speak up. Please. I will provide the opposite opinion: DP bit is not *needed* for EDE. If I'm proven wrong in future we can specify DP bit in a separate document and update EDE RFC. (Also I've changed my mind when it comes to TC bit - now I believe that normal DNS processing is fine and EDE does not need a special case.) -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On painting the draft-ietf-dnsop-svcb-httpssvc bikeshed
On 19. 11. 19 11:52, Ted Lemon wrote:
> On Nov 19, 2019, at 5:50 AM, Petr Špaček wrote:
>> Please keep RR type name as one lexical unit!
>>
>> Constructing the name from multiple tokens ("SVCB" "-" "HTTPS") will trigger
>> all sorts of bugs all over the place. For example the venerable
>> dnspython.org library would require rework before it would be able to
>> support the new type named "SVCB-HTTPS".
>>
>> What about SVCBWEB or WEBSVCB?
>>
>> Or shorter SVC + WEBSVC?
>
> I think it’s good to keep the protocol in the name, but agree with the syntax
> issue. Given that http is dead, why not just HTTPSVC or HTTPSVCB? There’s
> never going to be a competing no-TLS version of the RRtype.
Oh wait, why don't we get just "HTTP" for the protocol-specific variant? With
generic key=value format it should be able to accomodate new stuff for future
versions of HTTP...
--
Petr Špaček @ CZ.NIC
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
