Re: [DNSOP] avoiding fragmented DNS-over-UDP
Flattered to be mentioned. Specially thanks to Geoff and Joao for their effort to demontrate ATR with measurement and facts. You did what I desired but failed to do. If you think ATR is worth of doing, I'm looking forward to more comments to improve it towards a formal document. -Davey On 22 March 2018 at 20:39, Tony Finch wrote: > Tony Finch wrote: > > > > Here are some sketchy notes on what this might say... > > Geoff Huston just told me I need to read Davey Song's very clever > "additional truncated response" and that he would roast my suggestions > if I didn't mention ATR :-) > https://tools.ietf.org/html/draft-song-atr-large-resp > http://iepg.org/2018-03-18-ietf101/geoff.pdf > > Geoff is very keen on ATR. I think we should work on ATR, and as well as > that it would still be a good idea to work on both client-side mitigations > (for servers that don't have mitigations) and on server-side response size > reduction to avoid unnecessary ATR / TCP. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h > punycode > Irish Sea: South or southwest 5 to 7, occasionally gale 8 for a time. > Slight > or moderate, becoming rough. Occasional rain. 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] draft-ietf-dnsop-kskroll-sentinel-07
> On 23 Mar 2018, at 11:55 am, Mark Andrews wrote: > > This title of this document DOES NOT match reality. > > "A Sentinel for Detecting Trusted Keys in DNSSEC” should be > replaced by “A Root Key Trust Anchor Sentinel for DNSSEC”. > > kskroll-sentinel-- really needs something other > than “kskroll” as the first field. “root-key-sentinel--” > really more clearly matches what it does. > > Any other changes that follow from these two changes" If we want to make this generic then we need at least two sets of labels. One set for the root so we can avoid the single label issue and one set for other TA’s which encode the TA’s name in the query. e.g. “ta-sentinel--..” -- 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] New Version Notification for draft-spacek-edns-camel-diet-00.txt
> On 22 Mar 2018, at 10:30 pm, Ralph Dolmans wrote: > > Hi, > > On 21-03-18 16:58, Petr Špaček wrote: >> draft-spacek-edns-camel-diet-00 is a new draft which partially reacts to >> The Camel talk from yesterday, and is based on plan of open-source DNS >> software vendors to get rid of EDNS workarounds. > >> From the introduction: > >> EDNS version 0 was standardized in 1999, but non-RFC 1035 compliant >> implementations still exist and cause lot of extra queries and >> complicated logic in recursive resolvers. RFC 6891 clearly states >> that FORMERR is the only acceptable answer for implementations >> without support for EDNS. > > This is, although factual correct, somewhat misleading. Yes EDNS0 is > standardized in 1999, but that is not the later mentioned RFC6891 (from > 2013) that requires a FORMERR RCODE. RFC2761 from 1999 talks about > "NOTIMPL, FORMERR, or SERVFAIL". I also fail to understand the relation > with RFC1035 in the first sentence. RFC 1035 says to return FORMERR to a EDNS request. Yes, RFC 1035 said how to handle unknown extensions. That is what the expected behaviour of a STD 13 compliant server *is*. Non STD 13 compliant servers returned NOTIMPL and SERVFAIL. RFC2761 reported what was seen in the wild. FORMERR was the dominate rcode at the time. I don’t see anything other than FORMERR or NOERROR these days to a plain EDNS(0) query from a non-EDNS aware server. > Also the "The Protocol" section does not mention that the retrieved > RCODE (if any) is relevant in the decision whether to retry with or > without EDNS. > > -- Ralph > > ___ > 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
[DNSOP] draft-ietf-dnsop-kskroll-sentinel-07
This title of this document DOES NOT match reality. "A Sentinel for Detecting Trusted Keys in DNSSEC” should be replaced by “A Root Key Trust Anchor Sentinel for DNSSEC”. kskroll-sentinel-- really needs something other than “kskroll” as the first field. “root-key-sentinal--” really more clearly matches what it does. Any other changes that follow from these two changes" -- 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
[DNSOP] Attrleaf table entry fields (was: Re: I-D Action: draft-ietf-dnsop-attrleaf-04.txt)
On 3/22/2018 2:41 PM, Ray Bellis wrote: - the table formatting is pretty poor, do we really need any more than just "NAME", "RR" and "REFERENCE"? The ID field just seems to be an alternate mnemonic for the (already unique) underscore label itself I've looked over the latest version of the table with the above in mind. Wrestled a bit, and finally landed on 'yes', but want to record the thoughts justifying removing fields: ID: the _Node Name field really does serve that purpose well enough Purpose: The text that was there for most of the entries was mechanically redundant with information in other fields for the entry. Control: I've added overall text in a bulleted list before the table, that handles the 'authority' issue for each entry. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-04.txt
On 3/22/2018 2:41 PM, Ray Bellis wrote: Dave, I think this is much improved :) A few nits: Each globally-registered underscore name owns a distinct, subordinate name space. except when it doesn't (i.e. the SRV transports all share the *same* subordinate name space). Well, ummm, I think this demonstrates the difference between theory and practice. In theoretical terms -- as far as the global registration scheme goes -- they /do/ have their own name spaces. In practical terms, they adhere to some additional conventions that choose to use the same subordinate one. I suppose some sort of language that notes this possibility -- since it's a popular choice -- is worth adding, to moderate the tone of independence in the current draft. - on that note, _sctp and _dccp are missing from the global table. ack. - the table formatting is pretty poor, do we really need any more than just "NAME", "RR" and "REFERENCE"? The ID field just seems to be an alternate mnemonic for the (already unique) underscore label itself I added control because the message header field registration work has it and it occurred to me it's worth marking. - the IANA considerations still refer to the now non-existent common second-level table darn. thought i'd expunged them all. the word 'second' appears to now be fully absent from the next version of the draft... Not a nit: - is there a reference for IANA "First Come First Served" rules, and should we perhaps also mandate "specification required" as a pre-condition for registration? We don't want that table filled with any old junk without a stable specification. What is the downside of leaving the requirement out? I'm a minimalist in terms of the role of a registry. To the extent possible, I think that it only has to do registration with accountability. There are cases where more stringent requirements make sense, but I don't see this as one of them: there not any danger I can see in a useless registration entry and there's lots of namespace. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] The DNS Camel writeup
Hi everyone, I did a small writeup of the "DNS Camel" presentation from this Tuesday in London. It can be found here: https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/ (includes link to video, https://www.youtube.com/watch?v=8N_PO3s_Z24&feature=youtu.be&t=1h20m4s ) One of the funniest things I learned today was that we've apparently been producing two new pages of DNS RFC *every week* steadily for the past 20 years. Link has a graph. >From the abstract: "In past years, DNS has been enhanced with DNSSEC, QName Minimization, EDNS Client Subnet and in-band key provisioning through magic record types. It is now also seeing work on 'DNS Stateful Operations', XPF, ANAME (ALIAS), resolver/client encryption, resolver/authoritative encryption & KSK signalling/rollovers. Each of these features interacts with all the others. Every addition therefore causes a further combinatorial explosion in complexity. Up to now, the increase in DNS complexity (mostly driven by DNSSEC) has been made possible by the huge pool of programming talent, mostly in the open source world. This presentation sets out, with examples, how innoccuous features contribute to the combinatorial rise of complexity, and how we might ponder thinking twice before loading up this camel further." Bert ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-04.txt
Dave, I think this is much improved :) A few nits: > Each globally-registered underscore name owns a distinct, subordinate > name space. except when it doesn't (i.e. the SRV transports all share the *same* subordinate name space). - on that note, _sctp and _dccp are missing from the global table. - the table formatting is pretty poor, do we really need any more than just "NAME", "RR" and "REFERENCE"? The ID field just seems to be an alternate mnemonic for the (already unique) underscore label itself - the IANA considerations still refer to the now non-existent common second-level table - it's still only been five years, although it *does* feel like 12 :p Not a nit: - is there a reference for IANA "First Come First Served" rules, and should we perhaps also mandate "specification required" as a pre-condition for registration? We don't want that table filled with any old junk without a stable specification. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-04.txt
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 : DNS Scoped Data Through '_Underscore' Naming of Attribute Leaves Author : Dave Crocker Filename: draft-ietf-dnsop-attrleaf-04.txt Pages : 9 Date: 2018-03-22 Abstract: Formally, any DNS resource record may occur for any domain name. However some services have defined an operational convention, which applies to DNS leaf nodes that are under a DNS branch having one or more reserved node names, each beginning with an underscore. The underscore naming construct defines a semantic scope for DNS records that are associated with the parent domain, above the underscored branch. This specification explores the nature of this DNS usage and defines the "DNS Global Underscore Scoped Entry Registry" with IANA. The purpose of the Underscore registry is to avoid collisions resulting from the use of the same underscore-based name, for different services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-04 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC
On Thu, Mar 22, 2018 at 05:47:58PM +, Ondřej Surý wrote: ... > > They should switch away from SHA1 as SHA1 is being deprecated industry > > wide. Even if we recommend to move away from RSA (which I'm not sure if > > there > > is consensus on) to ECC, I would like to move them to ED25519/ED448 over > > the ECDSA* variants. > > I don’t think this is currently feasible to do so, so we need to have a > feedback from WG. > > > If it is too soon for that now, I would simply not > > recommend moving away from RSA. And maybe make ECDSAP256SHA256 a MAY > > instead of a MUST. > > What would be the technical/security reason for skipping ECDSA? > > Ondrej Besides of this question this is a recommendation to be change in the future. Current ED25519/ED448 deployment is negligible if any. It will take at least 5 year for the situation to improve. Fred ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC
-- Ondřej Surý ond...@isc.org > On 22 Mar 2018, at 17:27, Paul Wouters wrote: > > On Thu, 22 Mar 2018, Ondřej Surý wrote: > >> https://github.com/oerdnj/draft-ietf-dnsop-algorithm-update >> >> Pull/Merge Requests, Issues, etc. are welcome. >> >> The most of the work done between the last version and this is: >> >> * Removal of MUST-, SHOULD+, etc… >> * Upgrade the urgency of deploying ECC >> * Separate operational recommendations for default algorithm to >> ECDSAP256SHA256 >> * Deprecation of ECC-GOST (that actually happened elsewhere, so we reflect >> it here) > > As for the DS algorithm 4, SHA-384 does not really add anything over > SHA-256, so it would be good to move that further down from MAY to MUST > NOT on the creation (not validation) part. I'm afraid the current > listing might appear as "it is MAY now but will become MUST in the > future". > > Based on Viktor's data, the ratio of SHA256 to SHA384 is 500:1 with > only 8649 DS SHA384 records. Even GOST which is MUST NOT has 4x more > DS records deployed with 36388 records. Sounds good to me, you already have access to the repo :). > I think this text also needs an update: > > RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones > deploying it are recommended to switch to ECDSAP256SHA256 as there is > an industry-wide trend to move to elliptic curve cryptography. > > They should switch away from SHA1 as SHA1 is being deprecated industry > wide. Even if we recommend to move away from RSA (which I'm not sure if there > is consensus on) to ECC, I would like to move them to ED25519/ED448 over > the ECDSA* variants. I don’t think this is currently feasible to do so, so we need to have a feedback from WG. > If it is too soon for that now, I would simply not > recommend moving away from RSA. And maybe make ECDSAP256SHA256 a MAY > instead of a MUST. What would be the technical/security reason for skipping ECDSA? Ondrej ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC
On Thu, 22 Mar 2018, Ondřej Surý wrote: https://github.com/oerdnj/draft-ietf-dnsop-algorithm-update Pull/Merge Requests, Issues, etc. are welcome. The most of the work done between the last version and this is: * Removal of MUST-, SHOULD+, etc… * Upgrade the urgency of deploying ECC * Separate operational recommendations for default algorithm to ECDSAP256SHA256 * Deprecation of ECC-GOST (that actually happened elsewhere, so we reflect it here) As for the DS algorithm 4, SHA-384 does not really add anything over SHA-256, so it would be good to move that further down from MAY to MUST NOT on the creation (not validation) part. I'm afraid the current listing might appear as "it is MAY now but will become MUST in the future". Based on Viktor's data, the ratio of SHA256 to SHA384 is 500:1 with only 8649 DS SHA384 records. Even GOST which is MUST NOT has 4x more DS records deployed with 36388 records. I think this text also needs an update: RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones deploying it are recommended to switch to ECDSAP256SHA256 as there is an industry-wide trend to move to elliptic curve cryptography. They should switch away from SHA1 as SHA1 is being deprecated industry wide. Even if we recommend to move away from RSA (which I'm not sure if there is consensus on) to ECC, I would like to move them to ED25519/ED448 over the ECDSA* variants. If it is too soon for that now, I would simply not recommend moving away from RSA. And maybe make ECDSAP256SHA256 a MAY instead of a MUST. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt
Bob Harold wrote: ... Unfortunately, the resolver needs to make decisions based on the original transport, for example if the transport is TCP, it can send any size response. But if UDP, it needs to fit in a smaller size, and it often sends less info in the response. Likewise, session signalling, anti-spoofing decisions, etc depend on the transport. except that i don't find it unfortunately but simply factual, i agree. That brings up another question. Would it also need to know the MTU of the original connection, or any other info? (Assuming EDNS is not used) In that case, a different media type is not enough, and we need to change the format to add some 'header" info. not in my opinion. if the far end has a larger MTU outbound than the near end had inbound, then truncation damage will occur -- and the original initiator will retry with TCP. we just need to be transparent so that the original initiator can drive its own transport selections. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt
On Thu, Mar 22, 2018 at 12:42 PM, Dave Lawrence wrote: > Davey Song writes: > > To keep the transparency of DOH proxy, the proxy server should use > > the same transport as the proxy client receive queries from > > stub-resolver, transports patterns like UDP-DOH-UDP, and > > TCP-DOH-TCP. So the proxy client should signal the proxy server the > > initial transport recieve from stub-client. > > I'm really not digging this as a good use of a media type, especially > when the draft says: > > "If proxy client receives the query via TCP, then it >will carry a new media type defined in this document "application/ >dns-tcpwireformat" and speak DOH with proxy server with the same >DNS query without the two-byte length field defined in DNS over >TCP" > > So, dns-tcpwireformat and dns-udpwireformat are byte-for-byte > identical on the wire, and you're just using it as a signal for the > transport you want the DOH Proxy Server to use when talking to a > resolver (if indeed it is talking to separate resolver at all), is > that right? If a transparent DOH proxy client is talking to a > co-operating DOH proxy server, shouldn't they have a better signaling > mechanism than that? Is there any other media type that directs a > server on transport issues? > > The use case also doesn't really address why it is important to > preserve the stub's udp-vs-tcp choice to its presumptive resolver, but > rather only refers only vaguely to the transparency issue. It would > be nice to have a clearer statement of what's driving this proposal. > > Unfortunately, the resolver needs to make decisions based on the original transport, for example if the transport is TCP, it can send any size response. But if UDP, it needs to fit in a smaller size, and it often sends less info in the response. Likewise, session signalling, anti-spoofing decisions, etc depend on the transport. That brings up another question. Would it also need to know the MTU of the original connection, or any other info? (Assuming EDNS is not used) In that case, a different media type is not enough, and we need to change the format to add some 'header" info. -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt
Dave Lawrence wrote: I'm really not digging this as a good use of a media type, especially when the draft says: ... nor i. apparently there were only worse choices, in the eyes of http folks. So, dns-tcpwireformat and dns-udpwireformat are byte-for-byte identical on the wire, and you're just using it as a signal for the transport you want the DOH Proxy Server to use when talking to a resolver (if indeed it is talking to separate resolver at all), is that right? yes. If a transparent DOH proxy client is talking to a co-operating DOH proxy server, shouldn't they have a better signaling mechanism than that? Is there any other media type that directs a server on transport issues? i had originally proposed an http query header to inform the far end as to what transport the near end had received the question on. this was seen as "not http-friendly". thus we have the proposal you now see. The use case also doesn't really address why it is important to preserve the stub's udp-vs-tcp choice to its presumptive resolver, but rather only refers only vaguely to the transparency issue. It would be nice to have a clearer statement of what's driving this proposal. this is not a service, it's a proxy. that is, the far end should not start with udp (which is the usual dns initiator thing to do) and then make its own decision of whether to retry with tcp (for example on TC=1). the near end may already have tried udp and got TC=1. or the near end may have its own reasons for wanting to try tcp first. if we were specifying a transport to a servive, like the DOH draft does, then we would not care about this. but this is a firewall bypass tool, not a dns-via-http service. thus, the near side of the proxy has to tell the far end of the proxy how we heard the query, so that it can use the same transport when it regenerates it for us on the far end. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Attrleaf _second-Level modifications
On 22/03/2018 15:12, Dave Crocker wrote: > In the case of SRV, for example, that means that for the core SRV > template specification document: > > 1. The first-level, _Proto name assignment text has to be updated > to use the new, Attrleaf global table. > > 2. The second-level _Service name assignment text can remain > unchanged, per RFC 6335. > > Point #2 is actually not 'special' at all. I'd entirely missed that the > very strong need to do the first-level fixup did not also require > messing with the existing second-level. That's the conversation I thought we'd had in Orlando :p Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt
Davey Song writes: > To keep the transparency of DOH proxy, the proxy server should use > the same transport as the proxy client receive queries from > stub-resolver, transports patterns like UDP-DOH-UDP, and > TCP-DOH-TCP. So the proxy client should signal the proxy server the > initial transport recieve from stub-client. I'm really not digging this as a good use of a media type, especially when the draft says: "If proxy client receives the query via TCP, then it will carry a new media type defined in this document "application/ dns-tcpwireformat" and speak DOH with proxy server with the same DNS query without the two-byte length field defined in DNS over TCP" So, dns-tcpwireformat and dns-udpwireformat are byte-for-byte identical on the wire, and you're just using it as a signal for the transport you want the DOH Proxy Server to use when talking to a resolver (if indeed it is talking to separate resolver at all), is that right? If a transparent DOH proxy client is talking to a co-operating DOH proxy server, shouldn't they have a better signaling mechanism than that? Is there any other media type that directs a server on transport issues? The use case also doesn't really address why it is important to preserve the stub's udp-vs-tcp choice to its presumptive resolver, but rather only refers only vaguely to the transparency issue. It would be nice to have a clearer statement of what's driving this proposal. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Attrleaf _second-Level modifications (was: Re: Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-03.txt)
On 3/20/2018 9:31 AM, John R. Levine wrote: 2. SRV and URI These need more detailed text, very much in the s/old/new style. The current text in them does a use-by-reference of existing tables defined for other purposes. The Update text will, instead, specify a requirement for adding entries in the Global or Common Second-Level registries. The second level registry, though, is a problem, because it tries to redefine the naming rules for SRV records. RFC 2782 said that SRV second level names are from the services in Assiged Numbers STD 2. RFC 3400 abolished STD 2 in favor of an IANA registry. That registry, the Service Name and Transport Protocol Port Number Registry, was cleaned up by RFC 6335 which reiterates the fact that the service names in that registry are the services used to name SRV records. RFC 7335 states that URI records are named the same as SRV, and also says you can use enumservice _subtype._type. We need to change the description of the second level name registry to say that SRV and URI are special, they use names from Ports and Services at the second level and URI uses enumservice subtypes, and take out all of the SRV entries. What's left is the grabbag of second level names used for other stuff like NAPTR and _adsp._domainkey. Folks, Level set: * I think what hung me up was mostly missing the reference to 'second-level' while focusing too much on the presence of the word 'special'. * For any use of an underscore first-level name, that also uses a second-level name, the authority over that second-level belongs entirely and solely to that first-level name. ..._my-second._firsta.example and ..._my-second._firstb.example have no conflict. So here's what needs to be clearer in the main attrleaf document and the fixup document: All /first-level/ uses of underscore names MUST be registered in the single, /global/ registry, for in order to avoid collisions. For second-level names, any name assignment scheme can be used, as long as it prevents collisions /within the scope of its own first-level name/. In the case of SRV, for example, that means that for the core SRV template specification document: 1. The first-level, _Proto name assignment text has to be updated to use the new, Attrleaf global table. 2. The second-level _Service name assignment text can remain unchanged, per RFC 6335. Point #2 is actually not 'special' at all. I'd entirely missed that the very strong need to do the first-level fixup did not also require messing with the existing second-level. As for the proposed 'common, second-level' table... Given that this seems to reduce the Attrleaf 'common second-level' table to only _adsp, I think it best to remove that table entirely from the main attrleaf document, and instead have the separate fixup document contain some text specific to the DKIM document's domain naming scheme, to indicate how future second-level names should be assigned. Since ADSP is historic, specifying modification to it doesn't make sense to modify it. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC
Hi, Tim has poked me and Paul W. that WG have actually accepted Algorithm Implementation Requirements and Usage Guidance for DNSSEC as a working group document. I have updated the draft and submitted is as a WG document and meanwhile it sits there patiently for WG chair approval, you can look at the github version meanwhile: https://github.com/oerdnj/draft-ietf-dnsop-algorithm-update Pull/Merge Requests, Issues, etc. are welcome. The most of the work done between the last version and this is: * Removal of MUST-, SHOULD+, etc… * Upgrade the urgency of deploying ECC * Separate operational recommendations for default algorithm to ECDSAP256SHA256 * Deprecation of ECC-GOST (that actually happened elsewhere, so we reflect it here) I also squeezed paragraph about DS algorithm upgrade to operational considerations based on Roy Arends’ presentation. Ondrej -- Ondřej Surý ond...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt
Thanks for your advice. Davey Bob Harold 于 2018年3月22日周四 22:41写道： > > On Wed, Mar 21, 2018 at 9:36 PM, Davey Song wrote: > >> Hi folks, >> >> I just submit a updated version of dns wireformat over HTTP. This draft >> has been adopted as the dnsop wg document for quite a while before DOH. >> The original intention of this draft is to explore the possiblity of DNS >> over HTTP(s) use cases and demonstrate its capacity as an experimental >> draft. But the draft lacked enough specification on HTTP requirement and >> context at that time. Since DOH later was setup focusing on developing >> https as DNS transport protocol. So I updated this draft as a a special use >> case of DOH which served as DNS proxy. >> >> I would like to ask comments and advice in dnsop and doh wgs mainly two >> quesions: >> 1) (for dns people) Does this proxy use case sounds useful as a IETF >> experiment document . >> 2) (for HTTP people) Is a media type "application/dns-tcpwireformat" >> acceptable specially for this use case. We also consider to introduce an >> optional parameter to existing "application/dns-udpwireformat" MIME in >> DOH document, because the two media type carries the identical message body >> (the >> udp dns wireformat) in DOH request in proxy use case. We need >> suggestion here. >> >> Thank to Tim and Paul Hoffman to bring this draft alive. >> >> Davey >> >> -- Forwarded message -- >> From: >> Date: 22 March 2018 at 08:59 >> Subject: New Version Notification for >> draft-ietf-dnsop-dns-wireformat-http-02.txt >> To: Shane Kerr , Paul Vixie , >> Linjian Song >> >> >> >> A new version of I-D, draft-ietf-dnsop-dns-wireformat-http-02.txt >> has been successfully submitted by Linjian Song and posted to the >> IETF repository. >> >> Name: draft-ietf-dnsop-dns-wireformat-http >> Revision: 02 >> Title: An Proxy Use Case of DNS over HTTPS >> Document date: 2018-03-21 >> Group: dnsop >> Pages: 6 >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-dnsop-dns-wireformat-http-02.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wireformat-http/ >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-dnsop-dns-wireformat-http-02 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-wireformat-http >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-wireformat-http-02 >> >> Abstract: >>This memo introduces a DNS proxy use case to tunnel DNS query and >>response over HTTPs using DOH, a newly proposed DNS transport. This >>is useful in some situation where DNS is not working properly and DOH >>is not widely available for many stub-resolvers. >> > > > The first time "DOH" is used, it should be defined. Either: > DOH (DNS over HTTP) > or: > DNS over HTTP (DOH) > > I think the second is the preferred method. > > -- > Bob Harold > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt
On Wed, Mar 21, 2018 at 9:36 PM, Davey Song wrote: > Hi folks, > > I just submit a updated version of dns wireformat over HTTP. This draft > has been adopted as the dnsop wg document for quite a while before DOH. > The original intention of this draft is to explore the possiblity of DNS > over HTTP(s) use cases and demonstrate its capacity as an experimental > draft. But the draft lacked enough specification on HTTP requirement and > context at that time. Since DOH later was setup focusing on developing > https as DNS transport protocol. So I updated this draft as a a special use > case of DOH which served as DNS proxy. > > I would like to ask comments and advice in dnsop and doh wgs mainly two > quesions: > 1) (for dns people) Does this proxy use case sounds useful as a IETF > experiment document . > 2) (for HTTP people) Is a media type "application/dns-tcpwireformat" > acceptable specially for this use case. We also consider to introduce an > optional parameter to existing "application/dns-udpwireformat" MIME in > DOH document, because the two media type carries the identical message body > (the > udp dns wireformat) in DOH request in proxy use case. We need > suggestion here. > > Thank to Tim and Paul Hoffman to bring this draft alive. > > Davey > > -- Forwarded message -- > From: > Date: 22 March 2018 at 08:59 > Subject: New Version Notification for draft-ietf-dnsop-dns- > wireformat-http-02.txt > To: Shane Kerr , Paul Vixie , > Linjian Song > > > > A new version of I-D, draft-ietf-dnsop-dns-wireformat-http-02.txt > has been successfully submitted by Linjian Song and posted to the > IETF repository. > > Name: draft-ietf-dnsop-dns-wireformat-http > Revision: 02 > Title: An Proxy Use Case of DNS over HTTPS > Document date: 2018-03-21 > Group: dnsop > Pages: 6 > URL:https://www.ietf.org/internet- > drafts/draft-ietf-dnsop-dns-wireformat-http-02.txt > Status: https://datatracker.ietf.org/ > doc/draft-ietf-dnsop-dns-wireformat-http/ > Htmlized: https://tools.ietf.org/html/d > raft-ietf-dnsop-dns-wireformat-http-02 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-ietf-dnsop-dns-wireformat-http > Diff: https://www.ietf.org/rfcdiff? > url2=draft-ietf-dnsop-dns-wireformat-http-02 > > Abstract: >This memo introduces a DNS proxy use case to tunnel DNS query and >response over HTTPs using DOH, a newly proposed DNS transport. This >is useful in some situation where DNS is not working properly and DOH >is not widely available for many stub-resolvers. > The first time "DOH" is used, it should be defined. Either: DOH (DNS over HTTP) or: DNS over HTTP (DOH) I think the second is the preferred method. -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multi Provider DNSSEC Models
I agree, model 1 and model 2 seems doable. Note that RFC 6781 has some text for model 2 on rollover when changing DNS operators. https://tools.ietf.org/html/rfc6781#section-4.3.5 Matthijs On 22-03-18 13:50, Tony Finch wrote: Olafur Gudmundsson wrote: I think only Model #1 makes sense, i.e Zone apex DNSKEY/CDNSKEY/CDS RRset's are signed by zone publisher but rest signed by operator on the fly. From the provider point of view, I think there are a couple of models: (a) provider has KSK and ZSK; zone owner needs to be able to import other provider public keys into this provider's DNSKEY RRset, and export signed DNSKEY RRset. (b) provider only has ZSK; zone owner needs to be able to export public keys, and import signed DNSKEY RRsets. Given this, I think a zone owner can implement either model 1 or model 2 from the draft. Model 3 requires sharing private keys. Tony. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multi Provider DNSSEC Models
On Thu, Mar 22, 2018 at 1:42 PM, Tony Finch wrote: > Shumon Huque wrote: > > On Thu, Mar 22, 2018 at 12:50 PM, Tony Finch wrote: > > > > > > From the provider point of view, I think there are a couple of models: > > > > > > (a) provider has KSK and ZSK; zone owner needs to be able to import > other > > > provider public keys into this provider's DNSKEY RRset, and export > signed > > > DNSKEY RRset. > > > > > > (b) provider only has ZSK; zone owner needs to be able to export public > > > keys, and import signed DNSKEY RRsets. > > > > One thing I would like to discuss is whether this document should > recommend > > just one model to maximise the chances that multiple providers implement > a > > common interoperable scheme that a zone owner can successfully deploy. > > Providers might be persuadable to implement both models, but anything > more > > than two, I would guess, will not be practical. > > I think providers need to implement all the functionality I sketched > above. The zone owner might act as provider (a) holding the KSK private > key; or they might outsource it. > That would be great, but I think we need to get feedback from the providers that they are willing to implement both models, and if not, persuade them to do so, if that's the recommendation in the document. > > The risk the Olafur mentioned of a KSK provider dropping imported DNSKEYs > from other providers is probably a matter for contracts and lawyers :-) > Yes, that was my answer to Olafur in person (I'm sitting next to him right now in DOH :-) > But it sort of illustrates the point that this functionality is really > useful for phased migration from one provider to another without going > insecure. > Yes, indeed. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multi Provider DNSSEC Models
Shumon Huque wrote: > On Thu, Mar 22, 2018 at 12:50 PM, Tony Finch wrote: > > > > From the provider point of view, I think there are a couple of models: > > > > (a) provider has KSK and ZSK; zone owner needs to be able to import other > > provider public keys into this provider's DNSKEY RRset, and export signed > > DNSKEY RRset. > > > > (b) provider only has ZSK; zone owner needs to be able to export public > > keys, and import signed DNSKEY RRsets. > > One thing I would like to discuss is whether this document should recommend > just one model to maximise the chances that multiple providers implement a > common interoperable scheme that a zone owner can successfully deploy. > Providers might be persuadable to implement both models, but anything more > than two, I would guess, will not be practical. I think providers need to implement all the functionality I sketched above. The zone owner might act as provider (a) holding the KSK private key; or they might outsource it. The risk the Olafur mentioned of a KSK provider dropping imported DNSKEYs from other providers is probably a matter for contracts and lawyers :-) But it sort of illustrates the point that this functionality is really useful for phased migration from one provider to another without going insecure. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Shannon: South veering west, 5 to 7, increasing gale 8 or severe gale 9 for a time. Rough or very rough, occasionally high for a time. Squally showers. Moderate or poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multi Provider DNSSEC Models
On Thu, Mar 22, 2018 at 1:00 PM, Shumon Huque wrote: > On Thu, Mar 22, 2018 at 12:50 PM, Tony Finch wrote: > >> Olafur Gudmundsson wrote: >> > >> > I think only Model #1 makes sense, i.e Zone apex DNSKEY/CDNSKEY/CDS >> > RRset's are signed by zone publisher but rest signed by operator on the >> > fly. >> >> From the provider point of view, I think there are a couple of models: >> >> (a) provider has KSK and ZSK; zone owner needs to be able to import other >> provider public keys into this provider's DNSKEY RRset, and export signed >> DNSKEY RRset. >> >> (b) provider only has ZSK; zone owner needs to be able to export public >> keys, and import signed DNSKEY RRsets. >> >> Given this, I think a zone owner can implement either model 1 or >> model 2 from the draft. Model 3 requires sharing private keys. >> > > That's correct. Both model 1 and 2 seem quite viable to me. Maybe Olafur > can > elaborate on why he feels only model 1 makes sense. > > One thing I would like to discuss is whether this document should recommend > just one model to maximise the chances that multiple providers implement a > common interoperable scheme that a zone owner can successfully deploy. > Providers might be persuadable to implement both models, but anything more > than two, I would guess, will not be practical. > > Shumon. > > My preference is that the zone owner can say they are in full control of the zone authority Second reason is if provider B is signing the DNSKEY for the zone then it can remove the key for operator A which is not the intent of the zone owner. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multi Provider DNSSEC Models
On Thu, Mar 22, 2018 at 12:50 PM, Tony Finch wrote: > Olafur Gudmundsson wrote: > > > > I think only Model #1 makes sense, i.e Zone apex DNSKEY/CDNSKEY/CDS > > RRset's are signed by zone publisher but rest signed by operator on the > > fly. > > From the provider point of view, I think there are a couple of models: > > (a) provider has KSK and ZSK; zone owner needs to be able to import other > provider public keys into this provider's DNSKEY RRset, and export signed > DNSKEY RRset. > > (b) provider only has ZSK; zone owner needs to be able to export public > keys, and import signed DNSKEY RRsets. > > Given this, I think a zone owner can implement either model 1 or > model 2 from the draft. Model 3 requires sharing private keys. > That's correct. Both model 1 and 2 seem quite viable to me. Maybe Olafur can elaborate on why he feels only model 1 makes sense. One thing I would like to discuss is whether this document should recommend just one model to maximise the chances that multiple providers implement a common interoperable scheme that a zone owner can successfully deploy. Providers might be persuadable to implement both models, but anything more than two, I would guess, will not be practical. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multi Provider DNSSEC Models
Olafur Gudmundsson wrote: > > I think only Model #1 makes sense, i.e Zone apex DNSKEY/CDNSKEY/CDS > RRset's are signed by zone publisher but rest signed by operator on the > fly. >From the provider point of view, I think there are a couple of models: (a) provider has KSK and ZSK; zone owner needs to be able to import other provider public keys into this provider's DNSKEY RRset, and export signed DNSKEY RRset. (b) provider only has ZSK; zone owner needs to be able to export public keys, and import signed DNSKEY RRsets. Given this, I think a zone owner can implement either model 1 or model 2 from the draft. Model 3 requires sharing private keys. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Biscay: Variable 3, becoming southwesterly 4 or 5, occasionally 6. Moderate or rough. Occasional rain. Good occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] avoiding fragmented DNS-over-UDP
Tony Finch wrote: > > Here are some sketchy notes on what this might say... Geoff Huston just told me I need to read Davey Song's very clever "additional truncated response" and that he would roast my suggestions if I didn't mention ATR :-) https://tools.ietf.org/html/draft-song-atr-large-resp http://iepg.org/2018-03-18-ietf101/geoff.pdf Geoff is very keen on ATR. I think we should work on ATR, and as well as that it would still be a good idea to work on both client-side mitigations (for servers that don't have mitigations) and on server-side response size reduction to avoid unnecessary ATR / TCP. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Irish Sea: South or southwest 5 to 7, occasionally gale 8 for a time. Slight or moderate, becoming rough. Occasional rain. Good occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multi Provider DNSSEC Models
On Thu, 22 Mar 2018, Olafur Gudmundsson wrote: The document covers the case that different providers use different signing algorithms BUT does not cover if they use different negative answer approaches, no good answer other than say NSEC with “lies”. I think the document describes what I think of as a new and clever type of deployment. But it reads as some kind of BCP you could read or skip, mostly based on the title. Maybe change the title to something like Considerations for DNSSEC multi-signer deployments Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-spacek-edns-camel-diet-00.txt
Hi, On 21-03-18 16:58, Petr Špaček wrote: > draft-spacek-edns-camel-diet-00 is a new draft which partially reacts to > The Camel talk from yesterday, and is based on plan of open-source DNS > software vendors to get rid of EDNS workarounds. >From the introduction: > EDNS version 0 was standardized in 1999, but non-RFC 1035 compliant >implementations still exist and cause lot of extra queries and >complicated logic in recursive resolvers. RFC 6891 clearly states >that FORMERR is the only acceptable answer for implementations >without support for EDNS. This is, although factual correct, somewhat misleading. Yes EDNS0 is standardized in 1999, but that is not the later mentioned RFC6891 (from 2013) that requires a FORMERR RCODE. RFC2761 from 1999 talks about "NOTIMPL, FORMERR, or SERVFAIL". I also fail to understand the relation with RFC1035 in the first sentence. Also the "The Protocol" section does not mention that the retrieved RCODE (if any) is relevant in the decision whether to retry with or without EDNS. -- Ralph ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt
To keep the transparency of DOH proxy, the proxy server should use the same transport as the proxy client receive queries from stub-resolver, transports patterns like UDP-DOH-UDP, and TCP-DOH-TCP. So the proxy client should signal the proxy server the initial transport recieve from stub-client. Davey On 22 March 2018 at 18:23, Dave Lawrence wrote: > Davey Song writes: > > Is a media type "application/dns-tcpwireformat" acceptable > > Without yet having (re-)read the draft, I'm unclear on what benefit > this media type is bringing over dns-udpwireformat, since the only > difference presumably is explicitly adding the two octets of a > content-length <= 65535. Is it something other than that? > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-spacek-edns-camel-diet-00.txt
On Wed, Mar 21, 2018 at 08:17:08PM -0400, Matthew Pounsett wrote: > Congratulations on an extremely short, to the point draft. I think that's > the shortest I've ever read. Indeed! I hesitate to offer trivial rephrasing suggestions because it might represent such a significant percentage of the final text you'd have to give me co-author credit. :) That said, however, "No response...means" is ambiguous: it could be read as "[there is] no response [which] means". So I suggest rephrasaing section 2 as: The failure of a server to respond in any way to repeateded DNS queries containing EDNS OPT records indicates that the server is not a DNS responder. The querier MUST treat this server as nonresponsive, and MUST NOT retry queries without EDNS. Or something like that. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt
Davey Song writes: > Is a media type "application/dns-tcpwireformat" acceptable Without yet having (re-)read the draft, I'm unclear on what benefit this media type is bringing over dns-udpwireformat, since the only difference presumably is explicitly adding the two octets of a content-length <= 65535. Is it something other than that? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNSOP Session II at IETF 101: proxy co-chair, jabber scribe & slides
Hi all, As you probably saw from Tim’s email overnight, he’s injured his knee and his priority today is getting medical attention for it. But Session II is under control and we’ll convene at 18:10-19:10 this evening in the Sandringham room, with a proxy Tim if needed. We do still need a jabber scribe for this session. If you’re on the agenda and you don’t see your slides on the meeting materials page (https://datatracker.ietf.org/meeting/materials/) please send them to me— even if you sent them to Tim, he may not have gotten to review them before he went offline. (Feel better Tim!) Suzanne ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
