Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt
On Tue, Mar 31, 2015 at 4:31 PM, Alain Durand wrote: > > 3) There is another solution, that is do nothing, i.e. Do NOT populate the > reverse tree. >Probably ISPs on that path would like to see an update to RFC1033 & > RFC1912 to >explicitly say that the PTR record requirement is relaxed in IPv6 (and > maybe >in IPv4 as well?) > > The mere fact that this draft is still here many years after the effort > was started should tell us somethingŠ It would appear as if the world is > on path 3) above. > I agree with Alain. With widespread use of stateless address auto-configuration and privacy addresses, I don't think the blanket PTR requirements/recommendations in those old RFCs are practical or relevant to IPv6. They make sense for IPv6 servers and statically configured computers, but not dynamically configured clients. And it might make sense to update those documents not only to relax those requirements for IPv6, but also to dissuade IPv6 services deployers from using reverse DNS checks as a pre-condition to providing service. If the ISP is offering DHCPv6, they might be able to prepopulate the reverse DNS for a sufficiently small address pool. For non-residential/business customers that are planning to run servers, I assume they'd get static address assignments and either run their own DNS, and/or have the ISP configure static reverse DNS entries for them. When I was involved in running a large IPv6-enabled campus network, no client computers (predominantly using SLAAC/privacy addresses) got IPv6 PTR records and I never heard of any issues encountered by them in accessing IPv6 services. Same goes for many of my peers in the R&E world (many of whom were early adopters of IPv6). SMTP servers are one category of services where it's still popular to do client PTR checks even for v6, but most IPv6 clients don't deliver to mail servers directly (they usually talk to a submission server, where user authentication is the access control mechanism used, rather than PTR checks). Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt
Hi Lee Howard, Here are my comments on the draft: Section 1. What exactly is the reference to [RFC1033] for? I can't see any of the text in this sentence in RFC1033. Section 1.2 I don't see prefix delegation being mentioned in this section and I think it should. If an ISP (perhaps wireless) just handed out 1 IPv6 address per subscriber the problem would be no worse than with IPv4 and the plain old $GENERATE technique would still work. Section 1.2 I agree with John Levine's comment that 'manual zone entry is cumbersome in IPv6' is an interesting observation but not necessarily applicable to the problem this draft addresses. Section 1.2 talks about the 'host portion' of the address. This would be more accurately referred to as the Interface Identifier (RFC 4291 section 2.5.1) Section 1.2 'DNS administrators of residential ISPs should consider how to follow this advice for and PTR RRs in the residential ISP.' This sentence is not clear. Section 2.1 is confusing because it says that providing a negative response does not satisfy RFC1912 but then the next sentence goes on and say that even an NXDOMAIN will give the best user experience. Are you mixing two problems here? Section 2.3 'Dynamic DNS may not scale effectively in large ISP networks which have no single master name server, but a single master server is not best practice' This sentence is not clear too many no/not. Section 2.3.1 Once it learns its address, and has a resolving name server, the host must perform an SOA lookup on the ip6.arpa record to be added, to find the owner, which will lead to the SOA record. This sentence is not clear. What owner are we talking about? MNAME field in SOA? Section 2.3.2 relay dynamic DNS updates from hosts to the servers and domain provided by the ISP. Host behavior is unchanged; they should provide updates to the ISP's servers as described above. If the host behavior is unchanged, then what is the gateway relaying? Section 2.3.3 An ISP may elect to provide authoritative responses as a secondary server to the customer's primary server. For instance, the home gateway name server could be the master server, with the ISP providing the only published NS authoritative servers. primary/secondary setup for home gateways are not relevant to the draft, I suggest this section/sentence is removed or reworked. Section 3 fails to mention traceroute that I feel is one of the most important application that takes advantage of reverse DNS. Typo: administrator will then neet to consider. NEED Section 5, my first name is misspelled. Thanks, Stephan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt
>Looking for a few folks to do a close read. Send notes to the list, and >I'll make necessary revisions. If it's baked, I think there's consensus. I read through it. It's basically fine but of course here are a few suggestions. I'd redo sec 1.2 to make it clearer what the serious problems are. I don't think that the length of the names is a big deal, computers can deal with that. The problems are a) the address space is far too large to cover with static names as we do in IPv4 and, b) you can't easily tell where the hosts are. On IPv4 networks, addresses are usually configured either statically or by DHCP, so the network operator knows what addresses are assigned befor the hosts do. On IPv6, SLAAC means that hosts choose addresses effectively at random, so there are new and not widely used mechanisms (described later) to percolate those addresses back to the network and assign names to them. It would also be reasonable to offer as a concrete proposal that hosts with static addresses have forward and reverse DNS, while those without have no rDNS, and don't have forward DNS provided by the ISP. (If they want to use dyndns, go ahead.) In the list of ways to dynamically insert DNS records, it seems to me that most current home gateways are plenty capable to act as DNS servers or whatever, so the issue isn't that they can't, but that nontechnical users wouldn't be able to manage them, while malware would. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt
Lee, I will read through this in the next day or so. Thanks, Sean > On Mar 31, 2015, at 9:46 AM, Lee Howard wrote: > > There's been no discussion since this revision. > The Chairs have asked for a couple of reviews. I've asked a couple of > folks, but haven't had any response. > > Looking for a few folks to do a close read. Send notes to the list, and > I'll make necessary revisions. If it's baked, I think there's consensus. > > Thanks, > > Lee > >> On 2/15/15, 11:56 AM, "Lee Howard" wrote: >> >> Per discussion, I have added the four use cases discussed at a previous >> meeting. >> The "Recommendations" section is now "Considerations and Recommendations." >> The guidance from the WG was that ISPs should be advised of how PTRs are >> used, so they can decide how important it is to populate them. I left in >> the recommendations from before, since an ISP might decide it's important. >> >> I think the references to other ongoing work are up to date, but let me >> know if I've missed anything, please. >> >> We had pretty strong support the last time we discussed aloud (spontaneous >> applause). Is this document ripe for publication? >> >> >> Thanks, >> Lee >> >> On 2/15/15 11:46 AM, "internet-dra...@ietf.org" >> wrote: >> >>> >>> A new version of I-D, draft-howard-isp-ip6rdns-07.txt >>> has been successfully submitted by Lee Howard and posted to the >>> IETF repository. >>> >>> Name:draft-howard-isp-ip6rdns >>> Revision:07 >>> Title:Reverse DNS in IPv6 for Internet Service Providers >>> Document date:2015-02-16 >>> Group:Individual Submission >>> Pages:14 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-07.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns/ >>> Htmlized: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-07 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-howard-isp-ip6rdns-07 >>> >>> Abstract: >>> In IPv4, Internet Service Providers (ISPs) commonly provide IN- >>> ADDR.ARPA information for their customers by prepopulating the zone >>> with one PTR record for every available address. This practice does >>> not scale in IPv6. This document analyzes different approaches and >>> considerations for ISPs in managing the ip6.arpa zone for IPv6 >>> address space assigned to many customers. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >> >> >> ___ >> 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt
Commenting on an old draft I had worked/started with Lee on many years ago! 1) The intro should make it clear that this document DOES NOT recommend any solutions, it just describe the trade-offs. In fact, none of the solutions are really good. 2) there should be a longer discussion of hosts using privacy extensions RFC4941. What is the intended behavior here? Do those hosts need/want a reverse DNS entry? There is some text in section 2.3.1 but, IMHO, there should be a whole section toward the beginning of the document discussing this. 3) There is another solution, that is do nothing, i.e. Do NOT populate the reverse tree. Probably ISPs on that path would like to see an update to RFC1033 & RFC1912 to explicitly say that the PTR record requirement is relaxed in IPv6 (and maybe in IPv4 as well?) The mere fact that this draft is still here many years after the effort was started should tell us something It would appear as if the world is on path 3) above. Alain. On 3/31/15, 9:46 AM, "Lee Howard" wrote: >There's been no discussion since this revision. >The Chairs have asked for a couple of reviews. I've asked a couple of >folks, but haven't had any response. > >Looking for a few folks to do a close read. Send notes to the list, and >I'll make necessary revisions. If it's baked, I think there's consensus. > >Thanks, > >Lee > >On 2/15/15, 11:56 AM, "Lee Howard" wrote: > >>Per discussion, I have added the four use cases discussed at a previous >>meeting. >>The "Recommendations" section is now "Considerations and >>Recommendations." >>The guidance from the WG was that ISPs should be advised of how PTRs are >>used, so they can decide how important it is to populate them. I left in >>the recommendations from before, since an ISP might decide it's >>important. >> >>I think the references to other ongoing work are up to date, but let me >>know if I've missed anything, please. >> >>We had pretty strong support the last time we discussed aloud >>(spontaneous >>applause). Is this document ripe for publication? >> >> >>Thanks, >>Lee >> >>On 2/15/15 11:46 AM, "internet-dra...@ietf.org" >> >>wrote: >> >>> >>>A new version of I-D, draft-howard-isp-ip6rdns-07.txt >>>has been successfully submitted by Lee Howard and posted to the >>>IETF repository. >>> >>>Name:draft-howard-isp-ip6rdns >>>Revision:07 >>>Title: Reverse DNS in IPv6 for Internet Service Providers >>>Document date: 2015-02-16 >>>Group: Individual Submission >>>Pages: 14 >>>URL: >>>http://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-07.txt >>>Status: >>>https://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns/ >>>Htmlized: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-07 >>>Diff: >>>http://www.ietf.org/rfcdiff?url2=draft-howard-isp-ip6rdns-07 >>> >>>Abstract: >>> In IPv4, Internet Service Providers (ISPs) commonly provide IN- >>> ADDR.ARPA information for their customers by prepopulating the zone >>> with one PTR record for every available address. This practice does >>> not scale in IPv6. This document analyzes different approaches and >>> considerations for ISPs in managing the ip6.arpa zone for IPv6 >>> address space assigned to many customers. >>> >>> >>> >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission >>>until the htmlized version and diff are available at tools.ietf.org. >>> >>>The IETF Secretariat >>> >> >> >>___ >>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 smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt
Hi Lee, I will review. Thanks, Stephan > -Original Message- > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Lee Howard > Sent: Tuesday, March 31, 2015 6:47 AM > To: dnsop@ietf.org > Subject: [DNSOP] draft-howard-isp-ip6rdns-07.txt > > There's been no discussion since this revision. > The Chairs have asked for a couple of reviews. I've asked a couple of folks, > but haven't had any response. > > Looking for a few folks to do a close read. Send notes to the list, and I'll > make > necessary revisions. If it's baked, I think there's consensus. > > Thanks, > > Lee > > On 2/15/15, 11:56 AM, "Lee Howard" wrote: > > >Per discussion, I have added the four use cases discussed at a previous > >meeting. > >The "Recommendations" section is now "Considerations and > Recommendations." > >The guidance from the WG was that ISPs should be advised of how PTRs > >are used, so they can decide how important it is to populate them. I > >left in the recommendations from before, since an ISP might decide it's > important. > > > >I think the references to other ongoing work are up to date, but let me > >know if I've missed anything, please. > > > >We had pretty strong support the last time we discussed aloud > >(spontaneous applause). Is this document ripe for publication? > > > > > >Thanks, > >Lee > > > >On 2/15/15 11:46 AM, "internet-dra...@ietf.org" > > > >wrote: > > > >> > >>A new version of I-D, draft-howard-isp-ip6rdns-07.txt has been > >>successfully submitted by Lee Howard and posted to the IETF > >>repository. > >> > >>Name: draft-howard-isp-ip6rdns > >>Revision: 07 > >>Title: Reverse DNS in IPv6 for Internet Service Providers > >>Document date: 2015-02-16 > >>Group: Individual Submission > >>Pages: 14 > >>URL: > >>http://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-07.txt > >>Status: > >>https://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns/ > >>Htmlized: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-07 > >>Diff: > >>http://www.ietf.org/rfcdiff?url2=draft-howard-isp-ip6rdns-07 > >> > >>Abstract: > >> In IPv4, Internet Service Providers (ISPs) commonly provide IN- > >> ADDR.ARPA information for their customers by prepopulating the zone > >> with one PTR record for every available address. This practice does > >> not scale in IPv6. This document analyzes different approaches and > >> considerations for ISPs in managing the ip6.arpa zone for IPv6 > >> address space assigned to many customers. > >> > >> > >> > >> > >> > >>Please note that it may take a couple of minutes from the time of > >>submission until the htmlized version and diff are available at > >>tools.ietf.org. > >> > >>The IETF Secretariat > >> > > > > > >___ > >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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
