Re: [DNSOP] New version of the DNS terminology draft
On Jan 21, 2015, at 10:27 AM, Niall O'Reilly niall.orei...@ucd.ie wrote: I'ld suggest using the following text from RFC1034 (section 4.2.1): The authoritative data for a zone is simply all of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom edge of the zone. Quoting directly from the source RFCs seems better, yes. Thanks! --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
At Mon, 19 Jan 2015 14:16:47 -0800, Paul Hoffman wrote: Greetings again. Andrew, Kazunori, and I have done a massive revision on the DNS terminology draft based on the input we got on the -00. We're sure we have further to go, So far, great job! but we wanted people to look over the new version and give feedback. Thanks! [snip from http://www.ietf.org/id/draft-hoffman-dns-terminology-01.txt] 7. Zones This section defines terms that are used when discussing zones that are being served or retrieved. Zone -- A unit of organization of authoritative data. [...] Authoritative data -- RRsets in the Answer section of a DNS response that has the AA bit in the response header set to 1. [/snip] This seems to describe how Authoritative data must be marked in a DNS response, rather than to define Authoritative data. Besides, section 6.2.7 of RFC1034 shows a non-authoritative RR in the Answer section of a response which has the AA bit. I'ld suggest using the following text from RFC1034 (section 4.2.1): The authoritative data for a zone is simply all of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom edge of the zone. Best regards, Niall O'Reilly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Followup Discussion on TCP keepalive proposals
On Wed, 21 Jan 2015, Paul Vixie wrote: even if changing TCP/53's connection semantics could be done without creating new DoS vectors, the small number of DNS TCP initiators and responders who will ever be upgraded responders do not need to be upgraded for this, as we found out on this list about two years ago when Mark Andrews patched dig and I ran a test with that. , would be able to adopt TCP/80 faster. many middleboxes assume that DNS is UDP-only, and a few no doubt proxy the transaction in a way that hijacks the connection management semantics in a way that would (a) pass your new signalling along, but (b) not follow it. What is the problem with if you are behind broken middleware, do DNS like it it 1999 ? I don't see how that is a reason to start moving to port 80. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Followup Discussion on TCP keepalive proposals
Paul Wouters mailto:p...@nohats.ca Wednesday, January 21, 2015 8:38 AM On Wed, 21 Jan 2015, Paul Vixie wrote: even if changing TCP/53's connection semantics could be done without creating new DoS vectors, the small number of DNS TCP initiators and responders who will ever be upgraded responders do not need to be upgraded for this, as we found out on this list about two years ago when Mark Andrews patched dig and I ran a test with that. a responder with a small file descriptor limit who ignores keepalive signalling can easily see all of its tcp slots occupied, either by persistent initiators, or by any extremely unskilled, low-investment attacker. , would be able to adopt TCP/80 faster. many middleboxes assume that DNS is UDP-only, and a few no doubt proxy the transaction in a way that hijacks the connection management semantics in a way that would (a) pass your new signalling along, but (b) not follow it. What is the problem with if you are behind broken middleware, do DNS like it it 1999 ? I don't see how that is a reason to start moving to port 80. dnssec. but, more importantly, persistent tcp is all we've got. RFC 6013 failed, in the sense that the tcp-m WG chose not to give it the IANA resources it would have needed. google's tcp-fastopen is at best unsecure. SCTP seems to have jammed in the breach. if we want (and we do want) to keep a hot path open between a dns initiator and its pool of dns responders, then we need persistent tcp in the HTTP/1.1 style, and we need a large number of tcp slots on the responder, in the style of HTTP/1.1 responders. the t-shirt is wrong. it's not cross out 'lets take it to the ietf' and write 'just put it into dns'. rather, it's cross out 'lets assume that our initiator has an internet connection' and write 'lets assume that our initiator has a web connection'. the internet is older than the web, but no longer larger than the web. just as ethernet was the RS232 of the 1990's, so now TCP/80 is the RS232 of the new century. i do not love this fact, but i do recognize it. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
Thanks for the suggestions! However: On Jan 21, 2015, at 6:52 AM, Colm MacCárthaigh c...@allcosts.net wrote: RRSet: Are the RRs in an RRSet required to have different data? For types such as A//SRV/MX this makes sense, but maybe not for TXT. I also think views and other implementation specific features confuse things here. A user might have 10 A records defined for a given name; but if their DNS server returns one at a time (say it's using weighted round robin) - I don't think of the 10 as an RRSet; but rather it's 10 RRSets. What's actually sent on the wire is what matters, I think. Note that, when possible, our document is reproducing what is in the standards-track RFCs. You might want a different definition for a term, but if there is a non-confusing definition already, our document should use it. In this case, the RFC 2181 definition is refreshingly clear, and what you are describing would be a thing that is not an RRset and maybe should have a different term. We are, in fact, making up some terms in the document, but only in cases where there is a well-known thing that doesn't have a term. I don't think your round-robin example is such a thing, but if others disagree and can come up with a new term, we can add it. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
Colm MacCárthaigh mailto:c...@allcosts.net Wednesday, January 21, 2015 8:36 AM On Wed, Jan 21, 2015 at 7:25 AM, Paul Vixie p...@redbarn.org mailto:p...@redbarn.org wrote: if their server returns only one RR at a time, then there are ten RRsets, as you say. however, such a server would not be speaking the DNS protocol as defined, if it starts from a zone file or zone transfer where there is within the zone ten RR's for a given name. so, by definition, the current text is correct. If there are two zones for the same name, with different views, do the RRs of a given name and type in both zones form a single rrset? ... views are outside of the protocol, and i don't think a dns terminology document should talk about them at all. I don't think so. Zone files aren't a requirement of the DNS protocol either; and I don't think there's any case to be made that the configuration of multiple rrsets for the same name/type is not speaking the DNS protocol as defined. to my credit, i wrote or a zone transfer. that means if you are optionally receiving a zone (as defined in the protocol) or optionally loading a zone file (as defined in the protocol), then the meaning of a set of rr's in that zone transfer session or that zone file is as described by the protocol, and if you subset that set of rr's when sending a response to a query matching that name and type, then you are acting outside of the protocol. in this case as in the above case, i don't think a dns terminology document should describe things that are outside of the protocol. Stealth server: this definition seems a bit contradictory. Starts out by saying it's a slave, but then says it can also be a master. in other words, what makes you a master is that someone is transferring from you. the primary master is the only master that by definition cannot also be a slave. the terms master and slave refer to protocol roles within the AXFR/IXFR transaction. It might be worth updating the text to say is often also a master to make the non-exclusivity between master and slave a bit more clear. i think so too. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
Colm MacCárthaigh c...@allcosts.net wrote: TTL: It might be worth using the word 'maximum' in relation to the TTL; I think there is consensus that TTLs may be truncated. Yes, due to memory pressure, server restarts, administrative fiat, DNSSEC (RFC 4035 section 5.3.3), etc. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Humber, Thames, Dover, Wight, Portland: Southeast, backing east, 4 or 5, occasionally 6 at first in Humber. Slight or moderate, but rough at first in Portland. Showers. Good, occasionally moderate.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Followup Discussion on TCP keepalive proposals
Paul Wouters p...@nohats.ca wrote: responders do not need to be upgraded for this, as we found out on this list about two years ago when Mark Andrews patched dig and I ran a test with that. Not entirely true. Persistent TCP works but it needs some performance engineering. Responders need to be upgraded to handle queries concurrently and send replies out-of-order, so that TCP performance is as good as UDP performance. Both Unbound and BIND suffer from this (though BIND is being fixed.) They also need some web-server-style attention to TCP connection scalability, e.g. by default BIND is limited to only 100 connections. It should be reasonable to set it to 1 on servers that are relatively modest by today's standards. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Tyne, Dogger, Fisher, German Bight: Southeast 4 or 5, occasionally 3 later. Slight or moderate. Showers. Good, occasionally moderate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Followup Discussion on TCP keepalive proposals
Ray Bellis mailto:ray.bel...@nominet.org.uk Wednesday, January 21, 2015 1:30 AM TCP/53 is already persistent, it just happens most clients don't take advantage of that feature. if they did, then those initiators would either be a DoS from the responder's point of view, or a DoS from other initiators' points of view. we are a prisoner to the reasonable expectations of the billions of devices that were created in the decades-long era of RFC 1034 section 4.2.2. The point of my draft is to permit signalling that the current connection should _not_ be persisted ;-) i know. but the arrow of change does not point in that direction. HTTP/0.9 was responder-close, and was thus able to be changed in HTTP/1.1 to initiator-close unless and only unless Connection: close was specified. even if changing TCP/53's connection semantics could be done without creating new DoS vectors, the small number of DNS TCP initiators and responders who will ever be upgraded, would be able to adopt TCP/80 faster. many middleboxes assume that DNS is UDP-only, and a few no doubt proxy the transaction in a way that hijacks the connection management semantics in a way that would (a) pass your new signalling along, but (b) not follow it. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
On Wed, Jan 21, 2015 at 7:25 AM, Paul Vixie p...@redbarn.org wrote: RRSet: Are the RRs in an RRSet required to have different data? For types such as A//SRV/MX this makes sense, but maybe not for TXT. I also think views and other implementation specific features confuse things here. A user might have 10 A records defined for a given name; but if their DNS server returns one at a time (say it's using weighted round robin) - I don't think of the 10 as an RRSet; but rather it's 10 RRSets. What's actually sent on the wire is what matters, I think. if their server returns only one RR at a time, then there are ten RRsets, as you say. however, such a server would not be speaking the DNS protocol as defined, if it starts from a zone file or zone transfer where there is within the zone ten RR's for a given name. so, by definition, the current text is correct. If there are two zones for the same name, with different views, do the RRs of a given name and type in both zones form a single rrset? I don't think so. Zone files aren't a requirement of the DNS protocol either; and I don't think there's any case to be made that the configuration of multiple rrsets for the same name/type is not speaking the DNS protocol as defined. Stealth server: this definition seems a bit contradictory. Starts out by saying it's a slave, but then says it can also be a master. in other words, what makes you a master is that someone is transferring from you. the primary master is the only master that by definition cannot also be a slave. the terms master and slave refer to protocol roles within the AXFR/IXFR transaction. It might be worth updating the text to say is often also a master to make the non-exclusivity between master and slave a bit more clear. -- Colm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Followup Discussion on TCP keepalive proposals
On Wed, Jan 21, 2015 at 4:53 PM, John Heidemann jo...@isi.edu wrote: I don't see how DoS is an argument against TCP for DNS. (Unless one assumes hardware and software at the servers is fixed to something like 2004 standards.) What am I missing? What's the average client load expected (number of unique clients in the timeout of the tcp connection expected) for an authoritative server today? (say an enterprise hosted server, and then someone that is a large domain aggregator) What is the same curve for a recursive server? (again, a small isp/enterprise vs a large provider) What impact will changing to longer lived persistent tcp connections have on hardware and network capacity planning? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case
On Fri, Jan 16, 2015 at 09:58:32AM -0800, Paul Vixie wrote: Olafur Gudmundsson mailto:o...@ogud.com Friday, January 16, 2015 7:51 AM ... One of the oldest ideas on that was from Andreas Gustafsson was to wrap XFR transmission inside compressed transmission. late BIND4 and early BIND8 had something called ZXFR that did this. it never worked out of the box, but frederico neves in brazil fixed it and had it running in production for his inter-site synchronization some time in the mid/late 1990's. it's worth asking him if it was worthwhile This was late 1990's, in a time that we didn't have registry backend journals, way before bind started providing ixfr-from-differences on 9.3, OSs still struggled with the long fat pipe problem and we happen to have some secondaries on the 350ms vicinity... it was definitely worthwhile. But today I guess in the same scenario a vpn based transport solution would be easier. (noting, this was before incompressible DNSSEC signatures were added.) True only for individual records. I guess the authors are aiming at small zones and Olafur had this in mind when doing this comment. For a even a few thousand records signed zone I see quite good compression only taking in account RRSIGs RDATA. Taking synchronization efficiency in perspective, reducing the amount of redundant information, explicitly suppressing it, is the best approach. MIXFR ideas are worth pursuing. Fred ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Followup Discussion on TCP keepalive proposals
John Heidemann mailto:jo...@isi.edu Wednesday, January 21, 2015 1:53 PM On Wed, 21 Jan 2015 09:30:44 +, Ray Bellis wrote: I want to restate this, because people often confuse current practice with current specifications: DNS over TCP/53 is *already* persistent. No *protocol* changes are needed. i disagree with your use of terms here. see below. *Implementation* changes, however, are needed: - clients need to not blindly close the connection after one request - clients and servers need to use well known implementation techniques (from HTTP) to get good performance---pipelining, processing requests in parallel, sending replies out-of-order (rfc5966), handling TCP fastopen (newly minited rfc7413). at the moment, a tcp/53 initiator that assumes in-order response and does not check the TXID works. the protocol neither permits nor forbids this. the burden is either on the responder to be conservative in what it generates in the presence of the ambiguous specification, or on end-users to be able to upgrade their tcp/53 initiation software to be more cautious in how it treats the answers. similarly, a responder who aborts the tcp/53 session when pipelining is seen (which is a common technique for spam defense on tcp/25, so, unimaginable here) would have neither caused nor experienced any operational problems related to that implementation choice from 1985 to the present day, even though the specification was silent on the matter of pipelining, neither forbidding it nor requiring that it be supported. historically we say we don't want to break working configurations even if their interpretation of the ambiguous specification is not to our liking. and we treat the tightening up of the specification as a protocol change even though by some reading the new behaviour was also acceptable under the older more ambiguous specification. you can see this principle in use here https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00: 5.2. It is strongly urged that the DNS specification be amended to require that the question section from the request MUST be copied, exactly, bit for bit, into the question section of the response. The DNS specification is silent on the matter of altering 0x20 bits in the question name when copying it from the request to the response, so, this change is within the spirit. A change to the specification is necessary because while such bit for bit copying happens to be nearly universal practice today, we must warn all future responder implementors that the 0x20 bits, while not significant for name matching, are now in use as a covert channel by the requestor, to itself. since this draft did not go forward, any responder which does not copy the 0x20 bits of the QNAME is compliant, and any initiator who depends on the copying of 0x20 bits being copied has to allow for this perfectly reasonable interpretation of the existing, somewhat ambiguous, specification. in other words the installed base gets a seat at the table, and if you're going to behave very differently in a way that older implementations could reasonably refuse to interoperate with, it's your problem, not theirs. and under those circumstances, a mandatory change to how the other end interprets the older ambiguous specification is, in effect, a protocol change. Paul Vixie replies: } if they did, [that is: if clients take advange of persitent TCP over port 53] } then those initiators would either be a DoS from the responder's point of view, or a } DoS from other initiators' points of view. we are a prisoner to the reasonable expectations of } the billions of devices that were created in the decades-long era of RFC 1034 section 4.2.2. You're saying TCP is inherently a DoS when used for DNS? yes. well, TCP/53 is. TCP/80, with an appropriate RESTful/JSON API, would be fine. as i've said every time someone has said to avoid $problem, let's use TCP/53 as the primary transport, RFC 1035 section 4.2.2 is a mine field, and anyone at all can deny service to any initiator who depends on tcp/53 service from anyone else at all. that's why the fix to the Kaminsky bug was source port randomization, rather than TCP/53. I don't get it. Some how the web community tolerates persistent TCP without falling over. And you've suggested DNS-over-HTTP is desirable. Won't that also create any DoS problems that stem from TCP? no, it won't. i believe i spoke to this question in detail, down-thread: but, more importantly, persistent tcp is all we've got. RFC 6013 failed, in the sense that the tcp-m WG chose not to give it the IANA resources it would have needed. google's tcp-fastopen is at best unsecure. SCTP seems to have jammed in the breach. if we want (and we do want) to keep a hot path open between a dns initiator and its pool of dns responders, then we need persistent tcp in the HTTP/1.1 style, and we need a large number of tcp slots on the responder, in the style of HTTP/1.1 responders.
[DNSOP] Reminder of the documents in the WG, and a nudge to review them
Greetings again. This is a periodic reminder that the documents that this WG is working on, and may or may not be working on in the future, is at https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html It helps the WG chairs to know which documents have enough people willing to review them to move them forwards. If you would like to volunteer to be a reviewer for any of the documents, please let me know so I can list you. If you want to add a document to the list, contact the WG chairs. --Paul Hoffman, secretary ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Protocol Action: 'Child To Parent Synchronization in DNS' to Proposed Standard (draft-ietf-dnsop-child-syncronization-07.txt)
Tim Wicinski tjw.i...@gmail.com writes: I wanted to thank all the folks who offered comments, edits, and text for this document. Ditto! Documents are always better after lots of feedback, so thank you to everyone that contributed to the document. -- Wes Hardaker Parsons ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Followup Discussion on TCP keepalive proposals
On Wed, 21 Jan 2015 16:58:32 -0500, Christopher Morrow wrote: On Wed, Jan 21, 2015 at 4:53 PM, John Heidemann jo...@isi.edu wrote: I don't see how DoS is an argument against TCP for DNS. (Unless one assumes hardware and software at the servers is fixed to something like 2004 standards.) What am I missing? What's the average client load expected (number of unique clients in the timeout of the tcp connection expected) for an authoritative server today? (say an enterprise hosted server, and then someone that is a large domain aggregator) What is the same curve for a recursive server? (again, a small isp/enterprise vs a large provider) What impact will changing to longer lived persistent tcp connections have on hardware and network capacity planning? Those are good questions, and take some time to answer. We try to speak to them in a tech report at http://www.isi.edu/~johnh/PAPERS/Zhu14b.html It doesn't seem useful copy and past long quotes from that here, but the pointers are: What's the average client load expected (number of unique clients in the timeout of the tcp connection expected) for an authoritative server today? (say an enterprise hosted server, and then someone that is a large domain aggregator) What is the same curve for a recursive server? (again, a small isp/enterprise vs a large provider) [Zhu14b], figure 3a and 3b, with discussion in section 5.3. What impact will changing to longer lived persistent tcp connections have on hardware and network capacity planning? See section 5.2 about memory usage, and appendix H for a long discussion about deployment issues. -John Heidemann ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-rfc6304bis-05.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 Working Group of the IETF. Title : AS112 Nameserver Operations Authors : Joe Abley William F. Maton Sotomayor Filename: draft-ietf-dnsop-rfc6304bis-05.txt Pages : 25 Date: 2015-01-21 Abstract: Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites. Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called reverse lookups) corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the corresponding authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it. This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation. This document obsoletes RFC6304. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc6304bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsop-rfc6304bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc6304bis-05 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] DNSKEY RRset size and the root
Paul, Let me clarify things a bit, Thanks very much for this note. The issue of the ZSK length is something that has popped up on various radars on various occasions and given the recent publicity over at imperialviolet and sockpuppet on 1024 bit RSA, it'd be good to explore this in more detail to see what level of nightmare we'd be inflicting upon ourselves (if any). In other words, which ever clients cannot handle a root ZSK of 2048 already has a severe problem with DNS. I don't think we would be adding much of a problem by just switching to 2048 today. While I tend to agree, this assumes the clients would notice, which obviously depends on the names being looked up. Do you have any idea of (say) the popularity of the names behind large RRsets (e.g., their Alexa ranking or something similar)? Of course, once you believe we can do a ZSK of 2048, there is no urgency to move to ECDSA and we can wait on the CRFG to come up with a non-DSA ECC algorithm for us. Yep. I'd really like to go to ECDSA, but it doesn't look like there is enough support out there for it (at least for root purposes). So unless Australia is not reachable by a significant portion of the world doing DNSSEC, the root is not going to see an issue either. According to http://w3techs.com/technologies/overview/top_level_domain/all (random stats site select by closed eye googling, no idea whether their methodology is reasonable), .AU represents 1% of websites. If 20% of DNS queries are doing DNSSEC lookups, and a small fraction of those are behind broken middleboxes that puke on large RRsets, I can (barely) see an argument that the universe is too small to make a reasonable determination... I guess a larger question is do we care?. I'll be honest and say I'm increasingly concerned that broken middleware-driven ossification is getting in the way of fixing serious problems. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Kathleen Moriarty's No Objection on draft-ietf-dnsop-dnssec-key-timing-06: (with COMMENT)
Kathleen Moriarty has entered the following ballot position for draft-ietf-dnsop-dnssec-key-timing-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/ -- COMMENT: -- Please move Appendix A into section 1.3 as it would be better to have all terms, symbols, and variables used in the draft defined in the terminology section. Russ Housley noticed this and I agree with him in that it would be good to fix. In 1.4 should this include key sizes as well since they are not discussed? I see the explanation in section 5 and am just wondering if the procedures are the same when key properties change as opposed to expiration and revocation, which are both mentioned in the draft. The SecDir review found a few nits you should probably fix as well: https://www.ietf.org/mail-archive/web/secdir/current/msg05318.html ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Followup Discussion on TCP keepalive proposals
On Wed, 21 Jan 2015 09:30:44 +, Ray Bellis wrote: i realize that no votes aren't counted. but that's going to be my input if any document along the lines of adding persistence to tcp/53 is adopted by the WG. so, for full disclosure, i wanted to weigh in at this stage. TCP/53 is already persistent, it just happens most clients don't take advantage of that feature. The point of my draft is to permit signalling that the current connection should _not_ be persisted ;-) I want to restate this, because people often confuse current practice with current specifications: DNS over TCP/53 is *already* persistent. No *protocol* changes are needed. *Implementation* changes, however, are needed: - clients need to not blindly close the connection after one request - clients and servers need to use well known implementation techniques (from HTTP) to get good performance---pipelining, processing requests in parallel, sending replies out-of-order (rfc5966), handling TCP fastopen (newly minited rfc7413). (We've measured and reported the performance differences here before.) Paul Vixie replies: } if they did, [that is: if clients take advange of persitent TCP over port 53] } then those initiators would either be a DoS from the responder's point of view, or a } DoS from other initiators' points of view. we are a prisoner to the reasonable expectations of } the billions of devices that were created in the decades-long era of RFC 1034 section 4.2.2. You're saying TCP is inherently a DoS when used for DNS? I don't get it. Some how the web community tolerates persistent TCP without falling over. And you've suggested DNS-over-HTTP is desirable. Won't that also create any DoS problems that stem from TCP? I don't see how DoS is an argument against TCP for DNS. (Unless one assumes hardware and software at the servers is fixed to something like 2004 standards.) What am I missing? -John Heidemann ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Followup Discussion on TCP keepalive proposals
i realize that no votes aren't counted. but that's going to be my input if any document along the lines of adding persistence to tcp/53 is adopted by the WG. so, for full disclosure, i wanted to weigh in at this stage. TCP/53 is already persistent, it just happens most clients don't take advantage of that feature. The point of my draft is to permit signalling that the current connection should _not_ be persisted ;-) kind regards, Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Followup Discussion on TCP keepalive proposals
I agree with Paul Hoffman. While I think draft-ietf-dnsop-edns-tcp-keepalive is good, even the simpler draft-bellis-dnsop-connection-close would be much better than the current situation, so I support its adoption. DW On Jan 20, 2015, at 11:21 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Jan 20, 2015, at 7:37 AM, Tim Wicinski tjw.i...@gmail.com wrote: draft-ietf-dnsop-edns-tcp-keepalive is a reasonable document, but draft-bellis-dnsop-connection-close achieves a great deal at a very low cost. If we drop draft-ietf-dnsop-edns-tcp-keepalive (which seems likely if the authors don't want to pursue it), we should adopt draft-bellis-dnsop-connection-close and answer the many questions in the draft. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Followup Discussion on TCP keepalive proposals
On Tue, 20 Jan 2015, Paul Vixie wrote: my input is not a direct answer to either question, but, may be relevant. my view is: we can't reliably signal this capability, so any option we pursue will create a DoS vector for either new or old initiators or responders, and the right answer is to pursue DNS-over-HTTP as an alternate transport that already has TCP persistence built into it. i also note that we've got a JSON layout for DNS messages now, thanks to bortzmeyer and hoffman; and we've got a reasonably portable and high quality DNS shim layer now, thanks to the getdns team. so: adding DNS-over-HTTP would happen faster than revising TCP/53. It would be really sad to relegate all ports but 80/443 to the realm of CHAOS. And inevitably, the transparancy of port 80/443 would suffer as it becomes the default demuxing point. But I know you know this, and still you think it is the best way, so therefor sad. tcp/53 is already out there and working on the recursors. Adding client side support that proactively uses this should, for example in unbound and bind, should be easier than implementing dns-in-xml-over-port-80-in-new-api (just like I'm not a fan of dns-over-dbus-into-your-vm-and-back approach of systemd-resolved) I also think that draft-ietf-edns-querychain is a much simpler api than the new getdns api, but I'm biased. And speaking of that draft, I will process the reviews received on it and push out a an updated version. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of the DNS terminology draft
Colm MacCárthaigh mailto:c...@allcosts.net Wednesday, January 21, 2015 6:52 AM RRSet: Are the RRs in an RRSet required to have different data? For types such as A//SRV/MX this makes sense, but maybe not for TXT. I also think views and other implementation specific features confuse things here. A user might have 10 A records defined for a given name; but if their DNS server returns one at a time (say it's using weighted round robin) - I don't think of the 10 as an RRSet; but rather it's 10 RRSets. What's actually sent on the wire is what matters, I think. if their server returns only one RR at a time, then there are ten RRsets, as you say. however, such a server would not be speaking the DNS protocol as defined, if it starts from a zone file or zone transfer where there is within the zone ten RR's for a given name. so, by definition, the current text is correct. Stealth server: this definition seems a bit contradictory. Starts out by saying it's a slave, but then says it can also be a master. in http://www.rfc-editor.org/rfc/rfc1996.txt we see: 1.3. This document intentionally gives more definition to the roles of Master, Slave and Stealth servers, their enumeration in NS RRs, and the SOA MNAME field. In that sense, this document can be considered an addendum to [RFC1035]. ... 2.1. The following definitions are used in this document: Slave an authoritative server which uses zone transfer to retrieve the zone. All slave servers are named in the NS RRs for the zone. Master any authoritative server configured to be the source of zone transfer for one or more slave servers. Primary Master master server at the root of the zone transfer dependency graph. The primary master is named in the zone's SOA MNAME field and optionally by an NS RR. There is by definition only one primary master server per zone. Stealth like a slave server except not listed in an NS RR for the zone. A stealth server, unless explicitly configured to do otherwise, will set the AA bit in responses and be capable of acting as a master. A stealth server will only be known by other servers if they are given static configuration data indicating its existence. Notify Set set of servers to be notified of changes to some zone. Default is all servers named in the NS RRset, except for any server also named in the SOA MNAME. Some implementations will permit the name server administrator to override this set or add elements to it (such as, for example, stealth servers). 2.2. The zone's servers must be organized into a dependency graph such that there is a primary master, and all other servers must use AXFR or IXFR either from the primary master or from some slave which is also a master. No loops are permitted in the AXFR dependency graph. in other words, what makes you a master is that someone is transferring from you. the primary master is the only master that by definition cannot also be a slave. the terms master and slave refer to protocol roles within the AXFR/IXFR transaction. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
