Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Sat, 1 Nov 2014, John Levine wrote: I entirely agree ... the fact that reverse DNS works as a heuristic (and not an especially key heuristic) for IPv4 is not a reason for the considerable effort required to try and make it work as a an equally flawed heuristic on IPv6. There is a heuristic that says any host which is intended to act as a server visible to hosts on the public Internet should have matching forward and reverse DNS. (It does not say the converse; the presence of DNS doesn't mean a host is good, the absence means it's bad.) This seems to me to be perfectly relevant in IPv6. Which at the current deployment levels, is only valid for IPv4, not IPv6. Yet the anti-spammers have adopted it for IPv6. A rather significant difference between v4 and v6 is that you can create static generic rDNS for even a fairly large v4 allocation using something like $GENERATE, and it's well within the abilities of normal name servers to handle it. For v6, you need a stunt server or other kludge, with the kludges getting pretty intense if you want DNSSEC to work. So let's not bother. Yes, we have ways for hosts to install DNS entries for the addresses they're using, but they're not widely adopted, and I have bad feelings about their security characteristics. Are you saying now that the IPv6 reverse checks should be dropped? I'm confused. Beside the cost of creating the data and fetching it, there's the cost of caching it when people change the IP for every email sending attempt Although I think I was one of the first people to propose that, I still think that anyone who sends mail that way deserves what they get. Anti-spam measures should make it harder for spammers to send email, not for legitimate users. While there are trade-offs the current deployment of IPv6 is such that people are currently very limited in options to obtain native v6, and it often comes without reverse. If we want secure decentralised email, we should work on making it easier for people to run their own mailservers, not harder. Currently, the anti-spammers are causing a I gave up and use gmail wave of users. Really. There is one ISP in Canada offering native v6, and it does not come with delegations for reverse. I'm pretty sure Canada is not an isolated case. Blocking all IPv6 without reverse on smtp is simply an out of proportion meassure causing more harm than good. Doubly ironic since my email goes out with DKIM and is DNSSEC signed, you really don't need the reverse to check the validity of my email. Yes it will increase the load on your email server when you cannot blanket-block most of IPv6 outside the core. But is it really that prohibitive that you cannot afford to chain your anti-spam meassures appropriately and put DKIM before reverse DNS checks that are known to come with a high false positive rate? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
There is a heuristic that says any host which is intended to act as a server visible to hosts on the public Internet should have matching forward and reverse DNS. (It does not say the converse; the presence of DNS doesn't mean a host is good, the absence means it's bad.) This seems to me to be perfectly relevant in IPv6. Which at the current deployment levels, is only valid for IPv4, not IPv6. Yet the anti-spammers have adopted it for IPv6. I talk to a lot of people who run large mail systems at MAAWG, including some of the largest ones in Canada. Their experience with the v6 mail they send and receive is quite the opposite -- real mail hosts have real DNS, whether on v4 or v6. If your connection is over a consumer broadband network, your provider probably considers it a feature that it's hard for you to send mail without going through a relay with a static address and rDNS, not a bug. Are you saying now that the IPv6 reverse checks should be dropped? I'm confused. No, I'm saying that hosts with static addresses that are intended to be servers or mail clients should have DNS, for other hosts on random addresses, there's no point. If you want your hosts to be visible to your friends, you can use something like dyndns, and since they already know you, the absence of rDNS shouldn't matter. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
John Levine mailto:jo...@taugh.com Saturday, November 01, 2014 1:51 PM I entirely agree ... the fact that reverse DNS works as a heuristic (and not an especially key heuristic) for IPv4 is not a reason for the considerable effort required to try and make it work as a an equally flawed heuristic on IPv6. ... So let's not bother. Yes, we have ways for hosts to install DNS entries for the addresses they're using, but they're not widely adopted, and I have bad feelings about their security characteristics. (Hostile or buggy botware does an address hopping DDoS on your DNS infrastructure, for example.) john, richard, (others,) i've now heard from our friends in the last mile industry that the new york times web site won't serve web content to client IP's that lack PTR's. i havn't tested this, but hear me out. there is no RFC saying when PTR's are recommended and when not. john's formulation, There is a heuristic that says any host which is intended to act as a server visible to hosts on the public Internet should have matching forward and reverse DNS. (It does not say the converse; the presence of DNS doesn't mean a host is good, the absence means it's bad.) This seems to me to be perfectly relevant in IPv6, suits me just fine. if there were an RFC (let's be charitable and assume it would have to be an FYI due to lack of consensus) that gave reasons why PTR's would be needed and reasons why the absence might be better (so, internet access vs. internet service), then that RFC might give our last-mile industry buddies the air cover they need to be first movers in dropping PTR's for both V6 and V4 internet access addresses. it'll mean visiting the NYT tech team in person, no doubt, and then similar outreach to other smaller players. hard as it will be, dropping PTR for internet access addresses is at least thinkable, unlike, say, universal Source Address Validation. john, you're fast-good-and-cheap when it comes to whipping up sole-purpose RFC's. let us know which 25 of us you would like to list as co-authors, and we'll get you our authors addresses text blobs. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comment on draft-livingood-dnsop-negative-trust-anchors-01.txt
On Fri, Oct 31, 2014 at 8:17 PM, Brian Dickson brian.peter.dick...@gmail.com wrote: I think it is good to minimize disruption caused by broken DNSSEC domains, for all the reasons listed in the document. However, I also believe there is a second-order negative effect of implementing NTAs as described. Validating stub resolvers and validating forwarding resolvers, will still break. Yup. This is a feature, not a bug. NTA only makes the local / ISP resolver not perform validation for the domain. Anyone downstream who is doing validation will still perform the validation, and this will fail -- this is, IMO, the right thing to have happen. Downstream validators are presumably a: more security conscious and b: more able to troubleshoot DNS issues than my auntie. There is a big difference between handing back an answer as though you are not a validator (the NTA), and signing someone else's answer. W I do have a suggestion, which I hope is worth exploring and considering. For anyone using an open, well-known resolver (either provided by their ISP, or operated as a public service), include instructions on use of a provider-specific DLV and provider-specific alternative trust anchor (DNSKEY). Whenever it is necessary to over-ride broken DNSSEC zones, most likely on the Secure Entry Point, do the following: (1) Add a KSK to the apex DNSKEY RRset. For convenience use the same KSK for all such instances, and publish the public DNSKEY used. (2) Sign the apex DNSKEY RRset with this new KSK (3) Add this KSK into the DLV operated by the resolver operator at the appropriate location. For example, if example.com is broken, put the KSK at example.com.dlv.example.net, if the operator of the public resolver is example.net. (4) Observe successful validation of example.com by anyone configured to use dlv.example.net as their DLV. I haven't tried this, and there might be some specific modifications to what I described needed to make the configuration correct/functional. I don't believe it introduces new insecurities to anyone who already has placed trust in the resolver at example.net. (Is it the case that things that use DLV validate the chain of trust to the DLV itself, from the root, if there is not a separate trust anchor for the DLV zone? That would be optimal, security-wise, I believe.) Thoughts? Brian Dickson -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
vixie if there were an RFC (let's be charitable and assume it would vixie have to be an FYI due to lack of consensus) that gave reasons why vixie PTR's would be needed and reasons why the absence might be better vixie (so, internet access vs. internet service), then that RFC might vixie give our last-mile industry buddies the air cover they need to be vixie first movers in dropping PTR's for both V6 and V4 internet vixie access addresses. Hate to rain on your parade but this isn't going to happen. The problem is not one example, like NYT. It's that we have 20+ years of sloppy habits and people making golden calves of PTR records. As a last mile provider, customer screams are way more expensive than just whipping out garbage PTRs that mean nothing and are of no security/validation use but mean I don't get calls. I don't even know how many broken sites there are and I don't care to waste valuable staff time tilting at this windmill. I just want to avoid customer calls by suddenly deciding after decades that PTR records deserve to be cleaned up. My current expecation is somewhat like the following: - all routers/network interfaces will have PTRs so my traceroutes are of some use to my NOC - all service machines will have legit forward and reverse that match so that I can keep track of my own stuff and other folks will have less reason to ditch my email traffic - will probably get our DNS server folks to do lie on the fly v6 PTRs for any customer addrs, with sign on the fly so they do at least DNSSEC validate Folks using PTRs for insane uses like as part of VPN validation, to get web content or similar things that were useless in v4 will get the same delusional warm fuzzies they get now. Folks that find the current $GENERATE v4 stuff evil and untrustworthy will find the v6 stuff no better. Folks trying limit spam will hopefully figure out something that doesn't involve reputation by IPv6 addr, 'cause at 18 quadrillion per /64, that won't scale... ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comment on draft-livingood-dnsop-negative-trust-anchors-01.txt
Sent from my iPhone On Nov 1, 2014, at 4:30 PM, Warren Kumari war...@kumari.net wrote: On Fri, Oct 31, 2014 at 8:17 PM, Brian Dickson brian.peter.dick...@gmail.com wrote: I think it is good to minimize disruption caused by broken DNSSEC domains, for all the reasons listed in the document. However, I also believe there is a second-order negative effect of implementing NTAs as described. Validating stub resolvers and validating forwarding resolvers, will still break. Yup. This is a feature, not a bug. NTA only makes the local / ISP resolver not perform validation for the domain. Anyone downstream who is doing validation will still perform the validation, and this will fail -- this is, IMO, the right thing to have happen. Downstream validators are presumably a: more security conscious and b: more able to troubleshoot DNS issues than my auntie. There is subtlety in using DLV instances. On the one hand, passing along answers that have known DNSSEC validation problems avoids blocking your auntie. On the other hand, if it is known to have problems, stitching things up in ways that still don't validate without use of DLV isn't really any worse. And on the gripping hand, adding the fix in DLV, for only those who have configured that specific DLV, means those clients are able to validate. Furthermore, those doing advanced level DNS operations are unlikely to use NTA implementer services. And, IMHO, advanced operators could signal a desire for unmodified answers the traditional way, via the CD bit. Adding the DLV function provides a scaling benefit in terms of how many validating forwarders need to make the NTA mod to resolve the affected domain. Without DLV, there is still an incentive to turn off validation -- which is what NTA is explicitly trying to prevent. Having forwarders validate should be something we all encourage and support, especially in this sort of document. I definitely think it is up to each operator as to whether they do this. However, I would like this to be included in the draft as an optional aspect of setting up NTAs, so that operators can evaluate the pros and cons, and make informed choices. Brian There is a big difference between handing back an answer as though you are not a validator (the NTA), and signing someone else's answer. W I do have a suggestion, which I hope is worth exploring and considering. For anyone using an open, well-known resolver (either provided by their ISP, or operated as a public service), include instructions on use of a provider-specific DLV and provider-specific alternative trust anchor (DNSKEY). Whenever it is necessary to over-ride broken DNSSEC zones, most likely on the Secure Entry Point, do the following: (1) Add a KSK to the apex DNSKEY RRset. For convenience use the same KSK for all such instances, and publish the public DNSKEY used. (2) Sign the apex DNSKEY RRset with this new KSK (3) Add this KSK into the DLV operated by the resolver operator at the appropriate location. For example, if example.com is broken, put the KSK at example.com.dlv.example.net, if the operator of the public resolver is example.net. (4) Observe successful validation of example.com by anyone configured to use dlv.example.net as their DLV. I haven't tried this, and there might be some specific modifications to what I described needed to make the configuration correct/functional. I don't believe it introduces new insecurities to anyone who already has placed trust in the resolver at example.net. (Is it the case that things that use DLV validate the chain of trust to the DLV itself, from the root, if there is not a separate trust anchor for the DLV zone? That would be optimal, security-wise, I believe.) Thoughts? Brian Dickson -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
