Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt
On 03/17/2015 04:16 PM, Christian Grothoff wrote: it's a Lex Facebook, just like reserving .local was a Lex Apple. I'm not generally against those at all, but I personally dislike that IETF passes things quickly if they are backed by multi-billion dollar companies, The reservation of “local” took more than a decade if I remember correctly, and it did not benefit just Apple. -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01
Andrew Sullivan a...@anvilwalrusden.com wrote: In section 6, there's this: The server MUST NOT enforce these rules for a particular client because it does not know if the client IP address belongs to a single client or is, for example, multiple clients behind NAT. I don't think that MUST NOT is reasonable. I think the recommended limits in that paragraph are OK only if viewed from the perspective of individual client programs. The above quote is correct in that there's no sensible way for the server to enforce the limit - never mind NAT, if a user starts up a second browser, will it be locked out of TCP queries until the first one closes its connection? I suggest: To mitigate the risk of unintentional server overload, DNS clients MUST take care to minimize the number of concurrent TCP connections made to any individual server. It is RECOMMENDED that for any given client - server interaction a client SHOULD limit itself to no more than one connection for regular queries, one for zone transfers and one for each protocol that is being used on top of TCP, for example, if the resolver was using TLS. Servers MAY impose limits on the number of concurrent TCP connections being handled for any particular client. These limits SHOULD be much looser than the client guidelines above, because it does not know if the client IP address belongs to a single client or is, for example, multiple resolvers on a single machine, or multiple clients behind NAT. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Faeroes: West or southwest 5 or 6, becoming variable 4, then becoming south or southeast 5 or 6. Moderate or rough. Occasional rain. Good, becoming moderate or poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 6761 discussion (“special names”)
Tim Wicinski writes: The WG has several documents that we need to spend time in Dallas moving towards completion. But we also believe the RFC 6761 drafts should not be given short shrift. Accordingly, we are tentatively planning a Virtual Interim Meeting to dive a little deeper on the special names drafts, including possible architectural implications of the apparent increase in interest in RFC 6761, as we attempt to muddle through the questions we’ve seen and the ones we anticipate. Following this discussion from a distance, I cannot help wondering whether this is special names stuff might in violate RFC 2860 section 4.3. jaap ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
On 03/18/15 01:11, Michael Sinatra wrote: I think there are a few issues at play. google and other public recursives will sometimes have multiple backend servers fetch a given RR when they receive a single query for that RR on one instance of, say, 8.8.8.8. I am basing this both on observed behavior and on Geoff Huston's research (recently presented at NANOG). And since nothing is cached, I get the same servers asking the same query over and over again. Writ large, the result is that I end up with 1-2k of simultaneous TCP sessions, per server, per domain. Just a quick qualification: This is during an active attack, not as a normal course of events. However, the attacks can and will last for several weeks. michael ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01
i have read draft-ietf-dnsop-5966bis-01, and i have some comments. tl;dr: this document is nowhere near ready to ship. ... This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. this language is too strong, and breaks working configurations. many DNS servers are completely functional for all intents and purposes even though an upstream firewall or other middlebox prevents them from hearing TCP requests. i suggest some adjective other than REQUIRED here. perhaps STRONGLY RECOMMENDED. There are several advantages and disadvantages to the increased use of TCP as well as implementation details that need to be considered. This document addresses these issues and therefore extends the content of [RFC5966], with additional considerations and lessons learned from new research and implementations [Connection-Oriented-DNS]. i object to this reference. [Connection-Oriented-DNS] is a controversial paper, which i've reviewed separately, and should not be referenced in standards work. Whilst this document makes no specific requirements for operators of DNS servers to meet, if that's true, then you really can't say REQUIRED (see above). ... However, transport of UDP packets that exceed the size of the path MTU causes IP packet fragmentation, which has been found to be unreliable in some circumstances. can i ask, as the RFC 2671 author, that you change the word some to be instead the word many ? 6. Connection Handling One perceived disadvantage to DNS over TCP is the added connection setup latency, generally equal to one RTT. To amortize connection setup costs, both clients and servers SHOULD support connection reuse by sending multiple queries and responses over a single TCP connection. DNS currently has no connection signaling mechanism. Clients and servers may close a connection at any time. this is factually wrong. servers are not permitted to close a connection at any time. (this is what the spec says, and the expectations of any implementation that faithfully followed the spec must be called reasonable). Clients MUST be prepared to retry failed queries on broken connections. this is factually wrong. a client can give up on a server for at least the duration of the current transaction if it closes a connection prematurely. Section 4.2.2 of [RFC1035] says: If the server needs to close a dormant connection to reclaim resources, it should wait until the connection has been idle for a period on the order of two minutes. In particular, the server should allow the SOA and AXFR request sequence (which begins a refresh operation) to be made on a single connection. Since the server would be unable to answer queries anyway, a unilateral close or reset may be used instead of a graceful close. Other more modern protocols (e.g., HTTP/1.1 [RFC7230]) have support for persistent TCP connections and operational experience has shown that long timeouts can easily cause resource exhaustion and poor response under heavy load. Intentionally opening many connections and leaving them dormant can trivially create a denial-of-service attack. noting: this is why i frequently refer to the RFC 1035 connection management logic as unfortunate. It is therefore RECOMMENDED that the default application-level idle period should be of the order of seconds, but no particular value is specified. In practice, the idle period may vary dynamically, and servers MAY allow dormant connections to remain open for longer periods as resources permit. noting, as a recommendation, this is harmless to the installed base, as long as the installed base remembers that a faithful implementation of RFC 1035 4.3.2 will not be doing this, and avoids perturbing those servers with long-lived TCP sessions that their connection management logic is ill-equipped to handle. To mitigate the risk of unintentional server overload, DNS clients MUST take care to minimize the number of concurrent TCP connections made to any individual server. not just concurrent, but also, idle. no idle connections can be permitted unless the client knows absolutely that the server is modern and is following the specification now being reviewed. ... For reasons of efficiency, implementations SHOULD wherever possible attempt to coalesce the two byte length field and subsequent DNS payload data into a single packet. i think you can word this more strongly. as in: Since TCP responders are sensitive to timeout conditions, some extant implementations will abort a TCP session if the first TCP window does not contain both the two-octet length field and the entire request message described by that length field. TCP initiators should therefore take care to
Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01
On Wed, 18 Mar 2015 01:59:56 -0700 Paul Vixie p...@redbarn.org wrote: This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. this language is too strong, and breaks working configurations. That is the exact same language used in IETF RFC 5966. The original document, along with this draft still says it makes no specific recommendations to operators of DNS servers. It is written for implementors. This seems to be a common misunderstanding. John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 6761 discussion (“special names”)
On Mar 18, 2015, at 7:01 AM, Jaap Akkerhuis j...@nlnetlabs.nl wrote: Tim Wicinski writes: The WG has several documents that we need to spend time in Dallas moving towards completion. But we also believe the RFC 6761 drafts should not be given short shrift. Accordingly, we are tentatively planning a Virtual Interim Meeting to dive a little deeper on the special names drafts, including possible architectural implications of the apparent increase in interest in RFC 6761, as we attempt to muddle through the questions we’ve seen and the ones we anticipate. Following this discussion from a distance, I cannot help wondering whether this is special names stuff might in violate RFC 2860 section 4.3. Making sure that any coordination needed is getting done seems to be a valid concern, yes. The IAB called this out in a liaison communication to ICANN last year; you can read it here: http://datatracker.ietf.org/liaison/1351/. best, Suzanne ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 6761 discussion (“special names”)
On Mar 18, 2015, at 7:01 AM, Jaap Akkerhuis j...@nlnetlabs.nl wrote: Following this discussion from a distance, I cannot help wondering whether this is special names stuff might in violate RFC 2860 section 4.3. I don't see it. It looks like 2860 explicitly supports what is being proposed here. Where do you see a conflict? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01
On Wed, Mar 18, 2015 at 10:08:23AM +, Tony Finch wrote: I think the recommended limits in that paragraph are OK only if viewed from the perspective of individual client programs. The above quote is correct in that there's no sensible way for the server to enforce the limit - never mind NAT, if a user starts up a second browser, will it be locked out of TCP queries until the first one closes its connection? I agree with this; it's only the MUST NOT that I think goes too far, since that's a restriction on what an implementation might offer. I like the proposed alternative text (which I elided). A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 6761 discussion (“special names”)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/18/15 08:01, Jaap Akkerhuis wrote: Following this discussion from a distance, I cannot help wondering whether this is special names stuff might in violate RFC 2860 section 4.3. *** Assignment of special names belongs to assignment of domain names for technical use according to that section. Do you read it differently? == hk -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJVCXICXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9nukP/ikl8/kSob/+tEdkmy2W/rxa gaNmPtkvKSnFxOhHLNL2aUf0M23b/mJXJkVzX42PupqOpKX8aLIp/pb6Zb+XZMR8 As4eA6Xs6XaO/deoLTGVy0ihMpECtwrdk+FD1P+cWkgTzaTZajrRDakYiUwlJ8nq dMkaStxakHp+K9+Xt66enxTw8J7JmqKFxTQppumdpRvE/CsyJ3tBOeQOz7h4yInZ KSuRXCSB5Odi0OqTUPu18Egsu6l5RlesnVHobCkq6USp6Ctc+udFqrSpyOivzRzJ N3lIFk19snovxZUDx47TpNW2bXW1eTDGv2rMqgia+HUl1K1ZhgF7vy6/C+89XUv9 CoLZB9DjVk2Ej/d7/jfWclK6h9/YsMElne2Tny70uTQJF3MU8s9E3NJGxy8cO3Xb oVc8Iu6wRVfQyi4EJBJ6HsMNRtkxtlqz+3oDoQSVU7WZQTqpTuVXGFWNThp3vjC1 EgrlHT3EG6xjpoKoBwjRWmoyVUSg7m7UoUgsxWGKNAuGcrIaojhA/qDswFQ1YdrO 21oCyTM6YQ4XSwMgqRcyIRNe2NCQJMXHNcYvagW8IM46FjpSgZ6kXFjXPzxmrSx8 V6QP4ct6k3zC6qRiwcfsAD2kt/p9gZSfTmlEEZIq9a5v3T5HIP7wjZEr9nBpzWoJ na+Wl6rJg0hQKxrebcCX =7T7q -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS terminology: Passive DNS
Stephane Bortzmeyer wrote: On Tue, Mar 17, 2015 at 10:56:44PM -0400, Robert Edmonds edmo...@mycre.ws wrote a message of 34 lines which said: Passive DNS Replication -- A mechanism to collect and store resource records by observing responses, usually those sent by authoritative servers. Passive DNS databases can be used to recover DNS records which were served in the past, and may allow certain kinds of inverse searches of the stored records. Sometimes shortened to passive DNS. My contribution to the painting of the bikeshed: I would drop usually those sent by authoritative servers because the responses can be sent by servers which are not authoritative for this specific zone (that's why DNSDB indicates the bailiwick of the response). in DNSDB, any bailiwick value you see is of an authority zone, and thus, usually those sent by authoritative servers. i believe that robert's terminology was carefully chosen, and is correct. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS terminology: Passive DNS
Stephane Bortzmeyer wrote: On Tue, Mar 17, 2015 at 10:56:44PM -0400, Robert Edmonds edmo...@mycre.ws wrote a message of 34 lines which said: Passive DNS Replication -- A mechanism to collect and store resource records by observing responses, usually those sent by authoritative servers. Passive DNS databases can be used to recover DNS records which were served in the past, and may allow certain kinds of inverse searches of the stored records. Sometimes shortened to passive DNS. My contribution to the painting of the bikeshed: I would drop usually those sent by authoritative servers because the responses can be sent by servers which are not authoritative for this specific zone (that's why DNSDB indicates the bailiwick of the response). Hi, Stephane: I was actually trying to draw a distinction between above the recursive and below the recursive collection, which is shown graphically in the slide 13 set in [0]. The work in [1] is an example of a system that collected both types of data. Maybe the following is better: Passive DNS Replication -- A mechanism to collect and store resource records by observing responses, usually those received by recursive servers. Passive DNS databases can be used to recover DNS records which were served in the past, and may allow certain kinds of inverse searches of the stored records. Sometimes shortened to passive DNS. Thanks! [0] http://www.enyo.de/fw/software/dnslogger/first2005-interactive.pdf [1] http://www.cc.gatech.edu/~ynadji3/docs/pubs/dnsnoise-dsn2014.pdf -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01
Ray Bellis wrote: On 18 Mar 2015, at 12:37, John Kristoff j...@cymru.com wrote: That is the exact same language used in IETF RFC 5966. The original document, along with this draft still says it makes no specific recommendations to operators of DNS servers. It is written for implementors. This seems to be a common misunderstanding. That's exactly correct, and was required to get 5966 through IESG review. for avoidance of doubt, let's try writing what we actually mean, and arguing it to IESG if necessary. the current philosophy of DNSOP is to write documents in the If you want to do this, here's how to do it interoperably style, rather than the If you're going to do this at all, you must do it this way style. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-ogud-dnsop-acl-metaqueries
On Fri, Mar 13, 2015 at 05:25:03PM +, Tim Wicinski tjw.i...@gmail.com wrote a message of 31 lines which said: This starts a Call for Adoption for draft-ogud-dnsop-acl-metaqueries Without even reading the draft, I would like to raise a point. dnsop has adopted many Internet-Drafts https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html which it has trouble processing. I suggest to think strongly before adding more work, whatever the merits of this work are. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Paul Wouters mailto:p...@nohats.ca Wednesday, March 18, 2015 6:58 AM On Wed, 18 Mar 2015, Paul Vixie wrote: my proposal is, limit ANY to a selected set of source-ip addresses, as is commonly done with AXFR/IXFR. Which I answered before by saying that is basically killing the ANY query. The proposed solution merely pretends to not kill it by saying acl. i don't think there's any pretense here about not wanting to kill, or not killing, ANY. the history of DNS is replete with examples of information leaks which had to be stopped, either by ad-hoc action or by standards action. limiting who can do zone transfers was first (BIND4 King James Edition, 1989-ish). preventing DNSSEC zone walking was next (DNSEXT, NSEC3, 2001-2014). now it's ANY. many things which made sense on an academic research Internet do not make sense on a world-wide commercial internet. we need a document that says If you don't want to answer ANY, here's how to do it interoperably. we don't need to say you should not answer ANY, but we do need to say if you want to query for ANY, here's what might happen. that, sir, is a killing. we are killing ANY. there's no pretense. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-ogud-dnsop-acl-metaqueries
On Wed, 18 Mar 2015, Stephane Bortzmeyer wrote: This starts a Call for Adoption for draft-ogud-dnsop-acl-metaqueries Without even reading the draft, I would like to raise a point. dnsop has adopted many Internet-Drafts https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html which it has trouble processing. I suggest to think strongly before adding more work, whatever the merits of this work are. And every single dnsop meeting we ran into severe issues of running out of time. I do hope that this time, we will ONLY talk about current documents, and not have any third party presentations. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Paul Wouters wrote: On Tue, 17 Mar 2015, Yunhong Gu wrote: The reason that this response can be used for an amplification attack is its size, not the ANY type. A responses with 200 A records can be used for the same purpose. The (even deeper) root cause is the use of UDP in DNS protocol. I just do not think banning ANY touches any of these fundamental issues. Right, so require tcp or eastlake cookies, that would protect third parties, but not the server itself. or allow padding the ANY request so the request/response ratio is close to 1 before allowing the answer. that would not prevent the unfortunate information leak that allows third parties to scan our caches. Make the dig command default to tcp. That should cover the vast majority of valid ANY queries. my proposal is, limit ANY to a selected set of source-ip addresses, as is commonly done with AXFR/IXFR. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS terminology: In-bailiwick response, Out-of-bailiwick response
On Mar 18, 2015, at 2:29 PM, Robert Edmonds edmo...@mycre.ws wrote: draft-hoffman-dns-terminology-02 has the following definitions: In-bailiwick response -- A response in which the name server answering is authoritative for an ancestor of the owner name in the response. The term normally is used when discussing the relevancy of glue records. For example, the parent zone example.com might reply with glue records for ns.child.example.com. Because the child.example.com zone is a descendant of the example.com zone, the glue is in-bailiwick. Out-of-bailiwick response -- A response in which the name server answering is not authoritative for an ancestor of the owner name in the response. A few comments: * A zone can't send a reply; the authoritative server for a zone can. * Response isn't defined(!), nor is reply. I was (pedantically) thinking of an RFC 1035 §4 message with the QR bit set to 1 at first, but that doesn't fit well in the context of the owner name in the response, because a response message can contain RRs with different owner names, and records within a response message can be individually considered in-bailiwick or out-of-bailiwick. It would be good to clarify which owner name is being compared. * RFC 5452 §6, though it uses in-domain rather than in-bailiwick, uses the concept of deeming the authoritativeness of a record. RFC 3833 §2.3 refers to the long-standing defense of checking RRs in response messages for relevance to the original query. I think these two RFCs are alluding to the same or a similar bailiwick concept being defined here. Is in-bailiwick / out-of-bailiwick a property of the data in the DNS and how authoritative servers are configured to use it, or is it a determination (a deeming) by a recursive server that the data has this property? I favor the latter, because it is useful to have dedicated terminology for the process of determining a server's authority, but maybe a separate definition would be helpful: Bailiwick checking -- The process of determining whether a record in a response message should be considered in-bailiwick or out-of-bailiwick. Ah, the joys of defining terms that have been used a long time, but almost never in RFCs. Grep all the RFCs: you'll see bailiwick is used, but not defined, in RFC 6763 and 7477, and nowhere else. I think response and reply don't need to be defined, but they do need to be used more carefully, and we didn't do that here, I think (but my co-authors might disagree with me). From looking at your concerns and the general use of bailiwick, I propose that it is records, not responses, that in- or out-of. Further, I disagree with this being about deeming. There is a simple rule (the owner name is a subzone of the answer), whereas deeming indicates that there might be other logic that is not given here. Proposed rewording, quite open to editing or reversion: In-bailiwick -- A glue record in which the name server answering is authoritative for an ancestor of the owner name in the record. The term normally is used when discussing the relevancy of glue records. For example, the server for the parent zone example.com might reply with glue records for ns.child.example.com. Because the child.example.com zone is a descendant of the example.com zone, both glue records in-bailiwick. Out-of-bailiwick -- A glue record in which the name server answering is not authoritative for an ancestor of the owner name of the record. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS terminology: In-bailiwick response, Out-of-bailiwick response
On Wed, Mar 18, 2015 at 05:22:41PM -0700, Paul Hoffman wrote: Ah, the joys of defining terms that have been used a long time, but almost never in RFCs. Grep all the RFCs: you'll see bailiwick is used, but not defined, in RFC 6763 and 7477, and nowhere else. To be fair to the other authors, I suspect I am mostly to blame for this particularly infelicitous way of defining things. Good thing we have WGs to review stuff! I think response and reply don't need to be defined, but they do need to be used more carefully, and we didn't do that here, I think (but my co-authors might disagree with me). From looking at your concerns and the general use of bailiwick, I propose that it is records, not responses, that in- or out-of. What's tricky here is that the bailiwick-ness of something is only relevant given a response. So it seems to me that it's a question of records in a given response. I think Paul's proposed text doesn't _quite_ get us there, but it's close. I'll think some more. Out-of-bailiwick -- A glue record in which the name server answering is not authoritative for an ancestor of the owner name of the record. Given the previous discussion about glue, that word seems especially fraught here. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS terminology: In-bailiwick response, Out-of-bailiwick response
Hi, Andrew: Andrew Sullivan wrote: On Wed, Mar 18, 2015 at 05:22:41PM -0700, Paul Hoffman wrote: I think response and reply don't need to be defined, but they do need to be used more carefully, and we didn't do that here, I think (but my co-authors might disagree with me). From looking at your concerns and the general use of bailiwick, I propose that it is records, not responses, that in- or out-of. What's tricky here is that the bailiwick-ness of something is only relevant given a response. So it seems to me that it's a question of records in a given response. I think Paul's proposed text doesn't _quite_ get us there, but it's close. I'll think some more. Do you think the simple way in RFC 5452 §6 is talking about the bailiwick-ness of records, or is it describing something different/stricter? Out-of-bailiwick -- A glue record in which the name server answering is not authoritative for an ancestor of the owner name of the record. Given the previous discussion about glue, that word seems especially fraught here. I note 6763 talks about verifying that any records (not just glue records) in a response are in-bailiwick. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] negative-trust-anchors-02
Dear colleagues, I have read draft-ietf-dnsop-negative-trust-anchors-02. I have some comments. To begin with, I support, very strongly, getting this basic idea documented and published soon. Recent commentary (I will not say fatuous) on DNSSEC complained at length about DNSSEC failures, as though returning to those halcyon days where Certificate Invalid. Proceed? [YES] [no, why would you ever press this?] dialogues were the norm would be nice. NTAs are needed to aid with making DNSSEC compatible with human expectations. In section 1, it'd be nice to break up some of the references to other documents at the beginning. In my opinion, the final paragraph of section 1 could be cut without any damage to the document. Certainly, everything starting with, When I see folks voice opinions… is editorial and can profitably be removed. Regardless of how much I might agree with the sentiments, I don't think that's necessary for a protocol document to adopt that argumentative tone. The Introduction elsewhere gives ample reason that NTAs are a potentially useful innovation for effective deployment of DNSSEC. In section 2, I am jarred slightly by the description of NTAs as the inverse of TAs. I wonder whether they're actually the converse or, more likely, reverse of TAs. None of these are satisfying to me. Perhaps I spent too much time in syllogism school. I don't feel strongly about this, but I found it distracting, and probably just saying, By way of analogy, negative trust anchors stop validation…, or something along those lines. In section 4, I would be stronger in this sentence: End users generally do not know what DNSSEC is, nor should they be expected to at the current time (especially absent widespread integration of DNSSEC indicators in end user software such as web browsers). That sets the bar way too low. How about this: End users generally do not know of, understand, or care about the resolution process that causes connections to happen. This is by design: the point of the DNS is to insulate users from having to remember IP addresses through a friendlier way of naming systems. It follows from this that end users do not, and should not, be expected to know about DNSSEC, validation, or anything of the sort. In section 5, I'd remove and is potentially harmful to DNSSEC adoption. DNSSEC is not, as the I-D argues (IMO correctly) an end in itself. I don't understand why section 6 is in the document, and I really don't understand why it is in the location it is. Everything up to section 7 seems to be motivational. It might be nice to group all of itq into a big section (Introduction and Motivation) or something like that, and then deal with the normative parts in another section (leaving the sections 1-6 as subsections instead). There are some people who feel very strongly that the motivation stuff needs to be in a separate document, but publication would probably be eased by the single introduction and motivation section. In section 7, there are these bits: Technical personnel trained in the operation of DNS servers MUST confirm that a failure is due to misconfiguration, as a similar breakage could have occurred if an attacker gained access to a domain's authoritative servers and modified those records or had the domain pointed to their own rogue authoritative servers. […] Finally, they should make a reasonable attempt to contact the domain owner of the misconfigured zone, preferably prior to implementing the Negative Trust Anchor. How are you going to do the first part without the last part? Is this to cover the, I saw them post on a mailing list, case? After that, there's In the case of a validation failure due to misconfiguration of a TLD or popular domain name (such as a top 100 website), this could make content or services in the affected TLD or domain inaccessible for a large number of users. In such cases, it may be appropriate to use a Negative Trust Anchor as soon as the misconfiguration is confirmed. It seems to me that the top 100 website cases are exactly where one would most expect malfeasance, and therefore the names where one needs the strongest diligence, no? In the final paragraph of section 7, it'd be nice also to point out the isolation across the tree: example.com's NTA need not (MUST NOT?) affect .net or example.net or lower.example.net or even example2.com. Respectfully submitted, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt
On 3/17/15, 21:53, Richard Barnes r...@ipv.sx wrote: The only nit I would pick with the above is that it's perfectly possible to *specify* what should be done, but of course one should not expect that to instantly change everyone's behavior. A preamble - I don't think what is perfectly possible matters. In an environment that has an unbounded population it's a waste of time to document a rule saying this is how you must/should/ought to behave if only because enforcement (testing) is impractical. What you can do, in such an environment, is focus on individual reactions to the stimuli - like - when you get asked a question, reply like this. If you are writing to a bounded population of actors, you can spell out rules that define membership and what it means to be a member. Nevertheless, you have to account for the unbounded population of non-members knowingly or unwittingly getting in the way. Sometimes the underlying concept is perfectly reasonable but the way it is described has flaws and sometimes the recipe contains poor assumptions. From the draft (https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-00) 1. Users: human users are expected to recognize .onion names as having different security properties, and also being only available through software that is aware of onion addresses. I don't know what to make of that. It's fine, but, to me an onion is something I buy at the supermarket so if asked about an onion address, I'd guess a farm. (Take this lightly, I'm not sure what would be an appropriate answer - and I couldn't resist.) 2. Application Software: Applications that implement the Tor protocol MUST recognize .onion names as special by either accessing them directly, or using a proxy (e.g., SOCKS [RFC1928 https://tools.ietf.org/html/rfc1928]) to do so. Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion, and SHOULD NOT perform a DNS lookup. The first part of the answer is spot-on. The latter is wrong - for example, my mail client allowed be to type in .onion and it didn't and shouldn't complain. (I turned off spell checking too.) Trying to specify what non-Tor-protocol elements will do is kind of useless. 3. Name Resolution APIs and Libraries: Resolvers that implement the Tor protocol MUST either respond to requests for .onion names by resolving them (see [tor-rendezvous...) or by responding with NXDOMAIN. Other resolvers SHOULD respond with NXDOMAIN. This is tricky. Again, Tor-protocol elements are fair game. Other resolvers will fall into two camps, one that would always return NXDOMAIN so long as .onion is not delegated in the root zone. It's possible I stand up a test DNS with .onion, .tomato, .lettuce for testing in my private lab and that should be okay (until I connect the lab with the outside world - which I have seen happen). 4. Caching DNS Servers: Caching servers SHOULD NOT attempt to look up records for .onion names. They SHOULD generate NXDOMAIN for all such queries. Same comment as for #3. 5. Authoritative DNS Servers: Authoritative servers SHOULD respond to queries for .onion with NXDOMAIN. Same comment as for #3 and #4. 6. DNS Server Operators: Operators SHOULD NOT configure an authoritative DNS server to answer queries for .onion. If they do so, client software is likely to ignore any results (see above). I would drop the latter sentence, the first is a reasonable suggested practice for operators. I worked at an operator that would let you configure any domain you wanted, so long as it didn't conflict with others in its own system. This had the same pitfalls as certificate authorities issuing certificates for resources whose responsibility was impossible to trace, with actually less consequences. (I'll avoid the temptation to justify that here.) 7. DNS Registries/Registrars: Registrars MUST NOT register .onion names; all such requests MUST be denied. This goes along with my responses to #3, #4, #5 - as far as there never being a .onion in the root zone. (Somewhere in this writing, I remind myself that the Special-Use Domain Name registry is a little bit of an unknown to me, mentioned in another email earlier today.) Elsewhere in the draft is this: The Tor network is designed to not be subject to any central controlling authorities with regards to routing and service publication, so .onion names cannot be registered, assigned, transferred or revoked. Ownership of a .onion name is derived solely from control of a public/private key pair which corresponds to the algorithmic derivation of the name. Users must take special precautions to ensure that the .onion name they are communicating with is correct, as attackers may be able to find keys which produce service names that are visually or apparently
[DNSOP] DNS terminology: In-bailiwick response, Out-of-bailiwick response
Hi, draft-hoffman-dns-terminology-02 has the following definitions: In-bailiwick response -- A response in which the name server answering is authoritative for an ancestor of the owner name in the response. The term normally is used when discussing the relevancy of glue records. For example, the parent zone example.com might reply with glue records for ns.child.example.com. Because the child.example.com zone is a descendant of the example.com zone, the glue is in-bailiwick. Out-of-bailiwick response -- A response in which the name server answering is not authoritative for an ancestor of the owner name in the response. A few comments: * A zone can't send a reply; the authoritative server for a zone can. * Response isn't defined(!), nor is reply. I was (pedantically) thinking of an RFC 1035 §4 message with the QR bit set to 1 at first, but that doesn't fit well in the context of the owner name in the response, because a response message can contain RRs with different owner names, and records within a response message can be individually considered in-bailiwick or out-of-bailiwick. It would be good to clarify which owner name is being compared. * RFC 5452 §6, though it uses in-domain rather than in-bailiwick, uses the concept of deeming the authoritativeness of a record. RFC 3833 §2.3 refers to the long-standing defense of checking RRs in response messages for relevance to the original query. I think these two RFCs are alluding to the same or a similar bailiwick concept being defined here. Is in-bailiwick / out-of-bailiwick a property of the data in the DNS and how authoritative servers are configured to use it, or is it a determination (a deeming) by a recursive server that the data has this property? I favor the latter, because it is useful to have dedicated terminology for the process of determining a server's authority, but maybe a separate definition would be helpful: Bailiwick checking -- The process of determining whether a record in a response message should be considered in-bailiwick or out-of-bailiwick. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
