Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
I'll take a dollar for every query in PTR we take at the ipv4 /8 and Ipv6 /12 level. Thats somewhere around 170,000/sec. Luckily, you'll all stop before I have the entire western economy in my pocket, but thats ok. I'll take the cents.. I'll take the millicents... Seriously: the volume of query is not small. It may be pointless but by golly its popular. What do people do with it? I have no idea. But as long as people want to query, the RIR are happy to anchor the domains. -G On Mon, Nov 10, 2014 at 11:24 AM, Ted Lemon ted.le...@nominum.com wrote: On Nov 10, 2014, at 11:10 AM, Paul Ebersman list-dn...@dragon.net wrote: If I wait until I have screaming customers, I have months and months of hell before I have any solution. So deploy the solutions the IETF is already working on. You are proposing we do something bad to solve a problem that demonstrably does not exist, when we are already pursuing a solution that would be good, not bad. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
sthaug If you assume that IPv6 mail servers have static PTRs, there is sthaug zero added value (and a bit of work) in creating/synthesizing sthaug IPv6 PTRs for residential customers. Much better to simply not sthaug do it in the first place. I'm in agreement that legitimate, well run mail servers will have static forward and reverse in v6. My concern is random folks who currently accept any v4 PTR regardless of format (but caring if there is no PTR at all) will do something equally bad in v6. i.e. NYT web content and similar pointless cruft. Putting in an auto-gen'ed v6 PTR would satisfy that level of check. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
ebersman It's a nice thought. But considering how little we've ebersman converged on SLAAC vs DHCPv6, random assignment vs eui-64 vs ebersman static for host ID, RFC 6106 vs DHCPv6 DNS, etc. (and I won't ebersman even start on how many IPv6 transition techs there are), any ebersman consensus on better is going to be a fascinating trick. TLemon This is not an accurate representation of the situation. There TLemon are some people who see DHCPv6 versus SLAAC as an ideological TLemon problem rather than a choice between features, but this is TLemon completely orthogonal to the DNS issue. Sorry. Unclear analogy. Not conflating v6 and DNS, just pointing out that reaching consensus when we have non-compatible operational views and requirements tends to not lead to a solution in any real time frame. Proponents of SLAAC vs DHCPv6 tend to have different pain points and biases based on how they run their networks and we aren't likely to come to a meeting of the minds any time soon due to those differing needs. Not saying either network design is wrong or bad either. Just saying that different needs means we won't get a one size fits all solution. TLemon There is real work going on on the DNS problem, and while it's TLemon not clear everyone will want to deploy a nice solution, I don't TLemon think there's any serious argument within the IETF that such a TLemon solution should not be deployed, nor is there serious contention TLemon over how to do it (although there are several options). I don't TLemon _think_ there are any ideological disputes; the question is TLemon simply which solution is best for any particular use case. And, TLemon of course, actually getting the documents done that describe the TLemon several different ways of approaching the problem. I'd agree that we all would like the option of a nice use of PTRs. It does seem like there are two sets of conflicting pain points for which it's not clear to me there is a compromise in what we're talking about in this draft. The two groups with obvious pain points are: - service providers who want a way to avoid breaking things for customers while not being operationally complicated/insane - mail/spam folks who seem to be saying that the current v4 method is a time bomb that will explode any minute, is unmaintainable and doing v6 the same way is untenable to them Doing autogen'd PTRs in v6 violates the anti-spam folks' needs. Not having any PTR at all for consumers potentially violates the ISP needs. Things I don't know that anyone knows for sure but make it hard to reach consensus on a solution: - what are the various interesting/crazy/insane uses PTRs in v4 now (beyond the mail req of forward/reverse existing and matching), i.e. what will break now and in the future if there are no v6 PTRs for consumer IPs if content providers do the same uses in v6 - how much is the current v4 autogen being done by ISPs truly breaking mail/spam, how/when/how-soon will it explode and how much additional stress/breakage would doing v6 autogen add ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Nov 9, 2014, at 11:31 PM, Paul Ebersman list-dn...@dragon.net wrote: My concern is random folks who currently accept any v4 PTR regardless of format (but caring if there is no PTR at all) will do something equally bad in v6. i.e. NYT web content and similar pointless cruft. Putting in an auto-gen'ed v6 PTR would satisfy that level of check. The status quo is that the ISP doesn't add a PTR record for a customer IPv6 address, nor delegate the zone. Lots of IPv6 users are getting by just fine right this very moment (including me) without this. So I think it's safe to say that we do not need to solve this problem: if there is damage, it has already been routed around. So really all we need to talk about is whether there are features to add, not whether we need to fix something right now. It's already too late for that. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Nov 9, 2014, at 11:57 PM, Paul Ebersman list-dn...@dragon.net wrote: Sorry, I replied to a message prior to your reply to me, and so I sort of answered these points, but just to clarify: - service providers who want a way to avoid breaking things for customers while not being operationally complicated/insane Doing autogen'd PTRs in v6 violates the anti-spam folks' needs. Not having any PTR at all for consumers potentially violates the ISP needs. Things I don't know that anyone knows for sure but make it hard to reach consensus on a solution: - what are the various interesting/crazy/insane uses PTRs in v4 now (beyond the mail req of forward/reverse existing and matching), i.e. what will break now and in the future if there are no v6 PTRs for consumer IPs if content providers do the same uses in v6 - how much is the current v4 autogen being done by ISPs truly breaking mail/spam, how/when/how-soon will it explode and how much additional stress/breakage would doing v6 autogen add So it's not clear to me that there is a problem reaching consensus on what we should do. It's not even clear to me (as I explained in my previous message) that there is a problem or a pain point here for IPv6. It's pretty clear to me that the only sensible thing the IETF could do would be to say this isn't a problem, please don't add fake PTR records. And then ISPs would do whatever they do, regardless of what we recommend. My hope is that they would not _anticipate_ a problem that does not actually exist, and create complex wonderfulness in their DNS architecture purely to solve that possibly nonexistent problem. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
ebersman My concern is random folks who currently accept any v4 PTR ebersman regardless of format (but caring if there is no PTR at all) ebersman will do something equally bad in v6. i.e. NYT web content and ebersman similar pointless cruft. Putting in an auto-gen'ed v6 PTR ebersman would satisfy that level of check. TLemon The status quo is that the ISP doesn't add a PTR record for a TLemon customer IPv6 address, nor delegate the zone. Lots of IPv6 TLemon users are getting by just fine right this very moment (including TLemon me) without this. So I think it's safe to say that we do not TLemon need to solve this problem: if there is damage, it has already TLemon been routed around. This is a lovely thought. And I really hope it's true. I've thought since the early 90s that most things we did with PTRs other than network interfaces were questionable usefulness for pain that we're still dealing with supporting. However, I'm concerned that this (v6 working fine without already) is just as much an unsupported assumption as that we must support PTRs for content with no good data (other than various anecdotal stories) and no idea of what would break if we didn't do them. IPv6 is still in early adoption for broad general use and we don't know what plans folks have for requiring PTRs. TLemon So really all we need to talk about is whether there are TLemon features to add, not whether we need to fix something right now. TLemon It's already too late for that. I would still like to see: - actual data on how/where PTRs are being used and abused now (beyond the known mail filtering) to see if any of those folks are planning on continuing the bad idea into v6 - suggestions on how/if we can clean PTR usage, v4 and v6 I'm not expecting anything I'll be able to use to clean up current v4 usage, but I'd love to be pleasantly surprised. If someone does come up with a solid performance/efficiency improvement or a biz case for keeping better track and use, I'd certainly take that to my mgmt. As for the current draft, if it doesn't happen, I'll still need to cope with customer breakage and vendors will produce solutions that customers like me pay for. I'd much rather have a consistent approach across vendors and guidance in the IETF I can point to but I will probably have to do something about PTRs in the next year or two. And it will probably be something icky but less icky than screaming customers... ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
sthaug To me this is really simple: If many/most ISPs continue *not* sthaug adding useless/artificial/synthesized PTRs, the content / server sthaug people will have no choice - if they want their content to get sthaug out and their services to be used by the large majority of IPv6 sthaug users, they'll have to accept connections from IPv6 addresses sthaug without PTRs. One hopes... I would certainly love to not have to do (yet more) crap PTRs. I'm just not as optomistic that stupid people aren't really really persistent. And I'd still love to get better data on how it's currently used. If I could also stop doing the v4 crap and not have users screaming, that's a large pain point gone. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Nov 10, 2014, at 8:32 AM, Paul Ebersman list-dn...@dragon.net wrote: IPv6 is still in early adoption for broad general use and we don't know what plans folks have for requiring PTRs. I apologize for picking and choosing from your response, but I think this sums it up perfectly: if we do not yet know what plans they have, then we need not care. There is currently no support in any infrastructure of which I am aware for populating the reverse tree in IPv6 for customer IP addresses. Lots of customers are using IPv6, and are not having issues. It is indeed early days, but Comcast's deployment, and other deployments of which I am aware, are seeing real use by real users. So if e.g. Comcast were coming to us right now and saying we're getting a lot of phone calls because of foo, then we could talk about foo. But that's not happening, as far as I can tell. IOW, you are borrowing trouble. Please don't borrow trouble. At present we do not need to clean up the IPv6 reverse tree. If we say anything about the reverse tree, it should be with the goal in mind of preserving that pleasant status quo. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
ebersman IPv6 is still in early adoption for broad general use and we ebersman don't know what plans folks have for requiring PTRs. TLemon I apologize for picking and choosing from your response, but I TLemon think this sums it up perfectly: if we do not yet know what TLemon plans they have, then we need not care. [...] TLemon So if e.g. Comcast were coming to us right now and saying we're TLemon getting a lot of phone calls because of foo, then we could talk TLemon about foo. Comcast (or any large company/provider) does not move nimbly. The IETF does not move nimbly. Vendors do not implement what the IETF specifies energetically without beating/cash. I'm sympathetic to the idea that I should avoid borrowing trouble. However, I'd say that looking ahead and trying to be prepared for things that seem likely is not borrowing trouble; it's being prepared. If I wait until I have screaming customers, I have months and months of hell before I have any solution. Hence why I'm suggesting that we document v4 PTR usage and make recommendations on what we think are appropriate usage. If we can get a better idea of what bad ideas are being done now and try to folks to not do this, then we can indeed maintain the pleasant status quo in v6 PTRs. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Nov 10, 2014, at 11:10 AM, Paul Ebersman list-dn...@dragon.net wrote: If I wait until I have screaming customers, I have months and months of hell before I have any solution. So deploy the solutions the IETF is already working on. You are proposing we do something bad to solve a problem that demonstrably does not exist, when we are already pursuing a solution that would be good, not bad. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Thu, Nov 06, 2014 at 08:26:17AM +0100, sth...@nethelp.no sth...@nethelp.no wrote a message of 24 lines which said: Putting my ISP hat on, I'd have to agree with the security/stability reasons (and several others I can think of). As of today, I have zero incentive to let my residential customers create their own PTR records. Putting my customer hat on: I want PTR for my machines (many hosters allow it, like Linode or Gandi). Is it sufficient incentive for a provider? N customers want it, with N 0 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Putting my ISP hat on, I'd have to agree with the security/stability reasons (and several others I can think of). As of today, I have zero incentive to let my residential customers create their own PTR records. Putting my customer hat on: I want PTR for my machines (many hosters allow it, like Linode or Gandi). Is it sufficient incentive for a provider? N customers want it, with N 0 Business customers can already have static IPv6 PTRs, no problem. Residential customers and the proposed scheme of dynamically creating/ updating PTRs: N would have to be sufficiently large, or there would have to be other reasons (e.g. competitive pressure). Even if these conditions were fulfilled, it would still be prioritized against many other requirements. In other words: Don't hold your breath. Steinar Haug, AS 2116 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
To step back up a level again. Most ISPs and most email/spam folks find the current v4 pointer usage to be functional. I'm not saying that we all think it's not somewhat broken, couldn't be better, etc. However, it solves the problems it's supposed to solve in a functional way and doesn't generate lots of customer complaints. This draft basically outlines how to get more or less the same level of functionality and trust that exists in v4 in v6. The techniques being described in the draft are in use or being implemented soon and there is value in having an IETF draft that documents what is being done and what the operational tradeoffs are. Describing current state of operations and operational tradeoffs is the DNSOP bailiwick. There have been several comments about wanting to clean up PTR usage, either doing better in v6, or in both v4 and v6. There were also several folks observing that documenting how PTRs are actually being used would be handy. I think both a how are PTRs currently used and a how to do better with PTRs are both useful but should be separate drafts from this one. I'd even push that the how to do better talk about v4 and v6. As an operator, I'm not sure when or if I'd ever be allowed to spend resources to clean things up. However, if we can document what will actually break and how and why to better and there's some business problem solved or business opportunity created, I might have a fighting chance of getting resources to do this. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Nov 9, 2014, at 12:01 PM, Paul Ebersman list-dn...@dragon.net wrote: Most ISPs and most email/spam folks find the current v4 pointer usage to be functional. This assertion with respect to spam at least does not seem to match what's actually been said on the list by people who are in a position to know. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Moin! Read this draft on the way to the IETF and while saw there was a lot of discussion around it I didn't read all of it, so forgive me if stuff has been said before. First I think it is good to have a draft that captures what you can do and what the challenges for IPv6 reverse are. However as the discussion on what is the best way to do will never come to an end as people have strong opinions on that we should leave that or the recommendations section out of the draft and just publish it as informational. You could if you want to leave that section in just say that there is no clear way to recommend anything as there are different scenarios that apply to different operators and that everybody has to pick their own poison ;-). One thing I would like to see added is delegating reverse and corresponding forward to CPE (homenet router), but serving it out of the service providers name servers as described in https://tools.ietf.org/html/draft-mglt-homenet-front-end-naming-delegation-04 (full disclosure I am co-author of this). While I like the idea of delegating the naming responsibility to the end user/home I personally don't think it is a good thing for the Internet to generate millions of DNS servers on CPE devices as we already have enough problems with that (http://openresolverproject.org granted different kind of dns server/proxy but I assume hackers will find way to abuse these also). So long -Ralf --- Ralf Weber e: d...@fl1ger.de ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On November 9, 2014 2:08:28 PM PST, Ted Lemon ted.le...@nominum.com wrote: On Nov 9, 2014, at 12:01 PM, Paul Ebersman list-dn...@dragon.net wrote: Most ISPs and most email/spam folks find the current v4 pointer usage to be functional. This assertion with respect to spam at least does not seem to match what's actually been said on the list by people who are in a position to know. Indeed not. We currently have to maintain a large and complex distributed registry of ipv4 ptr patterns which are meaningless and must therefore be filtered out before making policy decisions about the presence/absence and match/doesn't of a ptr record and it's associated a record. V6 should attempt to be better than v4 in this regard. In fact v4 should attempt to improve in this regard. Functional at high cost and risking complexity collapse every day and twice on Sunday is not a status quo to love, not to copy from v4 to v6. Vixie -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ 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 Indeed not. We currently have to maintain a large and complex vixie distributed registry of ipv4 ptr patterns which are meaningless vixie and must therefore be filtered out before making policy decisions vixie about the presence/absence and match/doesn't of a ptr record and vixie it's associated a record. You are already doing this, correct? Not good, has pain, but at least in place? And if I used a generation method for v6 that exactly matched v4, I'd just get caught in exactly the same filters, right? I know you want to make things better but does adding v6 records with the same format make things worse or just no better? If the current v4 is so fragile, it will break at any minute, you're already at risk. If what I produce in v6 adds no new checks, it should add no new risks; only the risk you have in v4 already. vixie V6 should attempt to be better than v4 in this regard. In fact v4 vixie should attempt to improve in this regard. It's a nice thought. But considering how little we've converged on SLAAC vs DHCPv6, random assignment vs eui-64 vs static for host ID, RFC 6106 vs DHCPv6 DNS, etc. (and I won't even start on how many IPv6 transition techs there are), any consensus on better is going to be a fascinating trick. I have already mentioned that you and others are interested in some PTR usage solution that is better for both v4 and v6. And having actual real data on what is using PTRs in v4 and how as a second draft. I'd love to have real data to make an informed choice. I'm just suggesting that doing so is two drafts and significant effort on their own. paul Functional at high cost and risking complexity collapse every day paul and twice on Sunday is not a status quo to love, not to copy from paul v4 to v6. And what's the plan for v4 if collapse is imminent? Who's working on it? And I sure hope it isn't that v6 will just replace v4, if time is of the essence. Large providers, including my $DAYJOB, are already looking at what/where/how we should do PTRs in v6. Going back to management and saying that we need to completely redo v4 (which they view as already working) and do v6 in some complicated way isn't something they're going to buy into without solid business case for cost savings and/or new income stream. So far, I haven't heard anything like those, for this draft or in potential new drafts. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
In message 6c6d2bc0-4099-4f9c-ade4-f9dd021da...@fl1ger.de, Ralf Weber writes: Moin! Read this draft on the way to the IETF and while saw there was a lot of discu ssion around it I didn't read all of it, so forgive me if stuff has been said before. First I think it is good to have a draft that captures what you can do and wh at the challenges for IPv6 reverse are. However as the discussion on what is the best way to do will never come to an end as people have strong opinions o n that we should leave that or the recommendations section out of the draft a nd just publish it as informational. You could if you want to leave that sect ion in just say that there is no clear way to recommend anything as there are different scenarios that apply to different operators and that everybody has to pick their own poison ;-). One thing I would like to see added is delegating reverse and corresponding f orward to CPE (homenet router), but serving it out of the service providers n ame servers as described in https://tools.ietf.org/html/draft-mglt-homenet-fr ont-end-naming-delegation-04 (full disclosure I am co-author of this). While I like the idea of delegating the naming responsibility to the end user/home I personally don't think it is a good thing for the Internet to generate mill ions of DNS servers on CPE devices as we already have enough problems with th at (http://openresolverproject.org granted different kind of dns server/proxy but I assume hackers will find way to abuse these also). For the home user CPE you use DNS COOKIES / SIT or push to TCP. These should be low volume authoritative server. So long -Ralf --- Ralf Weber e: d...@fl1ger.de ___ 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] Draft Reverse DNS in IPv6 for Internet Service Providers
John Levine jo...@taugh.com wrote: Do we know whether typical PTR checks look for existence or matching? The ones I know all look for matching. My understanding is that mail servers will often just do existence checks because the matching check causes too much trouble for legitimate mail. (My servers don't enforce these checks so I don't have first-hand experience.) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Southeast Iceland: Cyclonic 5 or 6, becoming northerly gale 8 to storm 10 later. Rough becoming very rough or high. Occasional rain. Moderate or poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Joel, Thanks for this clarification on the process, I was on a plane :-) On Nov 6, 2014, at 12:23 PM, joel jaeggli joe...@bogus.com wrote: On 11/5/14 12:50 PM, Paul Vixie wrote: the lack of consensus means it can't be a proposed standard, not that it can't be an FYI, BCP or similar, right? BCP requires consensus after a fashion very similar to a standards track document. something with no-consensus basis would probably go to the ISE. Some that people do not oppose publication of even if they disagree with it might be informational. but this is all jail-house lawyering, if the w.g. can't build a consensus then it doesn't advance as a w.g. document. This is the important point. I tend to think we should have a topic/question/issue and a consensus to work on it before we get too concerned about a document status; it's an important detail, especially if we want a document status that requires IETF consensus for publication (standard or BCP), but finalizing it can be part of finalizing the document. In this particular discussion, I've heard multiple positions stated on the technical/operational issues and multiple opinions on where a consensus could be, if any. The extent and thoughtfulness of the discussion suggest there's indeed work to do for us here. Personally, I'd like to see us attempt to document the landscape, including consensus where we have it and description where we don't, but I understand the reason for skepticism. Suzanne ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Andrew Sullivan wrote: Especially in the absence of strong anti-spoofing mechanisms, like the DNS Security Extensions, a check for matching reverse DNS mapping should be regarded as an extremely weak form of authentication. Considering that DNS Security Extension provides weak security only blindly relying on untrustworthy TTPs, it is better to say; Especially in the absence of strong anti-spoofing mechanisms, a check for matching reverse DNS mapping should be regarded as a weak form of authentication. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Putting my ISP hat on, I'd have to agree with the security/stability reasons (and several others I can think of). As of today, I have zero incentive to let my residential customers create their own PTR records. Better tools and systems may change this, but it would in any case be *way* down on the priority list. Considering that PTRs generated by ISPs are too often useless, are you saying you won't provide PTRs? For our residential customers, we provide IPv4 PTRs which indicate that this is a dynamic address. We *don't* plan to provide IPv6 PTRs for those same customers. Steinar Haug, AS 2116 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
sth...@nethelp.no wrote: For our residential customers, we provide IPv4 PTRs which indicate that this is a dynamic address. We *don't* plan to provide IPv6 PTRs for those same customers. That's fine. But, what we need is opinions of ISPs which are allowing customers supply PTRs for IPv4, doesn't it? Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
marka For in-addr.arpa you already have a PTR records. Allowing the marka end user to set its content does not increase the amount of data marka you are serving. It does increase the amount of churn in the marka zone. This draft isn't talking about v4. And $GENERATE or equiv already works in that most customers don't scream. I have no incentive to change to a more risky and complicated and hard to maintain system for v4. I'd contend that the folks who check v4 PTRs will have the same level of trust with auto-gen'ed v6 that they do with v4. Folks that don't trust it now still won't and those that find it acceptible in v4 will accept it in v6. marka The occasional customer will add a offensive PTR record which marka won't be seen by 99.9% of the world. [...] marka If we recommend that this is only done when a forward record is marka also successfully added UPDATE + TSIG (yes, this does scale for marka this use) you get rid of the PTR/A mis-match issues. And we're definitely not talking about allowing customers to do dynamic updates of forward records in this draft. If you want that currently, you get a business account or use one of the many services that allows that. Yes, it costs money. But most folks don't seem to miss it in the consumer world and those that do find someone willing to do it. marka For ip6.arpa you delegate to the customer along with the prefix marka delegation. The customer has to deal with the space issues but marka uses the same mechanisms to add the PTR records and cleanup. Because the mythical grandmother wants to deal with their own address space. Right... Most customers don't even know what DNS is, much less PTRs. They want to get content, send emails and pictures of cats. As an ISP, it's our job to make sure this works. $GENERATE in v4 does work. Auto-gen'ed PTRs in v6 works as well as $GENERATE, no better, no worse. marka You get the equivalent of $GENERATE with customer settable marka overrides using UPDATE over TCP. And I want 10s of millions of users doing TCP to my auth servers? I think not. Certainly not for something of so little gain to my customers. ebersman Anti-spam folks *like* it that it's not trivial to get ebersman correct rDNS/PTRs. It's easy to find consumer connections ebersman based on the ISP doing bulk/lazy PTR generation and just ebersman reject SMTP traffic from them. marka Which won't work in IPv6 unless you syntesize the records on marka demand. And that's the plan, at least for $DAYJOB. And sign on the fly for those of us signing our zones. ebersman Large ISPs don't care about clean PTRs as long as no customers ebersman complain and they don't care if end customers can't do SMTP ebersman without having to ask for it in some special way. marka Except autogenerated PTR records don't solve the problem. How not? Works fine for v4 right now. Customers that want to do their own email usually have to make a special request to their ISP but can do it. Biz connections are allowed to do their own PTRs at most ISPs, assuming the customers want and need it. And if they do clean PTRs as part of this, the anti-spam folks are happy. ebersman What else in the way of tradeoffs is missing? marka That people want IP to name mappings for their internal networks. Get a biz connection or a service to allow this. marka With things like DNSSEC you need break DNSSEC trust chains at the marka ISP level for this to work. Even our biz customers mostly don't do or want DNSSEC on PTRs. As this changes, we'll figure out how to do this as a service. But all the work of getting in DS and doing clean zone cut and delegation has nothing to do with this draft either. marka We also don't know what else will come along to use the reverse marka namespace. It is a good place to hang keying material which is marka tied to IP address. So you're volunteering to work on a draft mentioned documenting how folks are using PTR space? Thanks! marka Having a well defined method to update this name space will be marka useful. Another draft. But not this one. If such a method did already exist, worked and had at least reference implementations, it would certainly be worth mentioning in this draft. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Thu, Nov 06, 2014 at 08:24:35AM -0700, Paul Ebersman wrote: marka Which won't work in IPv6 unless you syntesize the records on marka demand. And that's the plan, at least for $DAYJOB. And sign on the fly for those of us signing our zones. I'm going to take the risk of embarrassing myself in public and ask the stupid thing I've been wondering: Is there a reason not to use wildcard PTRs? $ORIGIN 6.7.6.2.7.6.7.0.1.0.0.2.ip6.arpa. * 604800 IN PTR home-ipv6-customer.isp.net. This way, a PTR would exist for every address, so broken sshd and similar daemons will work. It's easy to grep for, so antispam folks should be content. The wildcard record can be signed, which is trickier to do with on-demand PTR synthesis. If you want to sell a customer their own PTR or delegated reverse zone, you still can. You don't end up with a unique PTR for each address, and you'll get answers for addresses that aren't in use... but those kind of seem like features, not bugs. Also, it's cheap. So, are there technical reasons not to do this, or is it just conceptual inertia from the use of $GENERATE for v4? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On 11/5/14 12:50 PM, Paul Vixie wrote: Andrew Sullivan mailto:a...@anvilwalrusden.com Wednesday, November 05, 2014 10:50 AM On Wed, Nov 05, 2014 at 10:19:59AM -0800, 神明達哉 wrote: https://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 ... ... I believed I had watered down the draft so thoroughly that it would be impossible for anyone to disagree with it. I was evidently wrong. If we're going to bring that thing back up (in any sense you like), then I think it needs to get a spine. Perhaps also my willingness to try to find consensus has declined in the intervening years: I just don't think there _is_ a consensus on this. the lack of consensus means it can't be a proposed standard, not that it can't be an FYI, BCP or similar, right? BCP requires consensus after a fashion very similar to a standards track document. something with no-consensus basis would probably go to the ISE. Some that people do not oppose publication of even if they disagree with it might be informational. but this is all jail-house lawyering, if the w.g. can't build a consensus then it doesn't advance as a w.g. document. the fact of the network is, without a PTR you will have a hard time originating TCP/25. we should say that. another fact is, not everyone who should be able to (non-maliciously) access your web service will have a PTR. we should say that, too. those aren't opinions and they shouldn't be controversial. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
stupid thing I've been wondering: Is there a reason not to use wildcard PTRs? $ORIGIN 6.7.6.2.7.6.7.0.1.0.0.2.ip6.arpa. * 604800 IN PTR home-ipv6-customer.isp.net. This turns out to be a Well Known Bad Idea (WKBI). Most PTR checks look up the name to be sure there's a matching forward ( in this case) record, and ignore them if there isn't. You can't do that with wildcard PTRs unless you have some way of serving 2^64 records in a single response. R's, John PS to the literal minded: yes, I know that's impossible. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Nov 6, 2014, at 9:33 AM, John Levine jo...@taugh.com wrote: stupid thing I've been wondering: Is there a reason not to use wildcard PTRs? $ORIGIN 6.7.6.2.7.6.7.0.1.0.0.2.ip6.arpa. * 604800 IN PTR home-ipv6-customer.isp.net. This turns out to be a Well Known Bad Idea (WKBI). Most PTR checks look up the name to be sure there's a matching forward ( in this case) record, and ignore them if there isn't. I think Evan was proposing that home-ipv6-customer.isp.net would also exist, so a PTR check that looked for *existence* would succeed, but one that looked for *matching* would fail for most of those addresses. Do we know whether typical PTR checks look for existence or matching? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Thu, Nov 06, 2014 at 05:33:10PM -, John Levine wrote: This turns out to be a Well Known Bad Idea (WKBI). Most PTR checks look up the name to be sure there's a matching forward ( in this case) record, and ignore them if there isn't. I see. Too bad. Is it any more feasible to adjust expectations for v6 in this respect than it was when we were talking about not providing PTR for v6 in the first place? For whatever it's worth I've been running with a wildcard PTR for my hurricane-tunnel v6 network at home for more than four years. It's only a dozen or so addresses, but I haven't hit any obvious problems. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
I think Evan was proposing that home-ipv6-customer.isp.net would also exist, so a PTR check that looked for *existence* would succeed, but one that looked for *matching* would fail for most of those addresses. Do we know whether typical PTR checks look for existence or matching? The ones I know all look for matching. It's too easy for a malicious or negligent provider (typically in eastern Europe or Asia) to stick in PTRs like mail.google.com. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Paul Hoffman mailto:paul.hoff...@vpnc.org Thursday, November 06, 2014 9:41 AM ... Do we know whether typical PTR checks look for existence or matching? in postfix, it's matching. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Thu, Nov 06, 2014 at 09:41:57AM -0800, Paul Hoffman wrote: I think Evan was proposing that home-ipv6-customer.isp.net would also exist, so a PTR check that looked for *existence* would succeed, but one that looked for *matching* would fail for most of those addresses. Do we know whether typical PTR checks look for existence or matching? Matching could work, too, if they were able to compare prefixes rather than full addresses, but that's obviously a bigger leap. I suspect John is correct and the idea isn't practical. Alas. Thanks for the education, carry on. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Most PTR checks look up the name to be sure there's a matching forward ( in this case) record, and ignore them if there isn't. I see. Too bad. Is it any more feasible to adjust expectations for v6 in this respect than it was when we were talking about not providing PTR for v6 in the first place? Considering the security issues involved, I sure hope not. For whatever it's worth I've been running with a wildcard PTR for my hurricane-tunnel v6 network at home for more than four years. It's only a dozen or so addresses, but I haven't hit any obvious problems. I see a lot of v4 PTRs that don't forward resolve when doing header analysis for spam reports. The majority just seem sloppy, but a fair number are malicious and try to impersonate someone. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Evan Hunt mailto:e...@isc.org Thursday, November 06, 2014 9:46 AM I see. Too bad. Is it any more feasible to adjust expectations for v6 in this respect than it was when we were talking about not providing PTR for v6 in the first place? sadly, ipv6 isn't deployed enough that a v6-only end host can get real work done, but ipv6 is however deployed just well enough that we can't change what PTR means at this point. see also: http://www.circleid.com/posts/20110607_two_stage_filtering_for_ipv6_electronic_mail/ noting that in 2011 it was already too late for foundational recommendations on ipv6. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Thu, Nov 06, 2014 at 09:41:57AM -0800, Paul Hoffman wrote: Do we know whether typical PTR checks look for existence or matching? It depends. (We covered this to some extent in that failed reverse-tree draft.) A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
phoffman Do we know whether typical PTR checks look for existence or phoffman matching? johnl The ones I know all look for matching. For MX/spam and for VPNs, seems to want matching. For more fringe uses like NYT web, seems to just want a non-NXDOMAIN response. I'd be nervous about wildcard more because there seems to be a fair amount of variation in implementations (or folks who don't read RFCs but play with DNS...). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
In message 20141106152435.7ad4caa0...@fafnir.remote.dragon.net, Paul Ebersman
writes:
marka For in-addr.arpa you already have a PTR records. Allowing the
marka end user to set its content does not increase the amount of data
marka you are serving. It does increase the amount of churn in the
marka zone.
This draft isn't talking about v4. And $GENERATE or equiv already works
in that most customers don't scream. I have no incentive to change to a
more risky and complicated and hard to maintain system for v4.
I'd contend that the folks who check v4 PTRs will have the same level of
trust with auto-gen'ed v6 that they do with v4. Folks that don't trust
it now still won't and those that find it acceptible in v4 will accept
it in v6.
And why can't we improve IPv4 at the same time using the same
mechanisms?
Also the examples are easier to type into a 80 column window. The
only difference between IPv4 and IPv6 on the client node is the
name of the PTR record.
marka The occasional customer will add a offensive PTR record which
marka won't be seen by 99.9% of the world.
[...]
marka If we recommend that this is only done when a forward record is
marka also successfully added UPDATE + TSIG (yes, this does scale for
marka this use) you get rid of the PTR/A mis-match issues.
And we're definitely not talking about allowing customers to do dynamic
updates of forward records in this draft.
With IPv4 most ISPs supply both fake/generic forward and reverse
zones for those that check PTR records with A lookups.
If you want that currently, you get a business account or use one of the
many services that allows that. Yes, it costs money. But most folks
don't seem to miss it in the consumer world and those that do find
someone willing to do it.
Actually it is often impossible to find a ISP willing + same or
better speed let alone for a reasonable price. Sometimes you can't
get it for any price at any speed because the end point of the
connection is in a residence and the only ISP's servicing the area
won't sell a business class connection to the address.
So no, get a business account is *not* a viable alternative.
I'm and sick and tired of Were the phone company and you just have to
lump it which is all this alternative is.
marka For ip6.arpa you delegate to the customer along with the prefix
marka delegation. The customer has to deal with the space issues but
marka uses the same mechanisms to add the PTR records and cleanup.
Because the mythical grandmother wants to deal with their own address
space. Right...
Most customers don't even know what DNS is, much less PTRs. They want to
get content, send emails and pictures of cats. As an ISP, it's our job
to make sure this works. $GENERATE in v4 does work. Auto-gen'ed PTRs in
v6 works as well as $GENERATE, no better, no worse.
marka You get the equivalent of $GENERATE with customer settable
marka overrides using UPDATE over TCP.
And I want 10s of millions of users doing TCP to my auth servers? I
think not. Certainly not for something of so little gain to my
customers.
Well I can also do a solution which uses KEY's submitted via DHCP and
works over UDP.
TCP happens to work well for SLAAC in the home but it is conceptually
trivial to send KEY rdata via DHCP and have the DHCP server add the
record so that the DNS update can be done over UDP for those using
DHCP. Yes, I have written a draft on how to do this with PD but
similar logic works for a single address.
DHCP servers already do dynamic updates of reverse zones so this
is just adding a different record compared to the PTR record they
currently do. I would expect it would take about a day to add the
logic to do this once a code point for the DHCP option is assigned.
Nameservers already support updating of records based on self
referential KEY records for the name alone or the name and subzone
beneath it. We have shipped one which does this for over a decade
now.
update-policy {
grant dhcp-server-key subzone * ANY;
grant * self * PTR KEY; // explict list of type updatable
// grant * self * ANY; // all types except NSEC and NSEC3
// grant * self *; // all types except RRSIG, NS, SOA,
// NSEC and NSEC3
// grant * selfsub *; // Allow the key name and anything
// under it.
};
The KEY record is in the zone so it is already trusted. This doesn't
require the zone to be signed.
The rest of the cleanup logic still works.
One could simulate this today with just named and nsupdate.
Simulate DHCP server add/update of KEY record (I'm using in-addr.arpa
because it is easier to type).
nsupdate -k Kdhcp-server-key
update add 4.3.2.1.in-addr.arpa 3600 IN KEY ...
send
Simulate node update
nsupdate -k K4.3.2.1.in-addr.arpa
update add
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
At Sat, 01 Nov 2014 16:31:07 -0700, Paul Vixie p...@redbarn.org wrote: 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. [...] I guess https://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 (also in the references section of draft-howard-dnsop-ip6rdns-00, but doesn't seem to be actually referenced from the draft body) tried to become this kind of RFC (ignoring subtle implication differences). Unfortunately the draft was dead in a lot of controversy, and I think we're seeing the same type of varied opinions on this thread. I personally think if we can agree on the content this time, such a document will be very useful, but we should carefully learn from the previous failure so we won't repeat it. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Wed, Nov 05, 2014 at 10:19:59AM -0800, 神明達哉 wrote: I guess https://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 personally think if we can agree on the content this time, such a document will be very useful, but we should carefully learn from the previous failure so we won't repeat it. I'd be willing to try again if people really think it's worth doing, but the discussion just in this thread suggests to me that the result would be the same. For those who managed to miss the last round of this, that document ended up saying, There is a reverse tree; some people maintain it and some don't. Some people like to rely on it, but it is important to be aware that not everyone maintains it. If someone relies on the reverse tree and you don't maintain it for your site, you might have surprising results. At the time, I believed I had watered down the draft so thoroughly that it would be impossible for anyone to disagree with it. I was evidently wrong. If we're going to bring that thing back up (in any sense you like), then I think it needs to get a spine. Perhaps also my willingness to try to find consensus has declined in the intervening years: I just don't think there _is_ a consensus on this. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Andrew Sullivan mailto:a...@anvilwalrusden.com Wednesday, November 05, 2014 10:50 AM On Wed, Nov 05, 2014 at 10:19:59AM -0800, 神明達哉 wrote: https://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 ... ... I believed I had watered down the draft so thoroughly that it would be impossible for anyone to disagree with it. I was evidently wrong. If we're going to bring that thing back up (in any sense you like), then I think it needs to get a spine. Perhaps also my willingness to try to find consensus has declined in the intervening years: I just don't think there _is_ a consensus on this. the lack of consensus means it can't be a proposed standard, not that it can't be an FYI, BCP or similar, right? the fact of the network is, without a PTR you will have a hard time originating TCP/25. we should say that. another fact is, not everyone who should be able to (non-maliciously) access your web service will have a PTR. we should say that, too. those aren't opinions and they shouldn't be controversial. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Wed, Nov 05, 2014 at 12:50:42PM -0800, Paul Vixie wrote: the lack of consensus means it can't be a proposed standard, not that it can't be an FYI, BCP or similar, right? AFAIK we were planning only for informational. The chairs called WGLC, it ran, there was some ranting, then some months later one of the chairs told me that they weren't sure what to do. To publish something as a WG document, you still need consensus to get it out of the group. the fact of the network is, without a PTR you will have a hard time originating TCP/25. we should say that. You'd think. Here's the fully-watered text on that topic that the WG still couldn't agree to: Some anti-spam systems use the reverse tree to verify existing reverse mapping, or to check for matching reverse mapping. Some mail servers have the ability to perform such checks at the time of negotiation, and to reject mail from hosts that do not have matching reverse mappings for their hostnames. These PTR checks sometimes include databases of well-known conventions for generic names (for example, PTR records for dynamically-assigned hostnames and IP addresses), and may allow complicated rules for quarantining or filtering mail from unknown or suspect sources. Even some very large ISPs are reported to refuse mail from hosts without a reverse mapping. Often, the reverse map check is not used on its own, but is used as part of a scoring system in an attempt to indicate the probability that a given email message is spam. another fact is, not everyone who should be able to (non-maliciously) access your web service will have a PTR. we should say that, too. Again, fully watered-down: Especially in the absence of strong anti-spoofing mechanisms, like the DNS Security Extensions, a check for matching reverse DNS mapping should be regarded as an extremely weak form of authentication. […] Reverse mapping tests can give the administrator a false sense of security. There is little evidence that a reverse mapping test provides much in the way of security (see above), and may make troubleshooting in the case of DNS failure more difficult. […] Applications should not rely on reverse mapping for proper operation, although functions that depend on reverse mapping will obviously not work in its absence. Operators and users are reminded that the use of the reverse tree, sometimes in conjunction with a lookup of the name resulting from the PTR record, provides no real security, can lead to erroneous results and generally just increases load on DNS servers. Further, in cases where address block holders fail to properly configure reverse mapping, users of those blocks are penalized. Re-reading it today, it seems to me the text was altogether milquetoast. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Or we could stop debating whether we should maintain it and assume that if we give people tools that will allow it to be automatically maintained they will eventually deploy them. A lot of the issue is that the tools aren't out there yet. Document what a node should do to register itself in the reverse tree and to cleanup when its address changes. Write some code to do it. e.g. Add a PTR record and a KEY record using TCP and the source address as the authenticator. The KEY record lets the node cleanup after itself when the address changes by using SIG(0) as the authenticator. We already have nameservers which can completely support these clients. We can add delayed automatic cleanup to the DNS. Nameservers already do lots of automatic zone maintainance for DNSSEC. Cleaning out records when a timer goes off is no more difficult than regenerating RRSIG when timers go off. Yes, this would require nodes to refresh their REMOVE records periodically to keep the PTR and KEY records alive. Windows already does this sort of thing but on a whole of zone basis. 1.1.1.1.in-addr.arpa REMOVE PTR time 1.1.1.1.in-addr.arpa REMOVE KEY time Where time is a 32 bit time stamp like those in RRSIG records. The client would fetch the REMOVE records and send back a updated set of REMOVE records periodicaly. When a REMOVE record is triggered it is automatically removed from the set of REMOVE records. A nameserver could automaticall add REMOVE records and put upper bounds on the time field as a matter of policy if desired. You would then end up with a set of records like this optionally signed. 1.1.1.1.in-addr.arpa PTR name 1.1.1.1.in-addr.arpa KEY key 1.1.1.1.in-addr.arpa REMOVE PTR time 1.1.1.1.in-addr.arpa REMOVE KEY time The nameserver then has all the data it needs to re-establish the timers on startup within the zone. The next step is automatic reverse tree delegation along with prefix delegation as well as cleanup with the delegation expires. We have drafts for how to do this. -- 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] Draft Reverse DNS in IPv6 for Internet Service Providers
On Nov 5, 2014, at 3:59 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: AFAIK we were planning only for informational. The chairs called WGLC, it ran, there was some ranting, then some months later one of the chairs told me that they weren't sure what to do. To publish something as a WG document, you still need consensus to get it out of the group. Consensus in a case like this would mean is there something in the document that is not correct, not does everybody think we should publish the document. It is up to the chairs to determine consensus, and I think Pete's document (informative though it may be) on consensus is a perfectly valid guide for the chairs to follow in making that determination. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Re-reading it today, it seems to me the text was altogether milquetoast. I agree. The points that Vixie notes are entirely true, and it's hard to imagine a good reason not to document them for the benefit of people who want to, you know, interoperate. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
marka Or we could stop debating whether we should maintain it and marka assume that if we give people tools that will allow it to be marka automatically maintained they will eventually deploy them. For providers with millions or tens of millions of end customers, any system that just lets any customer scribble in DNS is unlikely to be employed for security or stability reasons. marka Document what a node should do to register itself in the reverse marka tree and to cleanup when its address changes. Write some code to marka do it. And of course all CPE vendors put out quality products with these advances in code and never put out cheap crap. And consumers always upgrade their CPEs based on this improved code immmediately. Heh. The reality is that this will take decades and in the meantime, consumers will have problems doing what they want and they will complain to their service provider, who won't have a good solution. This document tries to lay out the challenges and tradeoffs of not having PTRs or not having clean PTRs. We should be sure it makes those tradeoffs clear, along with the problems service providers will see if they do or don't pick one of the solution sets. If there are issues or tradeoffs not in the document, suggest a text change. The just do it right and folks will roll it out argument doesn't solve the problem in any useful timeframe and doesn't let folks who do have to support millions of customers make informed operational decisions. And automating at the scale we'll see with real IPv6 deployment is going to be very hard. Add in that embedded devices are some of the least likely to be current, clean or remotely upgradeable as we learn of mistakes and you'll wind up with more boxes doing it wrong than right. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
marka Or we could stop debating whether we should maintain it and marka assume that if we give people tools that will allow it to be marka automatically maintained they will eventually deploy them. [...] marka Document what a node should do to register itself in the reverse marka tree and to cleanup when its address changes. Write some code to marka do it. To put things another way, I think you're trying to optimize for a problem most folks don't want solved. Anti-spam folks *like* it that it's not trivial to get correct rDNS/PTRs. It's easy to find consumer connections based on the ISP doing bulk/lazy PTR generation and just reject SMTP traffic from them. Large ISPs don't care about clean PTRs as long as no customers complain and they don't care if end customers can't do SMTP without having to ask for it in some special way. They do care about and probably don't want complicated automated systems with all sorts of complicated behavior when autogen'ed PTRs solve most customer problems. While I as an individual may find it annoying to have to go to a web page to get a port 25 block removed and I may have to find someone better connected than me to get my email to real folks like google, I'm not most of the internet. Not even a teeny weeny fraction of it. And while I admit that I tend to disable auto-update on most of my devices and do updates by hand, at $DAYJOB, it's a feature when we can push new versions out to fix things and not wait for consumer gear to spout smoke and get replaced in 3-5 years. So for a large chunk of the providers out there, the recommendations in this draft solve a real problem in a mostly non-painful way and I think it's done a decent job of laying out the tradeoffs. There have been some comments about making it clear that providers that do bulk $GENERATE equivs in IPv6 will find that those addrs won't be able to send email. Seems like a fine thing to point out. What else in the way of tradeoffs is missing? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Thu, Nov 06, 2014 at 08:00:20AM +1100, Mark Andrews wrote: Or we could stop debating whether we should maintain it and assume that if we give people tools that will allow it to be automatically maintained they will eventually deploy them. Yeah, that's worked so far! No reason it shouldn't in this case! A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
In message 20141105231214.gk31...@mx1.yitter.info, Andrew Sullivan writes: On Thu, Nov 06, 2014 at 08:00:20AM +1100, Mark Andrews wrote: Or we could stop debating whether we should maintain it and assume that if we give people tools that will allow it to be automatically maintained they will eventually deploy them. Yeah, that's worked so far! No reason it shouldn't in this case! It requires the Chairs to actually act as chairs on this issue. A -- Andrew Sullivan a...@anvilwalrusden.com ___ 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] Draft Reverse DNS in IPv6 for Internet Service Providers
In message 20141105215548.27d51a91...@fafnir.remote.dragon.net, Paul Ebersman
writes:
marka Or we could stop debating whether we should maintain it and
marka assume that if we give people tools that will allow it to be
marka automatically maintained they will eventually deploy them.
For providers with millions or tens of millions of end customers, any
system that just lets any customer scribble in DNS is unlikely to be
employed for security or stability reasons.
For in-addr.arpa you already have a PTR records. Allowing the end
user to set its content does not increase the amount of data you
are serving. It does increase the amount of churn in the zone. A
matching TCP source address is a good enough authenticator to permit
the update. If you want to force a single PTR record that is
implementable policy.
1.2.3.4 can only set the PTR record at 4.3.2.1.in-addr.arpa.
update-policy {
permit * tcp-self * PTR;
};
to do singletons something like would work
update-policy {
permit * tcp-self-singleton * PTR;
};
I don't see a real security issue here.
The occasional customer will add a offensive PTR record which won't
be seen by 99.9% of the world. It will occasionally be included
in logs. The contents can already be checked to ensure that it is
a legal hostname (LDH) that is being added. We see this sort of
thing in whois but it doesn't stop the host names being registered
there and there is no real reason to stop them here.
If we recommend that this is only done when a forward record is
also successfully added UPDATE + TSIG (yes, this does scale for
this use) you get rid of the PTR/A mis-match issues.
For ip6.arpa you delegate to the customer along with the prefix
delegation. The customer has to deal with the space issues but
uses the same mechanisms to add the PTR records and cleanup.
marka Document what a node should do to register itself in the reverse
marka tree and to cleanup when its address changes. Write some code to
marka do it.
And of course all CPE vendors put out quality products with these
advances in code and never put out cheap crap. And consumers always
upgrade their CPEs based on this improved code immmediately.
So you implement the rest of the proposal to self clean and restore
defaults. Delayed additions are no harder than delayed removals. Yes
there are 3 records instead of one but no human needs to any
maintainence of the zone content.
REMOVE PTR time
ADD PTR time default value
You get the equivalent of $GENERATE with customer settable overrides
using UPDATE over TCP.
This is incrementally deployable.
add-remove delay PTR;
add-remove delay KEY;
add-add delay PTR dynamic-%1.%2.%3.%4.example.net;
update-policy {
permit * tcp-self-singleton * PTR KEY;
};
Or if you don't like the ADD record.
add-remove delay PTR;
add-remove delay KEY;
ptr-default dynamic-%1.%2.%3.%4.example.net;
update-policy {
permit * tcp-self-singleton * PTR KEY;
};
Technically this is 100% achievable. It adds a couple of new record
types. It requires nameservers to do the processing specified in
the new records as it falls due.
If you don't have PTR records by default you don't restore them on
deletion.
It can work with zones that synthesize missing PTR records on demand.
If there is no PTR record in the zone, create one.
Heh.
The reality is that this will take decades and in the meantime,
consumers will have problems doing what they want and they will complain
to their service provider, who won't have a good solution.
The reality is that this will give what is needed and is incrementally
deployable. The only question is do you synthesize missing PTR
records and matching records or not for IPv6.
Mark
This document tries to lay out the challenges and tradeoffs of not
having PTRs or not having clean PTRs. We should be sure it makes those
tradeoffs clear, along with the problems service providers will see if
they do or don't pick one of the solution sets. If there are issues or
tradeoffs not in the document, suggest a text change.
The just do it right and folks will roll it out argument doesn't solve
the problem in any useful timeframe and doesn't let folks who do have to
support millions of customers make informed operational decisions.
And automating at the scale we'll see with real IPv6 deployment is going
to be very hard. Add in that embedded devices are some of the least
likely to be current, clean or remotely upgradeable as we learn of
mistakes and you'll wind up with more boxes doing it wrong than right.
--
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
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
In message 20141105222034.5fe40a92...@fafnir.remote.dragon.net, Paul Ebersman writes: marka Or we could stop debating whether we should maintain it and marka assume that if we give people tools that will allow it to be marka automatically maintained they will eventually deploy them. [...] marka Document what a node should do to register itself in the reverse marka tree and to cleanup when its address changes. Write some code to marka do it. To put things another way, I think you're trying to optimize for a problem most folks don't want solved. You don't know that. At the moment most people that would want these records have give up because the barriers raised have been to hard mostly because it requires a human to be in the loop and there is no standarisation. Anti-spam folks *like* it that it's not trivial to get correct rDNS/PTRs. It's easy to find consumer connections based on the ISP doing bulk/lazy PTR generation and just reject SMTP traffic from them. Which won't work in IPv6 unless you syntesize the records on demand. They also have other databases so don't really need PTR records to workout static vs dynamic. Large ISPs don't care about clean PTRs as long as no customers complain and they don't care if end customers can't do SMTP without having to ask for it in some special way. They do care about and probably don't want complicated automated systems with all sorts of complicated behavior when autogen'ed PTRs solve most customer problems. Except autogenerated PTR records don't solve the problem. While I as an individual may find it annoying to have to go to a web page to get a port 25 block removed and I may have to find someone better connected than me to get my email to real folks like google, I'm not most of the internet. Not even a teeny weeny fraction of it. Getting a firewall block removed is a othogonal issue. And while I admit that I tend to disable auto-update on most of my devices and do updates by hand, at $DAYJOB, it's a feature when we can push new versions out to fix things and not wait for consumer gear to spout smoke and get replaced in 3-5 years. So for a large chunk of the providers out there, the recommendations in this draft solve a real problem in a mostly non-painful way and I think it's done a decent job of laying out the tradeoffs. There have been some comments about making it clear that providers that do bulk $GENERATE equivs in IPv6 will find that those addrs won't be able to send email. Seems like a fine thing to point out. What else in the way of tradeoffs is missing? That people want IP to name mappings for their internal networks. With things like DNSSEC you need break DNSSEC trust chains at the ISP level for this to work. We also don't know what else will come along to use the reverse namespace. It is a good place to hang keying material which is tied to IP address. Having a well defined method to update this name space will be useful. There is a opportunity cost in not having the ability to do this already deployed. Remember it is just as easy to add a delegation as it is a PTR record if the amount of material that needs to be stored gets too big. 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] Draft Reverse DNS in IPv6 for Internet Service Providers
marka Or we could stop debating whether we should maintain it and marka assume that if we give people tools that will allow it to be marka automatically maintained they will eventually deploy them. For providers with millions or tens of millions of end customers, any system that just lets any customer scribble in DNS is unlikely to be employed for security or stability reasons. For in-addr.arpa you already have a PTR records. Allowing the end user to set its content does not increase the amount of data you are serving. It does increase the amount of churn in the zone. Putting my ISP hat on, I'd have to agree with the security/stability reasons (and several others I can think of). As of today, I have zero incentive to let my residential customers create their own PTR records. Better tools and systems may change this, but it would in any case be *way* down on the priority list. Steinar Haug, AS 2116 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Hi George, and all. I've just caught up on this thread, and it strikes me that there is (it seems) an operational gap with the omission of the problem statement. On 3/11/2014 2:36 pm, George Michaelson g...@algebras.org wrote: [snip] We don't have any failure to delegate the parent blocks facing down: Its people's willingness to invest energy on the various different approaches to the sub-delegation engines inside your own block management, be it embedded in the NMS or some kind of customer facing provisioning web portal or whatever. Problem 1: Operator unwillingness to invest energy to the sub-delegation engines [snip] Personally, and it is only my personal view, I like some of the older ideas for semi-machine generated and wildcarded reverse I saw presented at the RIPE ROME meeting. And I see some value in sign-on-the-fly work. Problem 2: uniform generation of PTR (with the presumption that they are useful in some form) I think rDNS remains potential for big value. I can't verbalize it well, but it has qualities about trust which for me could be useful. Its volountarist nature is a huge counter argument as you've all exposed here: can't depend on it. coverage is low. Problem 3: The non-specific non-commital approach (or lack thereof) to coverage by operators. Problem 4: The inability to document 'big value' or trust qualities in reverse DNS. I see the use of reverse DNS as various forms of blacklisting/whitelisting or similarly adjudicating the reputation of a TCP connection (SMTP or otherwise) an interesting approach to remove a level of pain (where pain levels are individually variable). I don't necessarily believe this evolution has legs, but I don't believe they are very long. Suffice to say that I've used that as a pain fix in past, but now question its scale going forward for IPv6. I don't mind the concept of stable services addresses having stable and well formed reverse. However in a customer realm, see Problem 1 closely followed by problem 3. As to utility? I've stopped looking at reverse DNS, as a quality, and as an information source. Really, if I want to get a sense of who and where I tend to look toward whois/rdap and a sh ip bgp blah and look to the ASN. So as a sales job trying to sell reverse DNS IPv6 to the masses, and that isn't the IETF's job IMHO, we won't be living well on the commission. As to the IETF's job of documenting the problem, and then a possible solution for the operational aspects - I think that worth putting cycles toward, however I don't see that it will be at all easy. If this thread is any indication. Cheers Terry smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
I think thats pretty well completely fair Terry. I think you capture the qualities well. But if you put DNSSEC back in the equation, add sufficient value to the assertive-trust side of what would be said inside it, and the follows-the-delegation-chain aspect, I think it has potential to have more value. But only potential. Its very very latent. -G On Tue, Nov 4, 2014 at 12:32 AM, Terry Manderson terry.mander...@icann.org wrote: Hi George, and all. I've just caught up on this thread, and it strikes me that there is (it seems) an operational gap with the omission of the problem statement. On 3/11/2014 2:36 pm, George Michaelson g...@algebras.org wrote: [snip] We don't have any failure to delegate the parent blocks facing down: Its people's willingness to invest energy on the various different approaches to the sub-delegation engines inside your own block management, be it embedded in the NMS or some kind of customer facing provisioning web portal or whatever. Problem 1: Operator unwillingness to invest energy to the sub-delegation engines [snip] Personally, and it is only my personal view, I like some of the older ideas for semi-machine generated and wildcarded reverse I saw presented at the RIPE ROME meeting. And I see some value in sign-on-the-fly work. Problem 2: uniform generation of PTR (with the presumption that they are useful in some form) I think rDNS remains potential for big value. I can't verbalize it well, but it has qualities about trust which for me could be useful. Its volountarist nature is a huge counter argument as you've all exposed here: can't depend on it. coverage is low. Problem 3: The non-specific non-commital approach (or lack thereof) to coverage by operators. Problem 4: The inability to document 'big value' or trust qualities in reverse DNS. I see the use of reverse DNS as various forms of blacklisting/whitelisting or similarly adjudicating the reputation of a TCP connection (SMTP or otherwise) an interesting approach to remove a level of pain (where pain levels are individually variable). I don't necessarily believe this evolution has legs, but I don't believe they are very long. Suffice to say that I've used that as a pain fix in past, but now question its scale going forward for IPv6. I don't mind the concept of stable services addresses having stable and well formed reverse. However in a customer realm, see Problem 1 closely followed by problem 3. As to utility? I've stopped looking at reverse DNS, as a quality, and as an information source. Really, if I want to get a sense of who and where I tend to look toward whois/rdap and a sh ip bgp blah and look to the ASN. So as a sales job trying to sell reverse DNS IPv6 to the masses, and that isn't the IETF's job IMHO, we won't be living well on the commission. As to the IETF's job of documenting the problem, and then a possible solution for the operational aspects - I think that worth putting cycles toward, however I don't see that it will be at all easy. If this thread is any indication. Cheers Terry ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
but, separately from that, if PTR's have high and low uses, we should document that, so that NYT (or whomever) ... Can whoever mentioned the NY Times offer more clues about what they're rejecting? My cable connection happens to have IPv6 with no rDNS, and I can't even find a v6 address at the Times to try to connect to. As far as I can tell, they're all v4. I certainly get my share of v6 connection strangeness, but all of the ones I've been able to track down appear due to T-W's sometimes dodgy internal routing. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
ebersman I don't even know how many broken sites there are and I don't ebersman care to waste valuable staff time tilting at this ebersman windmill. ... vixie no worries. meanwhile i'm going to try to build an internet that vixie can grow for 200 more years. Suddenly being socially responsible with PTR use is going to save the internet. Cool. :) vixie that's not going to happen if all we ever do is add layers and vixie complexity. if PTR's are silly, then we have a responsibility to vixie say so in writing, with an RFC number to point at, and we should vixie begin what may be the several-lifetimes-long task of getting vixie people to pay attention differently. i have little or no use for vixie the world as it is, and i never have had. If you do really want to try to cure 20+ years of bad ideas and document it, go for it. I'd speak against doing so in this draft, other than a possible reference if said RFC ever happens. One of the big problems with the whole v6 PTR discussion is that every time somone (including me) has asked so how are we using them in v4, noone has anything like a definitive list of what we're doing now. That doesn't even touch whether or not said uses are actually good ideas. I think there is value in making recommendations now based on current operational reality and detailing tradeoffs and real customer support costs in doing PTRs in v6, which seems to be the goal of this draft. If this turns into an RFC and eventually becomes a quaint bit of history, we can retire it. ebersman Folks trying limit spam will hopefully figure out something ebersman that doesn't involve reputation by IPv6 addr, 'cause at 18 ebersman quadrillion per /64, that won't scale... vixie ain't it great? a lot of servers are going to demand PTR's for vixie V6. this will force the number of SMTP senders to be small. i vixie don't love the mechanism, but i can't quibble with the social vixie impact. So your grand scheme is to limit who can get v6 PTRs and that will be the new standard of whether or now you're tall enough to send email with the big boys? How's that worked out so far in v4 in the last few years? How about we admit that PTRs as a measure of trust and reputation is broken to begin with and won't scale or magically work better for v6 than v4? Let's come up with a better solution(s). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
ebersman So your grand scheme is vixie decorum? No objections here if you succeed. :) ebersman ... to limit who can get v6 PTRs and that will be the new ebersman standard of whether or now you're tall enough to send email ebersman with the big boys? vixie yes. Well, for my $DAYJOB, that's certainly something we support. As someone who runs my own mail server and knows other small businesses who do as well, I'm still hoping we can come up with a better system that lets some of the smaller players in too. ebersman How about we admit that PTRs as a measure of trust and ebersman reputation is broken to begin with and won't scale or ebersman magically work better for v6 than v4? Let's come up with a ebersman better solution(s). vixie i think we're on the same page, actually. where we're still far vixie apart is in our understandings of how things work today, in other vixie words, what status quo are we living with; and also, whether and vixie in what direction we can change it. I'm happy to be educated or corrected by hard facts. And I agree we probably ultimately want the same thing: email that is more signal than noise to mail servers. Getting back to this draft, I think there is enough value in enumerating the challenges and tradeoffs of doing some kind of v6 PTRs to try to get the draft out soon. Plenty of folks (including $DAYJOB) want something short term that doesn't break anything and looks/smells somewhat like what we already have in v4. No argument that a better solution here long term would be welcome too; I just don't want folks to have another excuse not to roll out v6 now. As for a grander scheme to clean up the PTR space, do you agree that breaking that out into a separate draft is more productive? It does seem to make sense to mention that folks doing the $GENERATE equiv will get the same short shrift from the anti-spam folks that the v4 PTRs get currently. Any other comments/additions to this draft? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
knowing its not the root issue, I would like to remind people the RIR system for rDNS delegation is almost entirely automatic from our various portals, and WHOIS based nserver mechanisms. Its not hard to do the top part. We're not roadblocking. We don't have any failure to delegate the parent blocks facing down: Its people's willingness to invest energy on the various different approaches to the sub-delegation engines inside your own block management, be it embedded in the NMS or some kind of customer facing provisioning web portal or whatever. What we don't do, (noting 6to4 reverse as a very specific counter-case) is permit 'hop over' in the delegation chain because its got issues regarding 'who said you could do that' we don't want to prod. The delegation sequence really has to be top down if you have sub-delegation state. Personally, and it is only my personal view, I like some of the older ideas for semi-machine generated and wildcarded reverse I saw presented at the RIPE ROME meeting. And I see some value in sign-on-the-fly work. I think rDNS remains potential for big value. I can't verbalize it well, but it has qualities about trust which for me could be useful. Its volountarist nature is a huge counter argument as you've all exposed here: can't depend on it. coverage is low. -G On Sun, Nov 2, 2014 at 7:20 PM, Paul Ebersman list-dn...@dragon.net wrote: ebersman So your grand scheme is vixie decorum? No objections here if you succeed. :) ebersman ... to limit who can get v6 PTRs and that will be the new ebersman standard of whether or now you're tall enough to send email ebersman with the big boys? vixie yes. Well, for my $DAYJOB, that's certainly something we support. As someone who runs my own mail server and knows other small businesses who do as well, I'm still hoping we can come up with a better system that lets some of the smaller players in too. ebersman How about we admit that PTRs as a measure of trust and ebersman reputation is broken to begin with and won't scale or ebersman magically work better for v6 than v4? Let's come up with a ebersman better solution(s). vixie i think we're on the same page, actually. where we're still far vixie apart is in our understandings of how things work today, in other vixie words, what status quo are we living with; and also, whether and vixie in what direction we can change it. I'm happy to be educated or corrected by hard facts. And I agree we probably ultimately want the same thing: email that is more signal than noise to mail servers. Getting back to this draft, I think there is enough value in enumerating the challenges and tradeoffs of doing some kind of v6 PTRs to try to get the draft out soon. Plenty of folks (including $DAYJOB) want something short term that doesn't break anything and looks/smells somewhat like what we already have in v4. No argument that a better solution here long term would be welcome too; I just don't want folks to have another excuse not to roll out v6 now. As for a grander scheme to clean up the PTR space, do you agree that breaking that out into a separate draft is more productive? It does seem to make sense to mention that folks doing the $GENERATE equiv will get the same short shrift from the anti-spam folks that the v4 PTRs get currently. Any other comments/additions to this draft? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft 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] 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] Draft Reverse DNS in IPv6 for Internet Service Providers
On Fri, Oct 31, 2014 at 1:28 AM, Paul Vixie p...@redbarn.org wrote: ... i suggest an efficiency improvement: don't manufacture these PTR's in the first place. let last-mile devices be PTR-free. signal to anti-spam folks, such as myself, by this method, that these are not real hosts and should not be participating in what were once considered end-to-end protocols, such as off-network SMTP. ... -- Paul Vixie I recall running into applications that refused to accept connections (or took a very long time) if the reverse DNS lookup was not found. If memory serves, telnet and ssh on some hosts. Do we know if there are still applications like that? If so, then we (home users) need the reverse PTR. -- Bob Harold (Speaking personally, not for my employer) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Bob Harold wrote: I recall running into applications that refused to accept connections (or took a very long time) if the reverse DNS lookup was not found. If memory serves, telnet and ssh on some hosts. Do we know if there are still applications like that? Ubuntu has a long-standing bug that causes a 5-second delay in any reverse lookup that yields NXDOMAIN: https://bugs.launchpad.net/ubuntu/+source/nss-mdns/+bug/94940 If so, then we (home users) need the reverse PTR. Personally, I would prefer to see Ubuntu, and any other software broken in similar ways, fixed. -- Andreas Gustafsson, g...@araneus.fi ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Not sure why Paul Vixie wants to relegate my IPv6 address to third class citizen that's not good enough to be a peer on the Internet for port 25. I'd ask him, but his mail server refuses my email due to my ISPs lack of reverse IPv6 :p I'm all for anti-spam heuristics, but checking the reverse is simply a method that's causing too many false positives, on top of punishing early adopters of IPv6 Sent from my iPhone On Oct 31, 2014, at 01:28, Paul Vixie p...@redbarn.org wrote: compose-unknown-contact.jpgDoug Barton Thursday, October 30, 2014 9:00 PM Of course not, but it is one that the ISP makes, and that distinction is useful to the anti-spam folks. IETF should not be making judgements as to what an ISP will value, because not all ISP's behave as you described. also, it's useless to the anti-spam folks. right now the massively faked and manufactured PTR RR's coming from almost all last-mile providers for about half of all the IPv4 address space that's reachable, has to be laboriously cataloged so that it can be ignored. that is, the lack of a PTR suggests that a device ought not be initiating TCP/25 outside its local network. (this is an observation of how the anti-spam folks, including myself, behave; it is not a recommendation.) knowing this, last-mile providers foolishly and bizarrely create hundreds of millions of PTR RR's that have no value whatsoever since they simply encode the IP address in ASCII and add the ISP's .foo.net suffix. knowing this, the anti-spam folks make lists of these manufactured patterns so that (and ONLY so that) they can pretend they do not exist. i suggest an efficiency improvement: don't manufacture these PTR's in the first place. let last-mile devices be PTR-free. signal to anti-spam folks, such as myself, by this method, that these are not real hosts and should not be participating in what were once considered end-to-end protocols, such as off-network SMTP. internet service != internet access. can we make that taxonomy explicit, and stop equivocating? Oct 31 00:59:29 ss postfix/postscreen[3912]: NOQUEUE: reject: RCPT from [59.55.248.215]:2294: 550 5.7.1 Service unavailable; client [59.55.248.215] blocked using b.barracudacentral.org; from=sabrina.g...@yahoo.com, to=wsksc...@mibh.com, proto=ESMTP, helo=yahoo.com 215.248.55.59.in-addr.arpa. 69668 INPTR 215.248.55.59.broad.ja.jx.dynamic.163data.com.cn. ;; Received 106 bytes from 202.101.226.68#53(ns.jxjjptt.net.cn) in 162 ms -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Not sure why Paul Vixie wants to relegate my IPv6 address to third class citizen that's not good enough to be a peer on the Internet for port 25. I'd ask him, but his mail server refuses my email due to my ISPs lack of reverse IPv6 :p I'm all for anti-spam heuristics, but checking the reverse is simply a method that's causing too many false positives, on top of punishing early adopters of IPv6 I'd suggest that mild inconvenience for you is not a synonym for too many false positives. I've been running IPv6 on my server for quite a while via a tunnel from HE, which includes the ability to manage my own reverse DNS. (Thanks!) When I look at the logs, I see precious few inbound connections with no rDNS that plausibly could be anything other than a spambot or yet another compromised web host. Every mail system in the world is reachable via IPv4 and will be for a long time. If your v6 setup isn't ready for prime time, it really isn't anyone else's job to help you experiment. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Bob Harold mailto:rharo...@umich.edu Friday, October 31, 2014 6:02 AM ... I recall running into applications that refused to accept connections (or took a very long time) if the reverse DNS lookup was not found. If memory serves, telnet and ssh on some hosts. Do we know if there are still applications like that? If so, then we (home users) need the reverse PTR. i do not know one way or the other. but if there are such apps, they are wrongheaded, and, the only way to get them fixed is, stop placating them. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Fri, 31 Oct 2014, Paul Vixie wrote: if you have a business grade connection to the internet, you should be able to establish a PTR for each real host. Oh, you want me to pay an additional $2000/month to use IPv6 with email. in other words i didn't relegate your address to third party status. that bed was on fire when you laid down on it. So much priviledge, wow, very Postel :P John Levin wrote: If your v6 setup isn't ready for prime time, it really isn't anyone else's job to help you experiment Attitudes like this at least guarantees we keep drinking scotch. But universal deployment of ipv6, not so much. In the fight between being forcibly NAT'ed behind IPv4, or having IPv6 without a reverse, it would be really nice to try and make everyone a full peer on the internet again using IPv6 :P I guess soon only criminals with have IPv6 reverse, since they have more budget to spend on this than I do :P 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
Paul Wouters mailto:p...@nohats.ca Friday, October 31, 2014 9:29 AM On Fri, 31 Oct 2014, Paul Vixie wrote: if you have a business grade connection to the internet, you should be able to establish a PTR for each real host. Oh, you want me to pay an additional $2000/month to use IPv6 with email. no, sir, and that's the second time you've attributed a desire to me that i don't possess. (putting it in the form of a question makes it no more palatable.) in other words i didn't relegate your address to third party status. that bed was on fire when you laid down on it. So much priviledge, wow, very Postel :P people who want their mail to get through relay it through servers that have PTR's. that's not news. you could: 1. pay $2000 (or whatever) for business-grade connectivity; 2. get a tunnel to sixxs or some other ipv6 tunnel broker; 3. buy a cheap virtual server in some cloud somewhere; 4. send me a 1U which i can host on my comcast business connection; 5. accept a free bhyve VM running freebsd on my personal cloud. note, #4 and #5 are only available to people i have drank beer with, so, mr. wouters certainly qualifies. if you want an option that's not on the menu, it's your job to define it, and probably build it. if your preferred solution is that everyone accepting e-mail stop looking for PTR's, then The Princess Bride has this wisdom for you: Inigo Montoya: Who are you? Man in Black: No one of consequence. Inigo Montoya: I must know... Man in Black: Get used to disappointment. Inigo Montoya: 'kay. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message 5453adcd.7090...@redbarn.org, Paul Vixie p...@redbarn.org writes and yet, every proposal i've seen concerning IPv6 PTR screams silently, PTR is an old-internet concept which no longer applies. it's as if we were trying to placate a bunch of apps that didn't understand classless inter-domain routing (CIDR) with its variable length prefixes, and rather than fix the apps, we're synthesizing acceptable metadata for them, at great complexity cost, and zero information benefit. 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. 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 What recipients really wish to know when they receive a connection is how much address space is controlled by the connecting entity so that a consistent reputation can be applied to all connections from that space. Whether they construct that reputation themselves or acquire it from a broker is not relevant -- they want to apply it to all addresses that a sender controls. We approximate this in IPv4 by using /32s (since few people control more than a /24 -- so we get within a factor of 250 -- and there are not all that many /18s and above ... so we can manually inspect the traffic from each one on its merits, and yes there's a gap there). We just can't use the same approximations for IPv6, but the reverse DNS system is one place where we could store attestations about delegation of address space ... ... if we don't build such a system where this information can be stored for anyone to access for free then we're all going to end up paying another set of brokers for the data needed to provide the granularity measures our reputation systems must use - -- Dr Richard Clayton richard.clay...@cl.cam.ac.uk tel: 01223 763570, mobile: 07887 794090 Computer Laboratory, University of Cambridge, CB3 0FD -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBVFPLKuINNVchEYfiEQIjbgCbBQSyfmInlRaW8X497OyNAKytMGIAn1Js 63oOrwA48IfcFtAuTBpwupMV =awU9 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
In message 16VeoWCqs8UUFA$s...@highwayman.com, Richard Clayton writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message 5453adcd.7090...@redbarn.org, Paul Vixie p...@redbarn.org writes and yet, every proposal i've seen concerning IPv6 PTR screams silently, PTR is an old-internet concept which no longer applies. it's as if we were trying to placate a bunch of apps that didn't understand classless inter-domain routing (CIDR) with its variable length prefixes, and rather than fix the apps, we're synthesizing acceptable metadata for them, at great complexity cost, and zero information benefit. 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. 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 If you don't look it up it doesn't cost anything to cache. Additionally a negative response is *bigger* and is more costly to cache especially if it is a signed negative response. If you are worries about cache size you *want* PTR records to be returned. What recipients really wish to know when they receive a connection is how much address space is controlled by the connecting entity so that a consistent reputation can be applied to all connections from that space. Whether they construct that reputation themselves or acquire it from a broker is not relevant -- they want to apply it to all addresses that a sender controls. We approximate this in IPv4 by using /32s (since few people control more than a /24 -- so we get within a factor of 250 -- and there are not all that many /18s and above ... so we can manually inspect the traffic from each one on its merits, and yes there's a gap there). We just can't use the same approximations for IPv6, but the reverse DNS system is one place where we could store attestations about delegation of address space ... ... if we don't build such a system where this information can be stored for anyone to access for free then we're all going to end up paying another set of brokers for the data needed to provide the granularity measures our reputation systems must use - -- Dr Richard Clayton richard.clay...@cl.cam.ac.uk tel: 01223 763570, mobile: 07887 794090 Computer Laboratory, University of Cambridge, CB3 0FD -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBVFPLKuINNVchEYfiEQIjbgCbBQSyfmInlRaW8X497OyNAKytMGIAn1Js 63oOrwA48IfcFtAuTBpwupMV =awU9 -END PGP SIGNATURE- ___ 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] Draft Reverse DNS in IPv6 for Internet Service Providers
On 10/23/14 5:17 PM, Mark Andrews ma...@isc.org wrote:
In message d06e91ee.72e46%...@asgard.org, Lee Howard writes:
From: Mwendwa Kivuva kiv...@transworldafrica.com
Date: Thursday, October 23, 2014 7:23 AM
To: dnsop dnsop@ietf.org
Subject: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service
Providers
Refering to the draft by Lee Howard
https://tools.ietf.org/html/draft-howard-dnsop-ip6rdns-00
and given the weakness of the Reverse DNS access for security
purposes, wha
t
problem is this draft trying to solve?
There is a common expectation that ISPs will populate PTR records for
their
customers.
In my opinion, that is an unreasonable expectation, since ISPs do not
have
host names for customers, so they usually make up a name. That seems
pretty
useless to me. However, I don't think that is a consensus opinion, so
it's
not what the draft says.
But it is not unreasonable to delegate a zone or to accept DNS UPDATE
requests
from the host you have just assigned a IP address to over TCP.
Not sure of the antecedent of you. If you are a DHCPv6 server, you
are not necessarily a DNS server authoritative for the ip6.arpa zone in
question and capable of accepting DNS updates. Especially if you are a
DHCPv6 server on a home router.
You (Mark Andrews, not the servers) have proposed mechanisms for
facilitating that communication; that would help.
zone ip6.arpa {
update-policy { grant * tcp-self * ptr; };
};
reverse=`arpaname ${ip_address}`
hostname=`hostname`
And residential hosts only know hostname, not domain name; is
myMacBook.local useful as a PTR? I haven't checked with users of PTRs
to see what they think.
Lee
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Lee, I don't see any discussion in your draft about why rDNS is needed in this space. IME there are typically 2 uses cases: 1. Residential users, or more specifically, those who will not be/should not be running services on their addresses 2. Commercial users, who may be running things like mails servers Obviously (and yes, I am being facetious since there is still controversy on this point in some quarters) the latter need the ability to run proper rDNS so that at minimum their mail servers can pass industry-standard (and arguably best practice) forward/reverse verification. Hopefully the solutions for that are obvious to the participants on this list. However, for users that are not running services the primary desire (that I'm aware of) is to have an easy way to flag that those are ranges that we would not expect mail to come from. The guidelines for flagging dynamic addresses in the mailop community are well known for IPv4, but I don't see any mention of that in your draft (although admittedly, I only skimmed it). So while on the one hand documenting that there are options for actually providing valid rDNS for end users probably has value (the How) I don't see enough discussion about Why? to give me a good feeling about this draft. Particularly I would like to see some discussion about why a wildcard set at a high level for your dynamic range isn't a valid solution. Doug ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
In message d0782276.73d89%...@asgard.org, Lee Howard writes:
On 10/23/14 5:17 PM, Mark Andrews ma...@isc.org wrote:
In message d06e91ee.72e46%...@asgard.org, Lee Howard writes:
From: Mwendwa Kivuva kiv...@transworldafrica.com
Date: Thursday, October 23, 2014 7:23 AM
To: dnsop dnsop@ietf.org
Subject: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service
Providers
Refering to the draft by Lee Howard
https://tools.ietf.org/html/draft-howard-dnsop-ip6rdns-00
and given the weakness of the Reverse DNS access for security
purposes, wha
t
problem is this draft trying to solve?
There is a common expectation that ISPs will populate PTR records for
their
customers.
In my opinion, that is an unreasonable expectation, since ISPs do not
have
host names for customers, so they usually make up a name. That seems
pretty
useless to me. However, I don't think that is a consensus opinion, so
it's
not what the draft says.
But it is not unreasonable to delegate a zone or to accept DNS UPDATE
requests
from the host you have just assigned a IP address to over TCP.
Not sure of the antecedent of you. If you are a DHCPv6 server, you
are not necessarily a DNS server authoritative for the ip6.arpa zone in
question and capable of accepting DNS updates. Especially if you are a
DHCPv6 server on a home router.
You (Mark Andrews, not the servers) have proposed mechanisms for
facilitating that communication; that would help.
zone ip6.arpa {
update-policy { grant * tcp-self * ptr; };
};
reverse=`arpaname ${ip_address}`
hostname=`hostname`
And residential hosts only know hostname, not domain name; is
myMacBook.local useful as a PTR? I haven't checked with users of PTRs
to see what they think.
Which is basically because home users have been treated as second
class citizen on the Internet. They couldn't get permanent addresses
as they had to be re-used just to keep the net working. This is
no longer true with IPv6.
Lots of home users do actually have registered domainnames. If you
make it simpler lots more will.
If you don't have a domain add a PTR record that points to name.itself
with a A / record which corresponds.
myMacBook.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa
is a legal hostname. You could also strip it back to the /64 or /48.
myMacBook.1.0.168.192.in-addr.arpa is a legal hostname.
1.0.168.192.in-addr.arpa PTR myMacBook.1.0.168.192.in-addr.arpa
myMacBook.1.0.168.192.in-addr.arpa A 192.168.0.1
The ISP could have a home and customers could have a name delegated
from it as part of their package. myMacBook.name.example.com
There are lots of ways to get a name.
ICANN could open up .home to residential customers.
Australia has id.au which is designed for low cost / zero cost delegations.
I have andrews.wattle.id.au for $0.
There days there really is no reason not to run servers at home.
I would bet that over 50% of households already run servers at home though
not all of these would be currently open to the world. I expect that
number to increase.
I also expect homes with registered domains to increase as the
automation in the home increases. There is something nice about
being able to tell airconditioners etc. to turn on when you leave
work so the room is a reasonable temperature.
There is something nice about being able to stream movies from your
home video system regardless of where you are in the world.
I'm sure lots of other things will come along to make use of homes having
registered domains in the future.
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] Draft Reverse DNS in IPv6 for Internet Service Providers
On Oct 30, 2014, at 6:05 PM, Doug Barton do...@dougbarton.us wrote: 1. Residential users, or more specifically, those who will not be/should not be running services on their addresses This is not a value judgment the IETF should be making. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On 10/30/14 6:02 PM, Ted Lemon wrote: On Oct 30, 2014, at 6:05 PM, Doug Barton do...@dougbarton.us wrote: 1. Residential users, or more specifically, those who will not be/should not be running services on their addresses This is not a value judgment the IETF should be making. Of course not, but it is one that the ISP makes, and that distinction is useful to the anti-spam folks. Doug ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Doug Barton mailto:do...@dougbarton.us Thursday, October 30, 2014 9:00 PM Of course not, but it is one that the ISP makes, and that distinction is useful to the anti-spam folks. IETF should not be making judgements as to what an ISP will value, because not all ISP's behave as you described. also, it's useless to the anti-spam folks. right now the massively faked and manufactured PTR RR's coming from almost all last-mile providers for about half of all the IPv4 address space that's reachable, has to be laboriously cataloged so that it can be ignored. that is, the lack of a PTR suggests that a device ought not be initiating TCP/25 outside its local network. (this is an observation of how the anti-spam folks, including myself, behave; it is not a recommendation.) knowing this, last-mile providers foolishly and bizarrely create hundreds of millions of PTR RR's that have no value whatsoever since they simply encode the IP address in ASCII and add the ISP's .foo.net suffix. knowing this, the anti-spam folks make lists of these manufactured patterns so that (and ONLY so that) they can pretend they do not exist. i suggest an efficiency improvement: don't manufacture these PTR's in the first place. let last-mile devices be PTR-free. signal to anti-spam folks, such as myself, by this method, that these are not real hosts and should not be participating in what were once considered end-to-end protocols, such as off-network SMTP. internet service != internet access. can we make that taxonomy explicit, and stop equivocating? Oct 31 00:59:29 ss postfix/postscreen[3912]: NOQUEUE: reject: RCPT from [59.55.248.215]:2294: 550 5.7.1 Service unavailable; client [59.55.248.215] blocked using b.barracudacentral.org; from=sabrina.g...@yahoo.com, to=wsksc...@mibh.com, proto=ESMTP, helo=yahoo.com 215.248.55.59.in-addr.arpa. 69668 INPTR 215.248.55.59.broad.ja.jx.dynamic.163data.com.cn. ;; Received 106 bytes from 202.101.226.68#53(ns.jxjjptt.net.cn) in 162 ms -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
P Vixie wrote: Ohta-san, like you I would like to see stateless address auto configuration for ipv6 (SLAAC) die in a fire. Sadly this outcome is beyond our powers. Not necessarily. Let's start from where we are, no matter how unpleasant that place may be. Vixie From where we are, fix broken part of the stack, not elsewhere, never. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Refering to the draft by Lee Howard https://tools.ietf.org/html/draft-howard-dnsop-ip6rdns-00 and given the weakness of the Reverse DNS access for security purposes, what problem is this draft trying to solve? If we need to find the host that has sent an email associated with an address, would we better let DKIM address that without a separate lookup in the receiving server? DKIM detects email spoofing by using digital signature allowing receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators. Is there a better way to approach the problem? __ Mwendwa Kivuva, Nairobi, Kenya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
and given the weakness of the Reverse DNS access for security purposes, what problem is this draft trying to solve? If we need to find the host that has sent an email associated with an address, would we better let DKIM address that without a separate lookup in the receiving server? DKIM detects email spoofing by using digital signature allowing receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators. Is there a better way to approach the problem? I do not claim it is a best way but I think CGA-TSIG can easily handle many similar scenarios. You can check the old version here http://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-tsig/ and upcoming version here http://editor.rozanak.com/show.aspx?u=AZCDD03D4DBABD14DA80CDTAM Hosnieh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Oct 23, 2014, at 7:23 AM, Mwendwa Kivuva kiv...@transworldafrica.com wrote: and given the weakness of the Reverse DNS access for security purposes, what problem is this draft trying to solve? If we need to find the host that has sent an email associated with an address, would we better let DKIM address that without a separate lookup in the receiving server? DKIM detects email spoofing by using digital signature allowing receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators. For me at least the main values of the reverse DNS are: - answers the question what host is contacting me in situations where I am _not_ under attack, which is really useful in logs and other debugging and network management settings. - provides place to hang information relating to a host's IP address DKIM is a solution that is applicable only to a specific protocol, so it can't address this in a general way. Like you I would like to see the end of the use of reverse lookups for security, but reverse lookups are still useful. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
From: Mwendwa Kivuva kiv...@transworldafrica.com Date: Thursday, October 23, 2014 7:23 AM To: dnsop dnsop@ietf.org Subject: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers Refering to the draft by Lee Howard https://tools.ietf.org/html/draft-howard-dnsop-ip6rdns-00 and given the weakness of the Reverse DNS access for security purposes, what problem is this draft trying to solve? There is a common expectation that ISPs will populate PTR records for their customers. In my opinion, that is an unreasonable expectation, since ISPs do not have host names for customers, so they usually make up a name. That seems pretty useless to me. However, I don't think that is a consensus opinion, so it's not what the draft says. The problem I'm trying to solve is how to do that in IPv6. I think the recommendations do represent consensus: try to get host names and reverse zone under the same authority (whether home or ISP), or have the authority inform the other. If you can't do that, making something up is better than nothing, but not strictly required. If we need to find the host that has sent an email associated with an address, would we better let DKIM address that without a separate lookup in the receiving server? DKIM detects email spoofing by using digital signature allowing receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators. Absolutely! It may be reasonable to say that all legitimate mail servers will have a PTR record that matches an A/ record; that alone is not enough to decide that a sender is safe. The only mention in the draft is this: For instance, most email providers will not accept incoming connections on port 25 unless forward and reverse DNS entries match. If they match, but information higher in the stack (for instance, mail source) is inconsistent, the packet is questionable. These records may be easily forged though, unless DNSsec or other measures are taken. The string of inferences is questionable, and may become unneeded if other means for evaluating trustworthiness (such as positive reputations) become predominant in IPv6. I didn't specifically call out DKIM as one of those other means for evaluating trustworthiness, but I could. Use of reverse DNS in email is only one use case for reverse DNS, and I agree that relying on it is, well, questionable. Lee Is there a better way to approach the problem? __ Mwendwa Kivuva, Nairobi, Kenya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Ted Lemon mailto:ted.le...@nominum.com Thursday, October 23, 2014 7:02 AM For me at least the main values of the reverse DNS are: - answers the question what host is contacting me in situations where I am _not_ under attack, which is really useful in logs and other debugging and network management settings. - provides place to hang information relating to a host's IP address DKIM is a solution that is applicable only to a specific protocol, so it can't address this in a general way. Like you I would like to see the end of the use of reverse lookups for security, but reverse lookups are still useful. william simpson was right in 1996. we should have moved get host name corresponding to IP to ICMP. the problems described by lee howard's draft are proof that our whole model is wrong. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Oct 23, 2014, at 1:50 PM, Paul Vixie p...@redbarn.org wrote: william simpson was right in 1996. we should have moved get host name corresponding to IP to ICMP. the problems described by lee howard's draft are proof that our whole model is wrong. Right, 'cuz there's nothing at all difficult about getting ICMP to work... :) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Ted Lemon mailto:ted.le...@nominum.com Thursday, October 23, 2014 11:16 AM Right, 'cuz there's nothing at all difficult about getting ICMP to work... :) understood. but that's part of what makes this a good solution. systems need to learn to live with hosts whose names they cannot guess. icmp even when it gets through can be spoofed either by the remote system or any intermediate system. that exactly matches the confidence and dependency levels that hostname-depending programs should have. internet service and internet access should be thought of differently. william simpson's icmp idea came with the observation that only a host can reliably report its own name, and only while it's up, because it might have a new name from time to time. the impedance mismatch between the understood and the possible in today's PTR system led to the creation of http://enemieslist.com/ which allows those of us who want to know when a PTR was machine-generated and that the host's actual name is amnesia and should not be able to do the things that real hosts which actually have names should do, can undo all the $GENERATE complexity that internet access providers use to jump through the hoops of pretending that their internet access IP addresses actually have host names, when in reality, they don't and oughtn't. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Paul Vixie wrote: william simpson was right in 1996. we should have moved get host name corresponding to IP to ICMP. the problems described by lee howard's draft are proof that our whole model is wrong. Wrong. What's wrong is SLAAC, which is stateful in the worst possible fashion with distributed state maintenance, which is why extra overhead of DAD is mandated. The proper solution is to ban SLAAC or, better, entire ND, which purposelessly depends on multicast, complexity of which is causing a lot of problems. william simpson's icmp idea came with the observation that only a host can reliably report its own name, and only while it's up, because it might have a new name from time to time. You are right if we need reverse look up only. However, as it might have a new name from time to time means that the host must interact with DNS for updating forward look up, an additional interaction (with different authority, in general) for reverse look up is not bad. It should be noted that, with DHCP, if a host is up, its DHCP server, which have the authority for host's address, is almost certainly up. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Ohta-san, like you I would like to see stateless address auto configuration for ipv6 (SLAAC) die in a fire. Sadly this outcome is beyond our powers. Let's start from where we are, no matter how unpleasant that place may be. Vixie -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
