Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance
On Mon, 10 May 2021, Benno Overeinder wrote: Now we will start a period of two weeks for the call for adoption of draft-hardaker-dnsop-nsec3-guidance on the mailing list. The draft is available here: https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/. 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 adopt. Willing to review and contribute text. I think what is missing is a discussion of online signing with nsec3 white lies - it does make it harder to brute force since you can't grab the full chain of hashed names. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] ZONEMD was Re: [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
> On 11 May 2021, at 09:20, Paul Hoffman wrote: > > On May 10, 2021, at 4:14 PM, Mark Andrews wrote: >> Actually, the process problem is that record format keeps changing AFTER the >> code point has been assigned and the record format THEORETICALLY been FIXED. > > Mark makes an excellent point, one that people in the DNS world routinely > forget. Just for reference ZONEMD switched two fields between draft-wessels-dns-zone-digest-05.txt and RFC 8976. "Digest Type | Reserved” -> "Scheme | Hash Algorithm”. This resulted in BIND rejecting zones with ZONEMD records using SHA-512 digests (digest field has the wrong length for Digest Type 1). Renaming fields is fine. Reordering/repurposing non reserved isn’t as it breaks stuff. Now we are making BIND compatible with RFC 8976 but we should never have been put in this position. > --Paul Hoffman___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
On Mon, May 10, 2021 at 9:58 AM Ben Schwartz wrote:
> I don't support breaking the SvcParams into separate RRs across the
> RRSet. This would be an extremely inefficient encoding in wire format, and
> would conflict with the usual understanding of resource records as
> independently meaningful alternatives.
>
> [snip]
> To see why I favor two-pass, consider a SvcParam whose wire format value
> is defined to be CBOR, represented as JSON in the zone file. JSON is
> defined as UTF-16, and allows strings containing any character from the
> Basic Multilingual Plane. It also allows various kinds of backslash
> escaping including " \" " for quotes within strings, and "\uD834\uDD1E"
> for extended unicode codepoints. A one-pass parser must somehow integrate
> this into the flow of zone file parsing. The easiest way is to simply
> disable all RFC1035-style escapes and line-breaks for the duration of the
> SvcParamValue, but this is a major breach of standard zone file practice,
> and raises questions about how to store UTF-16 characters in a zone file.
> Alternatively, we could somehow combine both RFC1035 and JSON escaping, but
> if this is even possible, it would seem to require writing a new
> RFC1035+JSON hybrid parser. I also think these behaviors would be
> confusing to users, who would have to try to understand how this new
> integrated escaping works in order to author zone files containing either
> kind of escape.
>
[snip]
Let me ask what is probably a really leading question, in terms of the
semantics for SVCB (and HTTPS).
If I understand the draft in its current form, the goal is to be able to
encode and parse some DNS RRset in such a way as it lets you obtain, in one
fell swoop (but possibly multiple passes for parsing) everything needed to
obtain:
- A well-ordered list of one or more targets, where each target has a set
of attributes.
- The examples currently show RRsets with multiple distinct Priority values
- However, the words indicate that it is permissible for two RRs in the set
to have the same Priority value.
- The effect is having an array of objects, each of which has a priority,
name, and optional set of key/value pairs (where values can be lists).
So, I have a proposed solution that will make the parsing, and generation
of post-parsing JSON objects as close to trivial as possible.
This borrows heavily from what Joe Abley already wrote. I'm just taking the
concept to its (il)logical conclusion.
Encode everything using the following mechanism:
Priority Enumeration Key Value
One of the "Keys" would be Target, with a corresponding Value of FQDN.
All of the records with the same value for "enumeration" belong together,
and form a single SvcParameter list.
For the AliasForm, both the Priority and Enumeration would be 0, and only a
single Target,Value pair are permitted.
To take one example from the draft, and re-encode it thusly:
$ORIGIN svc.example. ; A hosting provider.
pool 7200 IN HTTPS 1 h3pool alpn=h2,h3 ech="123..."
HTTPS 2 . alpn=h2 ech="abc..."
pool 300 IN A192.0.2.2
2001:db8::2
h3pool 300 IN A192.0.2.3
2001:db8::3
This would become (for brevity, encoding just a list of RDATA values for
all of the "pool HTTPS" records):
1 1 target "h3pool"
1 1 alpn "h2,h3"
1 1 ech "123..."
2 2 target "."
2 2 alpn "h2"
2 2 ech "abc..."
I think this is likely a lot easier to parse, and to convert into whatever
form your ALPN-handling stuff wants (including JSON).
I is also very close to trivial to write a JSON -> Zone File
transliterator, so user input in JSON (which meets the JSON structure
expected) can be handled, and even bidirectionally allow Zone File -> JSON
for user editing of already-existent entries.
For the example above;
If the priority of both of the above were the same, they would be all "1 1
..." and "1 2 ..." instead of "1 1 ..." and "2 2 ...".
If my JSON isn't horribly bad, I think this would get converted into:
[ { "name" : "h3pool", "priority" : 1, "SvcParams" : { "alpn" : "h2,h3",
"ech" : "123..." } }, ...]
IMNSHO, it'll be faster to discard any existing parsing code, and embrace
this as the Zone File format (and wire format) going forward.
Hope this is helpful to the discussion.
Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
On May 10, 2021, at 4:14 PM, Mark Andrews wrote: > Actually, the process problem is that record format keeps changing AFTER the > code point has been assigned and the record format THEORETICALLY been FIXED. Mark makes an excellent point, one that people in the DNS world routinely forget. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
> On 11 May 2021, at 08:46, Paul Hoffman wrote: > > On May 10, 2021, at 9:56 AM, Ben Schwartz > wrote: >> >> I don't support breaking the SvcParams into separate RRs across the RRSet. >> This would be an extremely inefficient encoding in wire format, and would >> conflict with the usual understanding of resource records as independently >> meaningful alternatives. > > Fully agree. It is a large change in the DNS protocol for a receiver to have > to internally group multiple RRs based on matching (priorty | target) tuples > and make security decisions based on the group, not on the record. > >> It would also require a dramatic rewrite of a specification that is now >> widely deployed. > > Er, screw that. The fact that some developers deployed this even though it > hadn't even completed WG last call, much less had a wider IETF review, is a > problem for those developers to solve. Actually, the process problem is that record format keeps changing AFTER the code point has been assigned and the record format THEORETICALLY been FIXED. When you go down the template route for code point assignment that FIXES the wire and presentation formats. A. Submission Date: 2020-06-18 B.1 Submission Type: [ X ] New RRTYPE [ ] Modification to RRTYPE B.2 Kind of RR: [ X ] Data RR [ ] Meta-RR C. Contact Information for submitter (will be publicly posted): Name: Erik Nygren Email Address: erik+ietf International telephone number: +1 617 444 3938 Other contact handles: D. Motivation for the new RRTYPE application. Please keep this part at a high level to inform the Expert and reviewers about uses of the RRTYPE. Most reviewers will be DNS experts that may have limited knowledge of your application space. The "HTTPS" DNS RR type facilitates the lookup of information needed to make connections for origin resources, such as for HTTPS URLs. HTTPS RRs allow an origin to be served from multiple network locations, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. For example, the presence of an HTTPS RR indicates that clients should upgrade insecure "http" URLs to secure "https" URLs prior to establishing a connection. E. Description of the proposed RR type. This description can be provided in-line in the template, as an attachment, or with a publicly available URL. See https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-00 F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? (from I-D.draft-ietf-dnsop-svcb-https-00 #appendix-A) The SRV record [RFC2782] can perform a similar function to the SVCB record, informing a client to look in a different location for a service. However, there are several differences: o SRV records are typically mandatory, whereas clients will always continue to function correctly without making use of HTTPS RRs. o SRV records cannot instruct the client to switch or upgrade protocols, whereas HTTPS RRs can signal such an upgrade (e.g.. to HTTP/2). o SRV records are not extensible, whereas HTTPS RRs can be extended with new parameters, such as for TLS Encrypted Client Hello keys. G. What mnemonic is requested for the new RRTYPE (optional)? HTTPS H. Does the requested RRTYPE make use of any existing IANA registry or require the creation of a new IANA subregistry in DNS Parameters? If so, please indicate which registry is to be used or created. If a new subregistry is needed, specify the allocation policy for it and its initial contents. Also include what the modification procedures will be. Yes, per I-D.draft-ietf-dnsop-svcb-https-00#section-12: * Create a new "Service Binding (SVCB) Parameter Registry" with an initial population of entries. This would be shared with the SVCB RR type. * Add an _https entry to the DNS Underscore Global Scoped Entry Registry. I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])? No. While DNS servers and resolvers may perform performance optimizations described in the I-D, these are optional and do not preclude processing as an unknown RRTYPE. J. Comments: The plan is to bring draft-ietf-dnsop-svcb-https to Working Group Last Call during Summer 2020. A early code point allocation for the SVCB RRtype and HTTPS RRtype is requested to enable interop testing between multiple implementations that are in-progress. >> As for the question of commas, I continue to
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Hiya, Without commenting on the rest of the discussion (though I do agree with those who made the point that optimising for those writing zone files here is better than for those parsing zone files)... On 10/05/2021 17:56, Ben Schwartz wrote: It would also require a dramatic rewrite of a specification that is now widely deployed. I'm not aware this is widely deployed. To be fair I mostly care about deployments that support ECH and so far I know of 2 of those. There may be more doing HTTPS or SVCB but not ECH I guess. If so, I'd find it valuable to see a list of those so I can get a sense of the variability to be seen in HTTPS/SVCB deployments. So - can you provide some backup for that claim of being widely deployed that might help me see how folks are choosing to deploy? Thanks, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
On May 10, 2021, at 9:56 AM, Ben Schwartz wrote: > > I don't support breaking the SvcParams into separate RRs across the RRSet. > This would be an extremely inefficient encoding in wire format, and would > conflict with the usual understanding of resource records as independently > meaningful alternatives. Fully agree. It is a large change in the DNS protocol for a receiver to have to internally group multiple RRs based on matching (priorty | target) tuples and make security decisions based on the group, not on the record. > It would also require a dramatic rewrite of a specification that is now > widely deployed. Er, screw that. The fact that some developers deployed this even though it hadn't even completed WG last call, much less had a wider IETF review, is a problem for those developers to solve. > As for the question of commas, I continue to believe that the current text is > preferable. I believe that the behavior Dick is advocating for is in fact > the one that was present in the draft until -02 [1], changed here [2]. We > changed this text after receiving complaints from WG members that the > algorithm as specified was too complicated, along with my own experiences > attempting to implement it in multiple codebases that apply char-string > decoding during or before tokenization. This is central to the problem of SVCB: it is more complex than traditional DNS RRtypes, and different developers have different views of what would make it simpler for them to implement and/or simpler for zone operators to type into zone files. I hope Dick's proposed simple addition is useful. I'm not a developer, and I don't write into zones very often, but I suspect that "it's all in one record that has an addition to the parsing" will be easier and safer to implement than "the receiver has to handle groups of records in a new way". --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
> On 11 May 2021, at 02:56, Ben Schwartz > wrote: > > I don't support breaking the SvcParams into separate RRs across the RRSet. > This would be an extremely inefficient encoding in wire format, and would > conflict with the usual understanding of resource records as independently > meaningful alternatives. It would also require a dramatic rewrite of a > specification that is now widely deployed. > > As for the question of commas, I continue to believe that the current text is > preferable. I believe that the behavior Dick is advocating for is in fact > the one that was present in the draft until -02 [1], changed here [2]. We > changed this text after receiving complaints from WG members that the > algorithm as specified was too complicated, along with my own experiences > attempting to implement it in multiple codebases that apply char-string > decoding during or before tokenization. > > The key question is: how is the zone file parsing supposed to work? I see > two main options: > > One-pass (draft-02): > 1. Read the key name up to an "=" > 2. Load a parser whose behavior depends on the key name > 3. Feed this parser characters from the zone file until it declares > completion or error > > Two-pass (more recent drafts): > 1. Read the key name up to an "=" > 2. Parse the value as a char-string > 3. Pass the char-string parser output to the a key-specific parser for deeper > processing > > In one-pass parsing, comma-separated value (CSV) lists are like dot-separated > domain names: first-class entities whose delimiter escaping is fully > integrated into the parsing. In two-pass parsing, CSV format is an > implementation detail of particular SvcParam registrations, encoded as data > inside plain char-strings in the zone file. > > To see why I favor two-pass, consider a SvcParam whose wire format value is > defined to be CBOR, represented as JSON in the zone file. JSON is defined as > UTF-16, and allows strings containing any character from the Basic > Multilingual Plane. It also allows various kinds of backslash escaping > including " \" " for quotes within strings, and "\uD834\uDD1E" for extended > unicode codepoints. A one-pass parser must somehow integrate this into the > flow of zone file parsing. The easiest way is to simply disable all > RFC1035-style escapes and line-breaks for the duration of the SvcParamValue, > but this is a major breach of standard zone file practice, and raises > questions about how to store UTF-16 characters in a zone file. > Alternatively, we could somehow combine both RFC1035 and JSON escaping, but > if this is even possible, it would seem to require writing a new RFC1035+JSON > hybrid parser. I also think these behaviors would be confusing to users, who > would have to try to understand how thi s new integrated escaping works in order to author zone files containing either kind of escape. Yet you fail to mention that the following 3. Encoding JSON text SHALL be encoded in Unicode. The default encoding is UTF-8. The UTF-16 JSON strings values are encoded as UTF-8. UTF-8 in zone files usually ends up being \DDD for non-ASCII and ASCII control octets once it has gone from text -> wire -> text to put everything into ASCII printable. Zone files are ASCII documents. If you are using the values in other contexts you may convert the wire forms differently. > In two-pass parsing, this is trivial. One simply parses the value as a > char-string, and feeds the output to a JSON parser. The resulting > double-escaping may be unattractive, but is commonplace when working with > structured data inside a string. > > Another point in favor of two-pass parsing: it makes unknown keys "value > errors" instead of "syntax errors". In one-pass parsing, when the parser > encounters an unrecognized SvcParamKey, it must stop and fail immediately. > It cannot proceed, because it cannot even continue tokenizing. > > [1] > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-02#appendix-A.1 > [2] https://github.com/MikeBishop/dns-alt-svc/pull/282 > > > On Mon, May 10, 2021 at 8:35 AM Joe Abley wrote: > Hi Pieter, > > On 10 May 2021, at 11:23, Pieter Lexis wrote: > >> You then invite the following issues: >> >> Clients need to match the tuple (ownername + prio + target) and get all >> data from all matched rrsets, whereas now you get all that data in one >> piece of rdata. > > Inviting that issue is also a potential benefit, but I agree that the > implication exists. For example, the ability to publish sets of SvcParams > with long TTLs ought to increase the probability of cache hits for that data > and reduce SVCB response sizes. > >> A client also can't figure out (if not doing DNSSEC valdiation >> themselves) if you have received all the SVC data for a certain name. > > A client can't figure out without DNSSEC whether anything they have received > is correct in, in general. So setting
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
On Mon, 10 May 2021, Ben Schwartz wrote: It would also require a dramatic rewrite of a specification that is now widely deployed. The IETF is not a rubber-stamp factory for corporate proposals though. The tendency for corporation to bring up something at the IETF that is "too far gone" for modifications during the IETF process as a trend is worrying, and does make me personally feel less sympathetic towards those kind of deployments. Did you reach out to SecDir for an early review request? I cannot find anything in the SecDir archives related to HTTPSVC or SVCB. DNS records have been using _prefix labels for a while now to split up RR information to be more specific related to targetted DNS requests. This RR type is unfortunately not using that, and thus the complexity and securtity issues are popping up now. To see why I favor two-pass, consider a SvcParam whose wire format value is defined to be CBOR, represented as JSON in the zone file. JSON is defined as UTF-16, and allows strings containing any character from the Basic Multilingual Plane. It also allows various kinds of backslash escaping including " \" " for quotes within strings, and "\uD834\uDD1E" for extended unicode codepoints. A one-pass parser must somehow integrate this into the flow of zone file parsing. The easiest way is to simply disable all RFC1035-style escapes Or to simply disable all JSON/COBR/UTF-16 et all ? Do we really need emoticons in our transport definitions ? I also think these behaviors would be confusing to users, who would have to try to understand how this new integrated escaping works in order to author zone files If that is the main argument, what's wrong with plain ascii limitations? Anyway, I think this issue deserves a full discussion, without taking into account the current wide deployment. Also bacause everything out there that does not support SVCB also continues to work, so it is not the end of the world if SVCB needs to go through some changes. But as Mr.Abley said (and I paraphrase) "we can burn an RR type allocation easilly". Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
On Mon, 2021-05-10 at 22:09 +0100, Tony Finch wrote: > Peter van Dijk wrote: > > Also in section 3.2, I do not think responding with the option should > > be limited to NOERROR. Specifically, I'd very much also want it to work > > for NXDOMAIN, > > Isn't the SOA record usually present in a negative response? Good point! In that case, I retract most of that and suggest the draft points out that in those cases, a serial can be extracted anyway. That said, I'm not sure that's a reason to skip including the option in the response. > and I can imagine some cases of it being useful even in SERVFAIL cases > > (at least in database-driven name servers like PowerDNS, where > > individual records inside a zone can be broken). > > Perhaps also in cases where the server has a copy of zone serial number > NNN but it has expired. +1 Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
Peter van Dijk wrote: > > Also in section 3.2, I do not think responding with the option should > be limited to NOERROR. Specifically, I'd very much also want it to work > for NXDOMAIN, Isn't the SOA record usually present in a negative response? > and I can imagine some cases of it being useful even in SERVFAIL cases > (at least in database-driven name servers like PowerDNS, where > individual records inside a zone can be broken). Perhaps also in cases where the server has a copy of zone serial number NNN but it has expired. Tony. -- f.anthony.n.finchhttps://dotat.at/ Viking, North Utsire: Cyclonic 6 to gale 8, becoming southerly 3 to 5. Moderate or rough, becoming moderate in North Utsire. Rain, fog patches. Moderate or good, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
On Mon, 10 May 2021, Joe Abley wrote: $ORIGIN example.com @ SVCB 1 foo key6="\032\001\013\184\000\000\000\000\000\000\000\000,\000" ; a.k.a. ipv6hint=2001:db8::5c5c:2c00 A zone owner/editor would never even think of typing in IP addresses like that. Right, but an attacker who wants to take advantage of the impact of that observation in the construction of some parser might, which is why it's a security concern. Some DN / RDN / CN parsing tools have hthis issue too and some allow a comma with an additional masking comma, eg OU=testing,,security, O=Mayhem Then other code can just never ever allow masking, double masking, backslshing, single or double quotes or what not. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance
On Mon, 10 May 2021, Olafur Gudmundsson wrote: I guess I support the document but would like it to say “Please do not use NSEC3 but if you have to use NSEC3 use it use these settings” The document should point how trivial it is to expose most names in NSEC3 signed zone using Graphics cards and dictionaries. But it should also then say something about opt-out, which might be harder to agree on (imho: "really, we have the RAM/CPU/SSD/DISK now, you should not use opt-out") Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
On Mon, 2021-05-10 at 12:37 -0400, Hugo Salgado wrote: > Hello everyone. Thanks for the comments, I just uploaded an unchanged > version (just to revive it) at: > https://datatracker.ietf.org/doc/draft-salgado-dnsop-RRSERIAL/ Thanks Hugo, that is useful. In section 3.2, 'the resource record of the ANSWER section' is ambiguous. The answer section can contain many resource record (s/sets). I suggest a reference to 'QNAME (original)' from RFC8499, or a careful copy of the words in that definition. Also in section 3.2, I do not think responding with the option should be limited to NOERROR. Specifically, I'd very much also want it to work for NXDOMAIN, and I can imagine some cases of it being useful even in SERVFAIL cases (at least in database-driven name servers like PowerDNS, where individual records inside a zone can be broken). > I agree RRSERIAL doesn't have much relevance in zones that don't give > serial versioning a meaning to its content. We can add a paragraph > about it, to make the applicability more clear. I agree, and I do not think this is a reason to not have this feature. > I also don't think we > should start to "deprecate" the SOA serial meaning at this point. > One can say that "modern" implementations using complex backends makes > SOA serials irrelevant, but there's certainly a use case for classic > and mainly static behavior. Just as NSID adds an "infrastructure" > identification dimension to a response, RRSERIAL adds the data > versioning dimension. +1 > And responding to the comment that having multi-queries is better, is > something that is long overdue, and would certainly make this hack > obsolete. Multi-query has not happened. I doubt it will happen. And in fact, mapping this specific use case onto it would limit implementations. I can imagine multi-query being implemented in some proxy/frontend, that sends out parallel queries to 'simpler' auths that do not even know about multi-query, and then the atomicity is gone. > Other issues that I think need more analysis is deciding whether it > makes any sense to expose RRSERIAL in resolvers. The original idea was > only in authoritatives, but it might make some sense to debug in > resolvers as well, to somehow identify the "data source" of a cached > record. In this sense, I fear an increase in cache requirements of > resolvers, which should somehow maintain the extra data; and also > in traffic and option availability for upstream auths. To expose it in resolvers, resolvers would have to set the option on all their outgoing queries, so that they can remember the serial involved in each RRset that they got. I don't think this puts a big burden on storage requirements, but adding EDNS options to all your resolver-to-auth traffic is always a gamble, finding out which auths will suddenly return SERVFAIL, or REFUSED, or just drop your query - or, in some observed cases, tell you NXDOMAIN because they're confused. Now, those auths are wrong, and should not exist, but I trust there will be some reluctance in deployments. That said, supporting this feature in resolvers does not require any changes to the protocol itself; the EDNS option, as your draft currently defines it, looks fine to me. Of course, if the document does want to support the resolver case, it should explain what that means. (Unrelated to anything above, I can see reasons to put the whole SOA in there instead of just the serial; this also reinvokes the 'why not put it in AUTHORITY or ADDITIONAL' question, but I really like the short EDNS option that does not change the processing of any RRsets from a query response.) Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance
On Mon, May 10, 2021 at 12:07 PM Peter van Dijk wrote: > On Mon, 2021-05-10 at 10:55 +0200, Benno Overeinder wrote: > > The draft is available here: > > https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/. > > > > 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. > > I support adoption of this draft, and am willing to review and > contribute text (in fact, I have already done so at small scale). > > I think the draft really deserves some text on when not to use NSEC3 at > all (i.e. when to pick NSEC instead) and I would be happy to contribute > that too, if nobody beats me to it. > > I support adoption of this draft, and concur with what Peter says (regarding NSEC). I'm willing to review and as time permits, contribute text. Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
On Mon, 2021-05-10 at 16:43 +0200, Pieter Lexis wrote: > Hi Dick, > > On 5/10/21 1:02 PM, Dick Franks wrote: > > My objection is narrowly focussed on the escape mechanism, nothing > > more. Changing the delimiter is neither necessary nor relevant. > > > > I am happy to contribute the necessary words. > > If you have the words to fix this issue that would need to changes the > code but clears everything up, do it :). I would like to clarify that Pieter meant 'need no changes to the code'. :-) Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance
I guess I support the document but would like it to say “Please do not use NSEC3 but if you have to use NSEC3 use it use these settings” The document should point how trivial it is to expose most names in NSEC3 signed zone using Graphics cards and dictionaries. Olafur > On May 10, 2021, at 1:20 PM, Tony Finch wrote: > > Benno Overeinder wrote: >> >> https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/. > > Yes, this is a helpful document that should be adopted by dnsop. I'm happy > to review etc. > > Tony. > -- > f.anthony.n.finchhttps://dotat.at/ > Biscay: Southwest 3 to 5 increasing 5 to 7. Rough, occasionally > moderate in east, becoming very rough in west. Thundery showers. Good, > occasionally poor. > > ___ > 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
Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance
On Mon, 2021-05-10 at 10:55 +0200, Benno Overeinder wrote: > The draft is available here: > https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/. > > 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. I support adoption of this draft, and am willing to review and contribute text (in fact, I have already done so at small scale). I think the draft really deserves some text on when not to use NSEC3 at all (i.e. when to pick NSEC instead) and I would be happy to contribute that too, if nobody beats me to it. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance
I like the document, but the section on validators recommends not to follow requirements from RFC 5155, so I don't expect that best-practice track is sufficient. And I do think we need a similar update to 5155, be it in this document or a separate one. I'd also expect something on limits accepted by secondaries. And some details are probably up to further discussion (e.g. particular numbers and SERVFAIL), but I don't think such details would block adoption. --Vladimir | knot-resolver.cz ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance
I support the adoption of the document. Yours, Daniel On Mon, May 10, 2021 at 1:21 PM Tony Finch wrote: > Benno Overeinder wrote: > > > > https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/. > > Yes, this is a helpful document that should be adopted by dnsop. I'm happy > to review etc. > > Tony. > -- > f.anthony.n.finchhttps://dotat.at/ > Biscay: Southwest 3 to 5 increasing 5 to 7. Rough, occasionally > moderate in east, becoming very rough in west. Thundery showers. Good, > occasionally poor. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Daniel Migault Ericsson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance
Benno Overeinder wrote: > > https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/. Yes, this is a helpful document that should be adopted by dnsop. I'm happy to review etc. Tony. -- f.anthony.n.finchhttps://dotat.at/ Biscay: Southwest 3 to 5 increasing 5 to 7. Rough, occasionally moderate in east, becoming very rough in west. Thundery showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Hi Ben, On 10 May 2021, at 12:56, Ben Schwartz wrote: > I don't support breaking the SvcParams into separate RRs across the RRSet. > This would be an extremely inefficient encoding in wire format, I think that assertion may well be worth challenging, and... > and would conflict with the usual understanding of resource records as > independently meaningful alternatives. ... I think we disagree about how we usually interpret the use of RRSets with more than one member RR. > It would also require a dramatic rewrite of a specification that is now > widely deployed. However, this seems clear (see my earlier horse/sailed comment). Given that the draft semantics of SVCB have already seen some implementation, any new semantics would need a new RRType (SVCC? :-) I admit I have a certain aesthetic bias here since I find the entire concept of embedding a list of parameters inside a single RR to be very un-DNS-like. However, I found Mr Wouter's concerns (paraphrasing, "perhaps we should pre-allocate a set of CVE numbers for this") worth considering, and would hope that if there is a reason to burn the current RRType on security grounds (or any grounds more compelling than aesthetic) that we would do so. Joe signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I agree with what Hugo said I would also like to point out that this draft spirit is aiming to be a debugging tool to be used by humans and not in between servers. If we start introducing all these new use cases in-between servers (like authoritatives signaling secondaries or resolvers storing new data) it would add an inmense amount of complexity that might be out of scope at the moment. Would it be simpler to progress with this as a read-only way to query an authoritative server in an atomic way for what's the current status of a record? I guess if we agree on that, we could expand on a better description or explanation to reflect such intention. Mauricio - -- Mauricio Vergara Ereche keybase.io/mave On 2021-05-10 at 16:37, hsalg...@nic.cl wrote: > Hello everyone. Thanks for the comments, I just uploaded an unchanged > version (just to revive it) at: > https://datatracker.ietf.org/doc/draft-salgado-dnsop-RRSERIAL/ > > I agree RRSERIAL doesn't have much relevance in zones that don't give > serial versioning a meaning to its content. We can add a paragraph > about it, to make the applicability more clear. I also don't think we > should start to "deprecate" the SOA serial meaning at this point. > One can say that "modern" implementations using complex backends makes > SOA serials irrelevant, but there's certainly a use case for classic > and mainly static behavior. Just as NSID adds an "infrastructure" > identification dimension to a response, RRSERIAL adds the data > versioning dimension. > > And responding to the comment that having multi-queries is better, is > something that is long overdue, and would certainly make this hack > obsolete. But I think the multi-query issues are so complex that it's > worth moving forward incrementally in the meantime. For the same > reason, I think we could aim for it to have "experimental" status at > the start, and after a few years we measure it to see its use and we > can adapt or change it to standard or deprecate it in favor of another > qtype. > > Other issues that I think need more analysis is deciding whether it > makes any sense to expose RRSERIAL in resolvers. The original idea was > only in authoritatives, but it might make some sense to debug in > resolvers as well, to somehow identify the "data source" of a cached > record. In this sense, I fear an increase in cache requirements of > resolvers, which should somehow maintain the extra data; and also > in traffic and option availability for upstream auths. > > Hugo > > > On 12:47 07/05, Hugo Salgado wrote: > > I'll upload a new version to revive it, and ask for a slot > > in IETF111 for further discussion! > > > > Thanks, > > > > Hugo > > > > On 22:02 06/05, Mauricio Vergara Ereche wrote: > > > Hi Hugo, > > > > > > I just want to bring back to life this topic as it solves an issue that > > > several operators (like me) seem to be in need to solve while debugging > > > issues. > > > > > > Mauricio > > > > > > On Mon, Jan 27, 2020 at 7:09 AM 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 > > > > Title: The "RRSERIAL" EDNS option for the SOA serial of a RR's > > > > zone > > > > Document date: 2020-01-27 > > > > Group: Individual Submission > > > > Pages: 5 > > > > URL: > > > > https://www.ietf.org/internet-drafts/draft-salgado-rrserial-01.txt > > > > Status: https://datatracker.ietf.org/doc/draft-salgado-rrserial/ > > > > Htmlized: https://tools.ietf.org/html/draft-salgado-rrserial-01 > > > > Htmlized: > > > > https://datatracker.ietf.org/doc/html/draft-salgado-rrserial > > > > Diff: > > > > https://www.ietf.org/rfcdiff?url2=draft-salgado-rrserial-01 > > > > > > > > Abstract: > > > >The "RRSERIAL" EDNS option allows a DNS querier to ask a DNS > > > >authoritative server to add a 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 problems and diagnosis by > > > >helping to recognize the origin of an answer, associating this answer > > > >with a respective zone version. > > > > - > > > > > > > > Best, > > > > > > > > Hugo Salgado > > > > > > > > ___ > > > > DNSOP mailing list > > > >
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
Hi Vladimir, On 10 May 2021, at 04:32, Vladimír Čunát wrote: > On 10. 05. 21 10:19, Petr Špaček wrote: >> I think the proper solution should be a real multi-query option, which >> incidentally provides a superset of RRSERIAL capabilities. > > If multi-queries require the records being in sync (if from the same zone), I > really dislike the implications of them being sent to resolvers, especially > for many questions at once. Caching, in particular. Yes, I agree with that. Perhaps we could specify that a request for an RRSERIAL MUST only be satisfied for a response with AA=1, so that only servers that are able to provide an authoritative response to the original query will return it. In contrast, I think there are probably use cases for a server that can't provide an authoritative response (e.g. a recursive server) to process a more generic multi-question query. So this seems like a reason to consider the two problem statements separately. I don't know exactly what use cases Petr had in mind for that though, so I'm guessing slightly. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
Hello everyone. Thanks for the comments, I just uploaded an unchanged version (just to revive it) at: https://datatracker.ietf.org/doc/draft-salgado-dnsop-RRSERIAL/ I agree RRSERIAL doesn't have much relevance in zones that don't give serial versioning a meaning to its content. We can add a paragraph about it, to make the applicability more clear. I also don't think we should start to "deprecate" the SOA serial meaning at this point. One can say that "modern" implementations using complex backends makes SOA serials irrelevant, but there's certainly a use case for classic and mainly static behavior. Just as NSID adds an "infrastructure" identification dimension to a response, RRSERIAL adds the data versioning dimension. And responding to the comment that having multi-queries is better, is something that is long overdue, and would certainly make this hack obsolete. But I think the multi-query issues are so complex that it's worth moving forward incrementally in the meantime. For the same reason, I think we could aim for it to have "experimental" status at the start, and after a few years we measure it to see its use and we can adapt or change it to standard or deprecate it in favor of another qtype. Other issues that I think need more analysis is deciding whether it makes any sense to expose RRSERIAL in resolvers. The original idea was only in authoritatives, but it might make some sense to debug in resolvers as well, to somehow identify the "data source" of a cached record. In this sense, I fear an increase in cache requirements of resolvers, which should somehow maintain the extra data; and also in traffic and option availability for upstream auths. Hugo On 12:47 07/05, Hugo Salgado wrote: > I'll upload a new version to revive it, and ask for a slot > in IETF111 for further discussion! > > Thanks, > > Hugo > > On 22:02 06/05, Mauricio Vergara Ereche wrote: > > Hi Hugo, > > > > I just want to bring back to life this topic as it solves an issue that > > several operators (like me) seem to be in need to solve while debugging > > issues. > > > > Mauricio > > > > On Mon, Jan 27, 2020 at 7:09 AM 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 > > > Title: The "RRSERIAL" EDNS option for the SOA serial of a RR's > > > zone > > > Document date: 2020-01-27 > > > Group: Individual Submission > > > Pages: 5 > > > URL: > > > https://www.ietf.org/internet-drafts/draft-salgado-rrserial-01.txt > > > Status: https://datatracker.ietf.org/doc/draft-salgado-rrserial/ > > > Htmlized: https://tools.ietf.org/html/draft-salgado-rrserial-01 > > > Htmlized: > > > https://datatracker.ietf.org/doc/html/draft-salgado-rrserial > > > Diff: > > > https://www.ietf.org/rfcdiff?url2=draft-salgado-rrserial-01 > > > > > > Abstract: > > >The "RRSERIAL" EDNS option allows a DNS querier to ask a DNS > > >authoritative server to add a 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 problems and diagnosis by > > >helping to recognize the origin of an answer, associating this answer > > >with a respective zone version. > > > - > > > > > > Best, > > > > > > Hugo Salgado > > > > > > ___ > > > DNSOP mailing list > > > DNSOP@ietf.org > > > https://www.ietf.org/mailman/listinfo/dnsop > > > > > > > > > -- > > Mauricio Vergara Ereche > > keybase.io/mave > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (YANG Types for DNS Classes and Resource Record Types) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'YANG Types for DNS Classes and Resource Record Types' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-05-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document introduces the YANG module "iana-dns-class-rr-type" that contains derived types reflecting two IANA registries: DNS CLASSes and Resource Record (RR) TYPEs. These YANG types are intended as a minimum basis for future data modeling work. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Hi Pieter, On 10 May 2021, at 11:23, Pieter Lexis wrote: > You then invite the following issues: > > Clients need to match the tuple (ownername + prio + target) and get all > data from all matched rrsets, whereas now you get all that data in one > piece of rdata. Inviting that issue is also a potential benefit, but I agree that the implication exists. For example, the ability to publish sets of SvcParams with long TTLs ought to increase the probability of cache hits for that data and reduce SVCB response sizes. > A client also can't figure out (if not doing DNSSEC valdiation > themselves) if you have received all the SVC data for a certain name. A client can't figure out without DNSSEC whether anything they have received is correct in, in general. So setting aside that more general authentication problem, I don't think it's correct to say that a client cannot tell whether they have received a complete RRSet in the answer section of a response. It's either there and complete or it's absent (and perhaps TC=1 if the reason for its absence is message truncation). There should be no response possible in an implementation that adheres to the protocol in which a truncated RRSet appears in the answer section. If we're widening the net to implementations that don't follow the rules then I agree anything is possible. Joe___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Hi Joe, On 5/10/21 1:42 AM, Joe Abley wrote: > On May 9, 2021, at 19:27, Paul Hoffman wrote: > >> If I'm wrong about this being as good as it can be, there must be an item >> delimiter that is better than a comma. I am not thinking creatively enough >> to figure out what might be better than a comma. I'd be happy to hear >> proposals for a better item delimiter. > > I am quite behind on this topic, but I presume there's a reason to put all > these key-value pairs in a list in one RR? > > If we compare the two fictional RRTypes EG1 and EG2 illustrated below: > > example.com. EG1 key1=value1,key2=value2,... > > example.com. EG2 key1 value1 > example.com. EG2 key2 value2 > > It seems to me that EG2 avoids the need for delimiters at all. There's a bit > of overhead resulting from the need for a larger RRSet but it's not obvious > that that's a proble> > If the SvcParams field of the SVCB RR was a domain name rather than an > explicit list this would all look a lot more DNS-like as far as parsing goes. > This would also allow a single set of SvcParams key-value pairs to be > included in different service bindings without having to be sent each time or > to be bound to something provided a service provider (SVB in customer.org > zone that refers to SvcParams.provider.com) giving the provider some ability > to maintain some aspects of the service). You then invite the following issues: Clients need to match the tuple (ownername + prio + target) and get all data from all matched rrsets, whereas now you get all that data in one piece of rdata. A client also can't figure out (if not doing DNSSEC valdiation themselves) if you have received all the SVC data for a certain name. Cheers, Pieter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance
I support the adoption of this document as a starting point for NSEC3 guidance. It will be useful for people who help operators when those operators ask "why didn't you tell us what were good choices for the values?". --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Hi Dick, On 5/10/21 1:02 PM, Dick Franks wrote: > My objection is narrowly focussed on the escape mechanism, nothing > more. Changing the delimiter is neither necessary nor relevant. > > I am happy to contribute the necessary words. If you have the words to fix this issue that would need to changes the code but clears everything up, do it :). Cheers, Pieter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
On Mon, 10 May 2021 at 00:28, Paul Hoffman wrote: > > On May 9, 2021, at 11:26 AM, Paul Wouters wrote: > > This is all pretty terrible. I agree with Tim that we should not inflict > > this onto the users. Or perhaps we can already pre-allocate some CVE > > numbers for the security issues this will generate. > > > > Keep the record simple, we are not going for Turing complete here. I > > recommend to authors take this discussion as advise to improve / simplify > > this aspect of the draft. > > I don't think this request is actually doable. The requirements for the SVCB > Rdata are: > 1. Must be entered by the zone operator as ASCII text (not all a jumble of > hex values) > 2. Is a list of key/value pairs > 3. Values are likely to be a list of items > It is very much doable. BIND, NSD, and PowerDNS can already parse values containing '\,' escapes, and each of these has a substantial installed base. My objections can be entirely satisfied by modest changes to reconcile the document with RFC1035. > Given these three things, it seems that there will *always* be an escaping > problem for the item delimiter in #3. In the current draft, the item > delimiter is a comma, so there has to be a way to escape a comma that is in > an item. Few types of items would ever need a comma in their values. If a > different character is chosen for the item delimiter, it too will need to be > escaped. > > If I'm wrong about this being as good as it can be, there must be an item > delimiter that is better than a comma. I am not thinking creatively enough to > figure out what might be better than a comma. I'd be happy to hear proposals > for a better item delimiter. My objection is narrowly focussed on the escape mechanism, nothing more. Changing the delimiter is neither necessary nor relevant. I am happy to contribute the necessary words. --Dick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
On May 10, 2021, at 05:42, Pieter Lexis wrote: >> On 5/9/21 2:01 PM, Dick Franks wrote: >> Pre-processing of '\\,' into the RFC1035 standard '\,' is >> superficially attractive, but also fraught with danger. >> >> A parser could have some fun with this one: >> >>$ORIGIN example.com >>@ SVCB 1 foo >> key6="\032\001\013\184\000\000\000\000\000\000\000\000,\000" >>; a.k.a. ipv6hint=2001:db8::5c5c:2c00 > > A zone owner/editor would never even think of typing in IP addresses > like that. Right, but an attacker who wants to take advantage of the impact of that observation in the construction of some parser might, which is why it's a security concern. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Hi Dick, On 5/9/21 2:01 PM, Dick Franks wrote: > Pre-processing of '\\,' into the RFC1035 standard '\,' is > superficially attractive, but also fraught with danger. > > A parser could have some fun with this one: > > $ORIGIN example.com > @ SVCB 1 foo > key6="\032\001\013\184\000\000\000\000\000\000\000\000,\000" > ; a.k.a. ipv6hint=2001:db8::5c5c:2c00 A zone owner/editor would never even think of typing in IP addresses like that. And no decoder should ever write that out (and if it does, would a zone-owner read it?). Also, when using the generic format, the full value should be the 'wire' format so there's comma delimiter between values. For ALPN you'd have [value1 len][value 1][value2 len][value2] and for key6 [encoded first ipv6 address bytes][encoded second ipv6 address bytes]. > The spec only needs to say that a comma needs to be escaped ( \, ) in > order to be disregarded as a separator. > BIND, NSD, Net::DNS, and PowerDNS can all do this, so there is little > mileage in claiming that it is not possible. > > The "impossible" can be made possible by doing the right things in the > correct order. > Selecting the right things and the correct order is left as an > exercise for the student. >From what I gather, this is the case? With the caveat that there is a 2-step process for parsing the values for keys defined as paramlists. Cheers, Pieter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
On Mon, 10 May 2021 at 00:42, Joe Abley wrote: > > On May 9, 2021, at 19:27, Paul Hoffman wrote: > > > If I'm wrong about this being as good as it can be, there must be an item > > delimiter that is better than a comma. I am not thinking creatively enough > > to figure out what might be better than a comma. I'd be happy to hear > > proposals for a better item delimiter. > > I am quite behind on this topic, but I presume there's a reason to put all > these key-value pairs in a list in one RR? > > If we compare the two fictional RRTypes EG1 and EG2 illustrated below: > > example.com. EG1 key1=value1,key2=value2,... > > example.com. EG2 key1 value1 > example.com. EG2 key2 value2 > > It seems to me that EG2 avoids the need for delimiters at all. There's a bit > of overhead resulting from the need for a larger RRSet but it's not obvious > that that's a problem. The current draft can reach the finishing line without tearing it to pieces. >8 > > Perhaps this horse has already sailed but I thought I'd mention it. Perhaps this horse needs to be tested for banned substances! --Dick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance
Hi all, As a follow-up to the presentation by Wes Hardaker at the IETF 110 DNSOP meeting, we want to start a call for adoption of draft-hardaker-dnsop-nsec3-guidance on the mailing list. With the presentation at the DNSOP meeting on IETF 110, there was a sufficient general support in the (virtual) room to adopt the draft as a working group document. Now we will start a period of two weeks for the call for adoption of draft-hardaker-dnsop-nsec3-guidance on the mailing list. The draft is available here: https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/. 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: 24 May 2021 Thanks, -- Benno DNSOP co-chair ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
On 10. 05. 21 10:19, Petr Špaček wrote: I think the proper solution should be a real multi-query option, which incidentally provides a superset of RRSERIAL capabilities. If multi-queries require the records being in sync (if from the same zone), I really dislike the implications of them being sent to resolvers, especially for many questions at once. Caching, in particular. --Vladimir | knot-resolver.cz ___ 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
