On 3/16/17, 7:02 AM, "Philip Homburg" <pch-bf054d...@u-1.phicoh.com on behalf of pch-dnso...@u-1.phicoh.com> wrote:
>>1. I do not think there is consensus that having PTRs is or is not a best >>practice, so emphasizing the lack of consensus lets us move on to what an >>ISP can do, if they care to do anything. >>The first paragraph has been overhauled to say "While the need for a PTR >>record and for it to match >> is debatable as a best practice, some network services [see Section 3] >>still do rely on PTR lookups, and some check the source address of >>incoming connections and verify that the PTR and A records match before >>providing service.=B2 > >Is it possible to have a separate section about e-mail? > >In my experience, without reverse DNS it is essentially impossible to have >mail delivered to the internet at large. Yes. > >So where most uses of PTR records are a nice to have to can be decided >locally, >for e-mail it is other parties on the internet that force the use of PTR >records. > >At the same time, if someone is capable of operating a mail server then >operating an auth. DNS server is not really out of line. I agree that people reject mail if there¹s no PTR; I think this is used in fighting spam, based on an inference that if there¹s no PTR, you¹re a spam bot rather than a legitimate mail server. The first case listed in 4. Considerations and Recommendations says There are six common uses for PTR lookups: Rejecting mail: A PTR with a certain string or missing may indicate "This host is not a mail server," which may be useful for rejecting probable spam. The absence of a PTR leads to the desired behavior. The draft currently doesn't say the opposite, which is ³A mail server is therefore expected to have a PTR.² It does say, in 5.1 Using Reverse DNS for Security: 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. [continued below] > >So I'd like some text that describes the importance of reverse DNS for >e-mail >and then basically says that if an ISP allows customers to handle their >own outgoing e-mail then that ISP SHOULD provide customers with a way of >setting up PTR records for those mail servers, even if it is just >delegating >part of the name space by setting up NS records. I¹ve quoted much of that text above. Given that the document is about residential ISPs, and given the above, plus the guidance that the information should match if it¹s possible to reconcile them, does this document need an affirmative statement about mail servers? If so, I think I would revise this text: Rejecting mail: A PTR with a certain string or missing may indicate "This host is not a mail server," which may be useful for rejecting probable spam. The absence of a PTR leads to the desired behavior. to say: Evaluating mail servers: no PTR, or a PTR with a certain string, may indicate "This host is not a mail server," which may be useful for rejecting probable spam. Therefore, legimitate mail servers are expected to have a PTR matching forward. But I do think this recommendation is covered under: when a host has a static address and name, AAAA and PTR records should exist and match. > >Do you have a reference for the following statement >Serving ads: "This host is probably in town.province." An ISP that does >not >provide PTR records might affect somebody else's geolocation. No. Given the privacy considerations, I¹ve changed the example from ³x.town.province² to ³string.region² and added privacy considerations. So I need to fix this text anyway. > >Extracting geo information from reverse DNS is very hard. As far as I >know, >geo location services for IPv4 mostly rely on other sources. That¹s probably true. Given that I need to update it to match what it says in the Privacy Considerations section and the examples, should I just remove mention of geolocation? Or should I tweak it to match the rest, and add text saying, ³But reverse DNS is not a great source for geolocation information²? > > >The following is not clear to me: >Some ISP DNS administrators may choose to provide only a NXDomain >response to PTR queries for subscriber addresses. [...] >Providing a negative response in response to PTR >queries does not satisfy the expectation in [RFC1912] for entries to >match. Users of services which are dependent on a successful lookup >will have a poor experience. For instance, some web services and SSH >connections wait for a DNS response, even NXDOMAIN, before >responding. > >Why would a NXDOMAIN response to a PTR query have a negative impact >on performance? If any, it would be faster because it saves a forward >lookup. > >Maybe you want to say that a PTR lookup has to result in a quick reply, >even it is an NXDOMAIN. A delegation to a name server that does not >respond >will cause a delay in applications that wait for the reverse DNS lookup to >complete. Good note. I think I revised this paragraph several times, and it didn¹t keep its integrity. Old sentence: Users of services which are dependent on a successful lookup will have a poor experience. Proposed new sentence: Users of services which are dependent on a successful lookup will have a poor experience if they have to wait for a timeout; an NXDomain response is faster. Old sentence: For best user experience, then, it is important to return a response, rather than have a lame delegation. Proposed new sentence: For best user experience, then, it is important to return a response, including NXDomain, rather than have a lame delegation. Resulting new paragraph (unformatted): Some ISP DNS administrators may choose to provide only a NXDomain response to PTR queries for subscriber addresses. In some ways, this is the most accurate response, since no name information is known about the host. Providing a negative response in response to PTR queries does not satisfy the expectation in [RFC1912 <https://tools.ietf.org/html/rfc1912>] for entries to match. Users of services which are dependent on a successful lookup will have a poor experience if they have to wait for a timeout; an NXDomain response is faster. For instance, some web services and SSH connections wait for a DNS response, even NXDOMAIN, before responding. For best user experience, then, it is important to return a response, including NXDomain, rather than have a lame delegation. On the other hand, external mail servers are likely to reject connections, which might be an advantage in fighting spam. DNS administrators should consider the uses for reverse DNS records and the number of services affecting the number of users when evaluating this option. > >I don't see a discussion about DNAME. Maybe that's worth adding? Is it? There are several places where the document talks about delegating authority for a prefix, but it never says how. Now that you mention it, I see how it¹s relevant, but I¹m on the fence about whether there¹s anything important to say that hasn¹t already been said in better documents. Lee _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
