[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
