Re: [DNSOP] Masataka Ohta's 2004 draft...
Paul Vixie wrote: Hi, this author isn't in toronto so i'll answer here-- i had not and have not compared -lee-dnsop-scalingroot- to -ohta-shared-root-. Security consideration section of my draft explains why allowing all the ISPs run their own anycast root servers does not make plain DNS less secure. That is, their is no reason to use DNSSEC for anycast root. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Masataka Ohta's 2004 draft...
Francis Dupont wrote: In your previous mail you wrote: Does several thousands of queries per second during normal operations with TCP matter? = yes because it is at the limit current OSs can do on cheap stock hardware... Are you saying real root servers are using cheap stock hardware? PS: I wrote OS because the first reached perf limit is in the kernel, not in the DNS server. And if you argue Web servers support far more, the TCP DNS issue is the server should close connections only after a timeout... Aren't you arguing that the server should close connections only after a timeout because the server can not accept so many new connections? Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Masataka Ohta's 2004 draft...
In your previous mail you wrote: Does several thousands of queries per second during normal operations with TCP matter? = yes because it is at the limit current OSs can do on cheap stock hardware... Are you saying real root servers are using cheap stock hardware? = current real root servers no but if we'd like to run 100 or 100 times more we have first to lower requirements on the hardware. And the argument applies to not root servers too. PS: I wrote OS because the first reached perf limit is in the kernel, not in the DNS server. And if you argue Web servers support far more, the TCP DNS issue is the server should close connections only after a timeout... Aren't you arguing that the server should close connections only after a timeout because the server can not accept so many new connections? = no, I am arguing the requirement on TCP DNS to close at the server side only after a timeout makes most kernel improvements for HTTP servers useless for TCP DNS. Regards francis.dup...@fdupont.fr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
So, if the TTL on the record were higher than the queue-expire setting of the MTA, wouldn't the *intelligent* strategy be to promote the tempfail to a permfail? I've never written an MTA, but it seems like an obvious optimization to me. - Kevin On 7/23/2014 10:00 PM, Mark Andrews wrote: In message 53cfbb29.7040...@chrysler.com, Kevin Darcy writes: Potentially dumb question: what does this magic meaning MX target (.) offer, that a target resolving to a null address (0.0.0.0 and/or ::0) does not? No protocol or code changes required. The null address does, after all, mean no service offered here. (Now, if only load-balancer vendors could wrap their tiny minds around that concept!) - Kevin 0.0.0.0 and :: mean I offer service but I don't currently have a address / know my address. This is a temp fail rather than a permanent fail along with a ttl to retry the address lookup. On 7/17/2014 4:59 PM, Dave Crocker wrote: On 7/17/2014 10:39 AM, John C Klensin wrote: Hi. For a number of reasons, many of which have been identified by others, I find this draft and the actions it recommends distasteful. Since I'm the doc shepherd: I have not seen statements by others indicating that the specification is 'distasteful', although there have been some that seemed to confuse its functionality with that of SPF. Feel free to cite the specific comments by others that classed this as distasteful or the equivalent. I see it as another step, albeit a small one, in the direction of prioritizing the prevention of unwanted messages or connections over successful delivery of legitimate messages. A statement of I don't do X does not 'prioritize' anything. The use of information that says target address Y will not work because there is not receiver at Y's domain does not 'prioritize' anything. The specification is nothing more than a vastly more efficient form of getting an SMTP 550 Requested action not taken: mailbox unavailable, except that it is even better than that, because it also precludes waiting days to discover that there's no service to supply even that error message. Hope, it would be better if the specification were historically accurate and accurate about the protocols it cites. You do not clearly indicate any historical inaccuracy at issue. The last sentence of the second paragraph of Section 5 (Security Considerations) of the spec says: The normal way to send mail for which a sender wants no responses remains unchanged, by using an empty RFC5321.MailFrom address. First, two issues of terminology: (1) RFC 5321 does not contain or specify notations like RFC5321.MailFrom. That notation was introduced in RFC 5598, a document that was approved as Informational with a consensus that, IIR, included some significant desire that it not be normative or casually treated as normative. If this First, so what? Second, a review of the IETF mailing list archive about the document's Last Call, in May of 2009, shows a nicely solid pattern of support for the document's publication. Strange that you would call it into question at this point. specification wants to use that notation, that is fine. But it should include an explicit note to that effect in its introduction or a Terminology section, not bury a (see [RFC5598] for the definitions of these terms) reference in a parenthetical note in Section 4.1 and then expect readers who are looking specifically at other sections to pick up on it. If you want specific text changes, please suggest specific text changes. Please do not formulate a requirement for change in a fashion that leaves the authors having to guess whether it will satisfy you. I believe that the RFC Editor's principle is that, if particular terminology is needed to correctly understand a specification, then the reference to the document that defines that terminology is normative. In this particular case, it seems inconsistent to consider 2119 normative and 5598 informative since both are used to define terminology without which the document cannot be correctly understood. So, you are suggesting that RFC 5598 be a normative reference here? (2) Second, RFC 5321 does not contain a concept that it calls an empty address. The terminology it does use is null reverse-path (See RFC 5321, Section 3.7). Subject to the above, if the authors want to say null address in RFC5321.MailFrom, I don't think that is sufficiently confusing to be a problem. But empty address could be construed as MAIL FROM: in the envelope with nothing following it, and that would be bad news. So you are suggesting: empty RFC5321.MailFrom address - null () reverse-path, per 3.6.3 and 6.1 of RFC 5321 More important, however, RFC 5321 specifies the use of a null reverse path only for delivery failure and status notifications and message disposition notifications (see
[DNSOP] Changing NSEC3 salts regularly is useless
I just sent the following to bind-users. We need to kill the myth that changing NSEC3 salt provides any real benefit. Actually it is useless to change the salt regularly. Changing the salt provides no real benefit against discovering the names in a zone which is the reason people were saying to change the salt. The attacker uses cached NSEC3 records. When it gets a cache miss it asks the servers for the zone, puts the answer in the cache and continues. When the salt changes it just maintains multiple nsec3 chains eventually discarding the old nsec3 chain eventually. I would wait until the new NSEC3 chain has as many cached records as the old NSEC3 chain. Changing the salt slows things up miniminally for a very short period of time after the change. Additionally once you have some names you ask for those names for a non-exisisting type to quickly pull in part of the new NSEC3 chain you know exists. The only reason to change the salt is if you have a collision of the hashed names. This will be a very very very rare event. Mark -- 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] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
In message 53d133d4.4020...@chrysler.com, Kevin Darcy writes: So, if the TTL on the record were higher than the queue-expire setting of the MTA, wouldn't the *intelligent* strategy be to promote the tempfail to a permfail? I've never written an MTA, but it seems like an obvious optimization to me. - Kevin I doubt that it is worth the effort. If one was doing this the ttl is likely to be very small ( 60) so that there are minimal effects when you do reconnect. Mark On 7/23/2014 10:00 PM, Mark Andrews wrote: In message 53cfbb29.7040...@chrysler.com, Kevin Darcy writes: Potentially dumb question: what does this magic meaning MX target (.) offer, that a target resolving to a null address (0.0.0.0 and/or ::0) does not? No protocol or code changes required. The null address does, after all, mean no service offered here. (Now, if only load-balancer vendors could wrap their tiny minds around that concept!) - Kevin 0.0.0.0 and :: mean I offer service but I don't currently have a address / know my address. This is a temp fail rather than a permanent fail along with a ttl to retry the address lookup. On 7/17/2014 4:59 PM, Dave Crocker wrote: On 7/17/2014 10:39 AM, John C Klensin wrote: Hi. For a number of reasons, many of which have been identified by others, I find this draft and the actions it recommends distasteful. Since I'm the doc shepherd: I have not seen statements by others indicating that the specification is 'distasteful', although there have been some that seemed to confuse its functionality with that of SPF. Feel free to cite the specific comments by others that classed thi s as distasteful or the equivalent. I see it as another step, albeit a small one, in the direction of prioritizing the prevention of unwanted messages or connections over successful delivery of legitimate messages. A statement of I don't do X does not 'prioritize' anything. The use of information that says target address Y will not work because there is not receiver at Y's domain does not 'prioritize' anything. The specification is nothing more than a vastly more efficient form of getting an SMTP 550 Requested action not taken: mailbox unavailable, except that it is even better than that, because it also precludes waiting days to discover that there's no service to supply even that error message. Hope, it would be better if the specification were historically accurate and accurate about the protocols it cites. You do not clearly indicate any historical inaccuracy at issue. The last sentence of the second paragraph of Section 5 (Security Considerations) of the spec says: The normal way to send mail for which a sender wants no responses remains unchanged, by using an empty RFC5321.MailFrom address. First, two issues of terminology: (1) RFC 5321 does not contain or specify notations like RFC5321.MailFrom. That notation was introduced in RFC 5598, a document that was approved as Informational with a consensus that, IIR, included some significant desire that it not be normative or casually treated as normative. If this First, so what? Second, a review of the IETF mailing list archive about the document's Last Call, in May of 2009, shows a nicely solid pattern of support for the document's publication. Strange that you would call it into question at this point. specification wants to use that notation, that is fine. But it should include an explicit note to that effect in its introduction or a Terminology section, not bury a (see [RFC5598] for the definitions of these terms) reference in a parenthetical note in Section 4.1 and then expect readers who are looking specifically at other sections to pick up on it. If you want specific text changes, please suggest specific text changes. Please do not formulate a requirement for change in a fashion that leaves the authors having to guess whether it will satisfy you. I believe that the RFC Editor's principle is that, if particular terminology is needed to correctly understand a specification, then the reference to the document that defines that terminology is normative. In this particular case, it seems inconsistent to consider 2119 normative and 5598 informative since both are used to define terminology without which the document cannot be correctly understood. So, you are suggesting that RFC 5598 be a normative reference here? (2) Second, RFC 5321 does not contain a concept that it calls an empty address. The terminology it does use is null reverse-path (See RFC 5321, Section 3.7). Subject to the above, if the authors want to say null address in RFC5321.MailFrom, I don't think that is sufficiently confusing to be a problem. But empty address could be construed as MAIL
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
On 24Jul14, Kevin Darcy allegedly wrote: So, if the TTL on the record were higher than the queue-expire setting of the MTA, wouldn't the *intelligent* strategy be to promote the tempfail to a permfail? Most SMTP clients use a DNS cache so they have no idea what the original TTL is. Even if they could see the auth TTL you'd have to worry about domains that just happen to have very large TTLs in place today for whatever reason. How do you differentiate those domains? As far as standardizing such an idea, I'd hazard a guess that the IETF would not look kindly on encoding semantics into TTL values. Your rationale for this approach would need to be pretty compelling. I've never written an MTA, but it seems like an obvious optimization to me. It's surprising how hard it is to get the TTL out of most DNS client libraries. None of the gethostby* family return it. Even fancy libraries like c-ares are hit and miss with making the TTL available for different RR types. And of course the whole thing implies changing every SMTP client on the planet to recognize these large TTLs. That's a bit of work. All in all it's hard to see what this approach achieves compared to nullmx which works today with no code changes and does not require any special interpretation of DNS data. Mark. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
In message 20140725031019.24785.qm...@f5-external.bushwire.net, Mark Delany writes: On 24Jul14, Kevin Darcy allegedly wrote: So, if the TTL on the record were higher than the queue-expire setting of the MTA, wouldn't the *intelligent* strategy be to promote the tempfail to a permfail? Most SMTP clients use a DNS cache so they have no idea what the original TTL is. Even if they could see the auth TTL you'd have to worry about domains that just happen to have very large TTLs in place today for whatever reason. How do you differentiate those domains? As far as standardizing such an idea, I'd hazard a guess that the IETF would not look kindly on encoding semantics into TTL values. Your rationale for this approach would need to be pretty compelling. I've never written an MTA, but it seems like an obvious optimization to me. It's surprising how hard it is to get the TTL out of most DNS client libraries. None of the gethostby* family return it. Even fancy libraries like c-ares are hit and miss with making the TTL available for different RR types. And of course the whole thing implies changing every SMTP client on the planet to recognize these large TTLs. That's a bit of work. All in all it's hard to see what this approach achieves compared to nullmx which works today with no code changes and does not require any special interpretation of DNS data. 0.0.0.0 and :: are orthognal to MX 0 . One means I am a host, I exist, but I don't know my/have a address presumably because it is offline, the other means There is no SMTP service for this domain. One is temp fail for SMTP, the other is a permanent fail. Mark. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Masataka Ohta's 2004 draft...
Francis Dupont wrote: Does several thousands of queries per second during normal operations with TCP matter? = yes because it is at the limit current OSs can do on cheap stock hardware... Are you saying real root servers are using cheap stock hardware? = current real root servers no but if Read the draft, before repeatedly demonstrating your stupidity in public. It is about the current configuration. Moreover, we'd like to run 100 or 100 times more we have first to lower requirements on the hardware. then, even though you haven't read the draft, it is obvious that 100 times more root servers means 100 times less load. And the argument applies to not root servers too. The argument in the draft is on the root servers. Aren't you arguing that the server should close connections only after a timeout because the server can not accept so many new connections? = no, I am arguing the requirement on TCP DNS to close at the server side only after a timeout It is because someone (Paul Vixie, perhaps) thought that several thousands new connection per second was harmful. Thus, today, the timeout can be 5, 1 or 0 seconds, if longer timeout is a problem (it is not, see below). makes most kernel improvements for HTTP servers useless for TCP DNS. Don't you know that, with HTTP/1.1, TCP connection is kept open even after a single query? I wonder how you can say I wrote OS. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
