Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-qdcount-is-one-01
On 19Jan24, Dave Lawrence apparently wrote:
> Mark Andrews writes:
> > It’s a couple of lines of code in a nameserver to support QCOUNT=0.
> > It will take more time debating this than it took to implement
> > support for QCOUNT=0.
>
> Miek Gieben writes:
> > yes, please, the amount of code that duplicates checks for
> > QDCOUNT!=1 is staggering, and that just in the Golang eco-system.
>
> Well now I'm really a lot more curious about this.
As always, the truth is likely somewhere in the middle.
Nearly two years ago on this very list I asked
(https://lists.dns-oarc.net/pipermail/dns-operations/2022-March/021595.html)
about the
presence of QD=0 server cookies in the wild as I'd not seen any with a "from
scratch" auth
server I was implenting and was wondering whether it was worth adding support.
I didn't get any positive responses but went ahead anyway since RFC7873 is
Standards
Track. This server is written in go and uses Miek's excellent dns package
(github.com/miekg/dns) so I consider it part of the Golang eco-system. It's
open source so
if anyone wants to verify the following, I can send a link.
As an exercise I just removed the QD=0 feature to see how much extra work it
cost in the
original implementation. Here's the SLOC counts according to
github.com/boyter/scc:
QD=0 Prod Tests
Not supported 42524181
Supported 42884182
Diff 36 1
This is somewhat misleading because with QD=0 support the defaultMsgAcceptFunc
has to be
replaced with a custom function which is an exact clone of
defaultMsgAcceptFunc() with one
change:
- if dh.Qdcount != 1 {
+ if dh.Qdcount > 1 {
So if we don't count this clone as *new* code, say if miekg/dns supported QD=0
with a
feature flag, the actual SLOC changes to the server reduce to:
QD=0 Prod Tests
Diff 36 1
Clone -32
4 1
That is, 4 lines of production code and one additional row in a test-case
table. In terms
of just the code related to validating and processing the inbound query, those
4 lines
represent 1% of the ~430 lines of relevant code which itself represents 10% of
the
complete server implementation.
It's also the case that the implementation worried about QD=0 from day one
which gave it a
structural advantage of incorporating QD=0 into a standard logic flow. Existing
implementations which have to retrofit may incur larger structural costs.
You can spin this any way you want, so I'll let others draw their own
conclusions. Before
doing so though, I'll finish with one other stat of interest. In those
aforementioned ~430
lines of query validation, over 20% consists of conditionals! So on one hand,
dealing with
QD=0 cost this implementation just one conditional; on the other hand, that one
"if" lives
in a sea of other conditionals due to DNS complexity.
Mark.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2024-01-30
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
Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-qdcount-is-one-01
Mark Andrews writes: > It’s a couple of lines of code in a nameserver to support QCOUNT=0. > It will take more time debating this than it took to implement > support for QCOUNT=0. Miek Gieben writes: > yes, please, the amount of code that duplicates checks for > QDCOUNT!=1 is staggering, and that just in the Golang eco-system. Well now I'm really a lot more curious about this. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping
Thanks Peter and Paul I'll review the revised I-D but we were thinking of going another (perhaps shorter) follow up working group last call tim On Fri, Jan 19, 2024 at 8:59 AM Peter Thomassen wrote: > For the record, Paul and I sorted these out off-list (for real, this > time!), and I'll push a new revision of the draft shortly. > > ~Peter > > On 11/20/23 16:49, Peter Thomassen wrote: > > Hi Paul, (off-list) > > > > To keep the ball rolling, may I nudge you for your opinion on the below? > :) > > > > Thank you very much for your input, > > Peter > > > > > > On 11/13/23 22:30, Peter Thomassen wrote: > >> Hi Paul, > >> > >> Thanks for your thoughts. I'd like to address your points below and > would very much appreciate your follow-up response. > >> > >> On 11/11/23 12:55, Paul Wouters wrote: > >>> I have read the document and I am supportive of the idea, but I find > the > >>> document not ready. Some issues I have with the document in the > current form: > >>> > >>> - It "deprecates" RFC8078 but does not offer a solution for all cases > of > >>>8078, such as when all nameservers are in-domain of the child. > >> > >> That is correct. This deprecation was requested to be clarified (but > not challenged) in the Dnsdir review [1]. > >> > >> During the subsequent considerations on the list, nobody objected, > which I read as "the WG prefers deprecation". > >> > >> If the WG feels differently, let's change the text. Perhaps one or two > people could speak up if they would prefer such a change. > >> > >> The question at hand is whether, given the cryptographically secure > method of this document, we want to continue endorsing an insecure method, > even if only for in-domain nameservers. > >> > >> I can imagine three kinds of things to say in the draft without > continuing to endorse insecure bootstrapping: > >> > >> 1.) discourage the insecure method (by deprecating it); > >> 2.) perhaps even discourage in-domain nameservers; > >> 3.) perhaps point out that one might perform DNSSEC bootstrapping with > at least one out-of-domain nameserver, then switch to in-domain nameservers > (e.g., via CSYNC). > >> > >> The draft currently does the first thing, but not the other two. > >> > >> In-domain nameservers cause a bunch of problems (including the orphaned > glue saga), and are also foreseen to be incompatible with DELEG-style > delegations in ServiceMode [2]. > >> > >> Reserving any judgment on the DELEG mechanism itself, it appears to me > that in-domain nameservers are best advised against. So perhaps what we > should do is (1) + (2). > >> > >> [1]: > https://mailarchive.ietf.org/arch/msg/dnsop/04LYtemBnRjOBLWzgdD6RuaD5UU/ > >> [2]: > https://mailarchive.ietf.org/arch/msg/dnsop/rUY8CJHrrZYa0Sdvi3BV10IsfiE/ > >> > >>> - Section 4.3 is named "Triggers" but it basically only describes > >>>"Timers". Some of us have significant scar tissue on this matter, > >>>and I don't see new information or a new technology here that > >>>resolves this old discussion. It feels a lot like restating RFC8078. > >> > >> The situation in this draft is different from the trigger conditions in > in Section 6.1 of RFC 7344 (which I think is what you meant). That RFC > lists conditions for *updating* a DS RRset. This one here is for > *initializing*, so other scenarios apply. > >> > >> For example, one condition listed here (but not in RFC 7344) for > triggering the CDS authentication procedure is when the parent receives a > new or updated NS record set for a child. > >> > >> Besides scans (which of course have a timer) and the receipt of a new > NS RRset (which doesn't), the draft also mentions walking a list of > children known to be in need of bootstrapping, perhaps received by AXFR or > extracted via NSEC walk of signaling zones (and the NS receipt). I don't > see any relation to timers here. > >> > >> > >> However, this is second instance (after [3]) that someone suggests to > remove this section, so perhaps it's time to do so. Before doing so, I'd > like to point out the following: > >> > >> The main takeaway from Section 4.3 is that the authentication mechanism > requires reliable knowledge of the delegation's NS records, which -- > depending on the trigger method -- may or may not be implicit in the > trigger condition; as a result, a cross-check in the parent's database may > be needed for certain triggers. This point is not contained in RFC 7344 > (which deals with updates which use the child's existing chain of trust, so > this point doesn't apply). > >> > >> In particular, scanning the registry database or installing a new NS > RRset gives *certain* knowledge of what the NS records are, because the > trigger conditions directly derive from processing an NS RRset that has > previously been accepted for delegation. > >> > >> In contrast, when processing some kind of list fetched externally (e.g. > walking the signaling domain _signal.$NS), it's possible to encounter > signaling records pertaining to domains
Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-07.txt
Dear WP, This is the update resulting from WGLC comments. Changes: - Editorial changes to Security Considerations - Add/discuss bootstrapping triggers via notifications - (non-WGLC) Add Glauca registrar implementation Best, Peter On 1/19/24 14:56, internet-dra...@ietf.org wrote: Internet-Draft draft-ietf-dnsop-dnssec-bootstrapping-07.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator Authors: Peter Thomassen Nils Wisiol Name:draft-ietf-dnsop-dnssec-bootstrapping-07.txt Pages: 17 Dates: 2024-01-19 Abstract: This document introduces an in-band method for DNS operators to publish arbitrary information about the zones they are authoritative for, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated. Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay". This document deprecates the DS enrollment methods described in Section 3 of RFC 8078 in favor of Section 4 of this document, and also updates RFC 7344. [ Ed note: This document is being collaborated on at https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/). The authors gratefully accept pull requests. ] The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-bootstrapping-07.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-dnssec-bootstrapping-07 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 -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping
For the record, Paul and I sorted these out off-list (for real, this time!), and I'll push a new revision of the draft shortly. ~Peter On 11/20/23 16:49, Peter Thomassen wrote: Hi Paul, (off-list) To keep the ball rolling, may I nudge you for your opinion on the below? :) Thank you very much for your input, Peter On 11/13/23 22:30, Peter Thomassen wrote: Hi Paul, Thanks for your thoughts. I'd like to address your points below and would very much appreciate your follow-up response. On 11/11/23 12:55, Paul Wouters wrote: I have read the document and I am supportive of the idea, but I find the document not ready. Some issues I have with the document in the current form: - It "deprecates" RFC8078 but does not offer a solution for all cases of 8078, such as when all nameservers are in-domain of the child. That is correct. This deprecation was requested to be clarified (but not challenged) in the Dnsdir review [1]. During the subsequent considerations on the list, nobody objected, which I read as "the WG prefers deprecation". If the WG feels differently, let's change the text. Perhaps one or two people could speak up if they would prefer such a change. The question at hand is whether, given the cryptographically secure method of this document, we want to continue endorsing an insecure method, even if only for in-domain nameservers. I can imagine three kinds of things to say in the draft without continuing to endorse insecure bootstrapping: 1.) discourage the insecure method (by deprecating it); 2.) perhaps even discourage in-domain nameservers; 3.) perhaps point out that one might perform DNSSEC bootstrapping with at least one out-of-domain nameserver, then switch to in-domain nameservers (e.g., via CSYNC). The draft currently does the first thing, but not the other two. In-domain nameservers cause a bunch of problems (including the orphaned glue saga), and are also foreseen to be incompatible with DELEG-style delegations in ServiceMode [2]. Reserving any judgment on the DELEG mechanism itself, it appears to me that in-domain nameservers are best advised against. So perhaps what we should do is (1) + (2). [1]: https://mailarchive.ietf.org/arch/msg/dnsop/04LYtemBnRjOBLWzgdD6RuaD5UU/ [2]: https://mailarchive.ietf.org/arch/msg/dnsop/rUY8CJHrrZYa0Sdvi3BV10IsfiE/ - Section 4.3 is named "Triggers" but it basically only describes "Timers". Some of us have significant scar tissue on this matter, and I don't see new information or a new technology here that resolves this old discussion. It feels a lot like restating RFC8078. The situation in this draft is different from the trigger conditions in in Section 6.1 of RFC 7344 (which I think is what you meant). That RFC lists conditions for *updating* a DS RRset. This one here is for *initializing*, so other scenarios apply. For example, one condition listed here (but not in RFC 7344) for triggering the CDS authentication procedure is when the parent receives a new or updated NS record set for a child. Besides scans (which of course have a timer) and the receipt of a new NS RRset (which doesn't), the draft also mentions walking a list of children known to be in need of bootstrapping, perhaps received by AXFR or extracted via NSEC walk of signaling zones (and the NS receipt). I don't see any relation to timers here. However, this is second instance (after [3]) that someone suggests to remove this section, so perhaps it's time to do so. Before doing so, I'd like to point out the following: The main takeaway from Section 4.3 is that the authentication mechanism requires reliable knowledge of the delegation's NS records, which -- depending on the trigger method -- may or may not be implicit in the trigger condition; as a result, a cross-check in the parent's database may be needed for certain triggers. This point is not contained in RFC 7344 (which deals with updates which use the child's existing chain of trust, so this point doesn't apply). In particular, scanning the registry database or installing a new NS RRset gives *certain* knowledge of what the NS records are, because the trigger conditions directly derive from processing an NS RRset that has previously been accepted for delegation. In contrast, when processing some kind of list fetched externally (e.g. walking the signaling domain _signal.$NS), it's possible to encounter signaling records pertaining to domains that are *not* delegated to $NS; therefore, the parent has to check that what's found in the list matches an actual delegation. I would like to hear your opinion on whether this point warrants the existence of Section 4.3; if it doesn't, I'll go ahead and remove it. [3]: https://mailarchive.ietf.org/arch/msg/dnsop/toP-e7Rc-ZLg0dR2SvzC25kAGxk/ - Style: I think the document is a lot more verbose and repetitive than it needs to be. Condensing this would increase clarity of the document. It looks like opinions within the W
[DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-07.txt
Internet-Draft draft-ietf-dnsop-dnssec-bootstrapping-07.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator Authors: Peter Thomassen Nils Wisiol Name:draft-ietf-dnsop-dnssec-bootstrapping-07.txt Pages: 17 Dates: 2024-01-19 Abstract: This document introduces an in-band method for DNS operators to publish arbitrary information about the zones they are authoritative for, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated. Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay". This document deprecates the DS enrollment methods described in Section 3 of RFC 8078 in favor of Section 4 of this document, and also updates RFC 7344. [ Ed note: This document is being collaborated on at https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/). The authors gratefully accept pull requests. ] The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-bootstrapping-07.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-dnssec-bootstrapping-07 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] Fw: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt
i think offering more than one wire encoding to get the same outcome would be the opposite of simplicity. if the ietf were to decide that dnssec had been a mistake and universal deployment was no longer to be sought, then we would want to look carefully at the features it had contained and consider other ways to get them. if it helps, imagine that the lifetime total cost of an "if" statement in an open source program is about $10,000.00. re: Zhiwei Yan wrote on 2024-01-19 00:42: Hello, Paul, Simplicity and ease of use are fundamental features that enable the large-scale deployment of a protocol. You are right, everyone hopes for the widespread deployment of DNSSEC to mitigate various security risks. While, this draft addresses two key aspects: on one hand, we aim to delve into the security vulnerabilities associated with delegation, and on the other hand, propose corresponding solutions that can be achieved through extending DNS, or assuming DNSSEC and simpler optimizations based on DNSSEC. BR, Zhiwei 在 2024/1/7 18:01, Paul Vixie 写道: zuop...@cnnic.cn wrote on 2024-01-06 22:59: ... Aggressive NSEC (RFC 8198) is useful against to NXNSAttack –like attack, because it allows a DNSSEC-validating resolver to generate negative answers within a range. ... have you looked at dns rrl? ... But if a NSEC3 RR has an Opt-Out flag, it can’t be used for aggressive negative caching. In addition, DNSSEC adoption rate remains low in some area and this situation may not change significantly over a long period of time for policy reasons. i think as long as we keep adding features that are only necessary because dnssec lacks certain features or is not universally deployed or both, then dnssec will lack certain features or not be universally deployed or both. please be careful what you wish for. Compared to DNSSEC, the draft is relatively simple, it uses OPT RR option to confirm NS record only when a resolver is requesting address (Glue record) of delegation points. And it is compatible with current DNS protocol. it will always be within our powers to add complexity. google for "dns camel" to find out one author's thoughts about how to use that power more wisely. -- P Vixie ___ 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
[ Quoting in "Re: [DNSOP] Dnsdir early review of ..." ] 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. yes, please, the amount of code that duplicates checks for QDCOUNT!=1 is staggering, and that just in the Golang eco-system. Regards, Miek ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
