Re: [DNSOP] new version of IPv6 rDNS for ISPs
One observation is that the delegation to CPE routers (home gateways) is contradictory to RFC6092: REC-8 By DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS resolving server. Not suggesting delegation to CPE shouldn't happen, but would it would negate this requirement. DNS amplification attacks caused, at least partly, by DNS proxies in CPEs is a significant problem. Note that this is often due to the CPEs being open to *recursive* queries. A delegation would only need replies to zones the CPE was authoritative for - however, I'm afraid such a distinction would be lost on many CPE manufacturers. There are also ISPs that block outgoing DNS queries to (residential) CPEs, precisely because of DNS amplification attacks by these CPEs. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
Joe Abley joe.ab...@icann.org wrote: If there was a possible solution where a customer device could auto-register a name using dynamic DNS, how would it know what nameservers to send the UPDATE messages to? Extract the MNAME from the closest-enclosing SOA? How do you find the closest-enclosing SOA, bearing in mind that the address concerned might previously have been used by someone else, and hence the blah.blah.ip6.arpa owner name might already exist? Just query for the SOA at the full RDNS name, and the name server will return the zone apex name and SOA record in the authority section of its reply (or possibly in the answer section though that's unlikely). http://tools.ietf.org/html/draft-andrews-dnsext-soa-discovery Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
Joe Abley joe.ab...@icann.org wrote: I think you skipped a step -- you need to find the zone cut before you can find the nameservers responsible for the zone. I guess I do that by asking for blah.ip6.arpa/IN/SOA and checking the authority section, but what if the authority section is empty because of software choices in some nameserver? Are name servers allowed to leave out the SOA record? It would break negative cacheing. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
John Levine jo...@taugh.com wrote: Why do you think that a host that is not a server and will never be contacted by (non-malicious) other hosts needs a name? Is there such a thing as a host that is not a server? Multicast DNS and DNS-SD exist so that you can discover devices and services on your lan. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
On 2012-11-23, at 06:28, Tony Finch d...@dotat.at wrote: Joe Abley joe.ab...@icann.org wrote: I think you skipped a step -- you need to find the zone cut before you can find the nameservers responsible for the zone. I guess I do that by asking for blah.ip6.arpa/IN/SOA and checking the authority section, but what if the authority section is empty because of software choices in some nameserver? Are name servers allowed to leave out the SOA record? It would break negative cacheing. I was being pessimistic. If that authority-section SOA was frequently missing (e.g. for devices behind home gateways) would anything break from the perspective of stub resolvers? I can't think of anything; hence I assume it's broken. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
On 23 Nov 2012, at 11:28, Tony Finch d...@dotat.at wrote: Are name servers allowed to leave out the SOA record? Yes. Though it depends on what the question was, which server you ask and what data it has. RFC2308 lists some examples of valid NXDOMAIN/NODATA responses containing no SOA record. It would break negative cacheing. So what? It's not compulsory to implement or support that. Which would of course be a Bad Idea. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
On 21 November 2012 15:01, Lee Howard l...@asgard.org wrote: You may remember this draft from a couple of years ago. People keep asking me what a residential ISP should do for IPv6 PTR records, and I keep repeating what's in the draft. The intent is to document existing solutions, since prepopulating PTRs like we did in IPv4 doesn't work. Last time I brought it to DNSOP, there was interest, but not necessarily as a working group document. Since it's been a while, and the operator community is still asking for guidance, I've updated it, and would like a renewed review of it as an individual submission (unless this WG or v6ops wants it). I'm in support of this document being published. One observation is that the delegation to CPE routers (home gateways) is contradictory to RFC6092: REC-8 By DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS resolving server. Not suggesting delegation to CPE shouldn't happen, but would it would negate this requirement. Regards Daryl ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
On Nov 21, 2012, at 11:44 AM, Ted Lemon ted.le...@nominum.com wrote: On Nov 21, 2012, at 10:01 AM, Lee Howard l...@asgard.org wrote: Since it's been a while, and the operator community is still asking for guidance, I've updated it, and would like a renewed review of it as an individual submission (unless this WG or v6ops wants it). The document looks pretty good to me, except that the motivation section is likely to be controversial (as I'm sure you are aware). The reasons you state are not reasons that I personally find motivational; I want a working reverse tree because it's a way to publish information about an address, both for debugging purposes and for operational purposes (e.g., DANE). I could make some suggestions about this section, but I think it might be better to just take it out. I would just ditch the text in the introduction starting with Some of the most... and the three bullet items that follow it. Aside from this quibble, I think the document is useful and should be published. Ted, I agree with this assessment, and perhaps it does make sense to update or remove as needed in a follow-up version. I support this document being published, in order to provide the options that operators can take as they deploy IPv6 and support it in their DNS platforms. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
Hi, On 11/21/2012 9:28 PM, Jim Reid wrote: On 21 Nov 2012, at 18:07, Paul Vixie p...@redbarn.org wrote: network operators should provide PTR RR's for specific addresses which have real names. the inability due to IPv6's richness of address space to provide auto-naming for PTR's does not to me, a problem statement make. +1 +1 not pre-populating rDNS here. feel that absence of rDNS is a useful indicator for don't accept spam from here. 1.1 s/2.0.192.IN-ADDR-ARPA/2.0.192.IN-ADDR.ARPA/g while I consider 1.1 correct. I doubt whether that's a good situation. 2.1 sounds a bit like it's bad to receive an NXDOMAIN. Is it bad? is successful lookup one that gets a response, or one that has ANSWER: 0 ? Under recommendations I personally would like the negative response to be given more consideration. Maybe as a default behavior for residential connections as long as end users have not chosen any of the other options (as/if provided by the ISP)...? Frank ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
On Nov 22, 2012, at 2:07 PM, Joe Abley joe.ab...@icann.org wrote: This approach would leave a single nameserver responsible for a delegation, which is contrary to general best practice. Quite possibly that's a reasonable trade-off in this case (poor link quality affecting DNS resolution would also affect the ability of the customer to use the network) but the trade-off should be mentioned. The conclusion that this is not an option for residential ISPs assumes sysadmin requirements on the part of the user, incidentally. If this convention was widely deployed in home gateways, users wouldn't need to care. The mechanism for specifying how the delegation happens should allow the zone to be delegated to more than one name server—presumably the primary would be the CPE device, but someone who really cares about the reliability of the reverse zone, if there is such a person, would want to set up a secondary elsewhere and keep it up to date with zone transfers or the like. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
In message a7dfdb0d-0f13-4b87-b331-30701d101...@icann.org, Joe Abley writes: Hi Lee, Some comments below, based on a fairly cursory skim through (so, I may well h ave missed and/or understood things). 2.2 Wildcard match There is no mention of the issue of uniqueness. What do you do when you have five thousand different customers who all attempt secure dynamic updates with the name macbook? Or, what to do when you have two Nest thermostats in the same house (on the same network) both of which think their name is nest? If there was a possible solution where a customer device could auto-register a name using dynamic DNS, how would it know what nameservers to send the UPDA TE messages to? Extract the MNAME from the closest-enclosing SOA? How do you find the closest-enclosing SOA, bearing in mind that the address concerned mi ght previously have been used by someone else, and hence the blah.blah.ip6.ar pa owner name might already exist? 2.3.1 Dynamic DNS from individual hosts I think it should be mentioned that this is a niche scenario, and that the va st majority of customers today don't connect a single host directly to their DSL/cable/whatever modem. And alongside that, some study should be cited that has come to that conclusion based on actual measurements, rather than my spe culation :-) Individual hosts should be doing dynamic DNS. Where that update is sent to may change but all machines should be doing it and should support TSIG as a minimum. They should also expect to see DNAME and CNAME records. i.e. the update may be to a name other than that produced by the address to IP6.ARPA (and IN-ADDR.ARPA) mapping. Individual hosts should be able to work out where to send the updates by querying the DNS to find the nameservers of the containing zone after processing and DNAME/CNAME mappings. We shipped code sans DNAME/CNAME remapping a decade ago that did this. Darwin and Windows already support sending dynamic updates though I don't believe they handle the presence of DNAME or CNAME. 2.3.2 Dynamic DNS through Residential Gateways I think this section makes an assumption that the place to send your UPDATEs to is the same DNS server that is handed out (e.g. via DHCP option) for use a s a recursive server. If that's really a requirement, that ought to be spelle d out (because I think in general it's unusual). Most ISPs hand out at least two such addresses. Can either one be used? If not, which one? 2.3.3 Dynamic DNS Delegations This approach would leave a single nameserver responsible for a delegation, w hich is contrary to general best practice. Quite possibly that's a reasonable trade-off in this case (poor link quality affecting DNS resolution would als o affect the ability of the customer to use the network) but the trade-off sh ould be mentioned. Firstly there are multiple ways to do a delegation. * Use a DNAME to a namespace that is already delegated. a.b.c.d.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA DNAME IP6.EXAMPLE.NET * The traditional method using NS records. The conclusion that this is not an option for residential ISPs assumes sysadm in requirements on the part of the user, incidentally. If this convention was widely deployed in home gateways, users wouldn't need to care. And with IPv6 I would expect most homes *will* get dynamic forward zones. IPv6 *is* a game changer and people are still rooted in IPv4 think. 2.5 Dynamically Generate PTR When Queried (On the Fly) The DNSSEC commentary is a bit weird. Keys are associated with zones, not wit h RRSets. Keys would not need to be generated on the fly; I think you're talk ing about signatures. 4.3 Considerations for Other Uses of the DNS I don't understand this section at all. What does it mean? General I don't feel that in its current form this draft provides much practical advi ce to an ISP who is trying to find an analogue to pre-populate all my IN-ADD R zones containing customer addresses as is commonly (whatever you think abo ut it) done in IPv4. I don't think that's generally a fault of the draft; I t hink this is just an operational consideration that was not well-explored dur ing the development of IPv6. There are potentially additional requirements fo r hosts, routers, DHCPv6 and RADIUS in here. Perhaps a more useful approach (if there is consensus that more work is requi red in this area) would be to work on a requirements document for the solutio n space. If the goal is rather to figure out practical advice which ISPs can use today to provide PTR records for their customers, then I think this draft needs to provide some more concrete advice. Joe On 2012-11-21, at 10:01, Lee Howard l...@asgard.org wrote: You may remember this draft from a couple of years ago. People keep asking me what a residential ISP should do for IPv6 PTR records, and I keep repeating what's in the draft. The intent is to document existing
Re: [DNSOP] new version of IPv6 rDNS for ISPs
On 2012-11-22, at 18:10, Mark Andrews ma...@isc.org wrote: Individual hosts should be doing dynamic DNS. Where that update is sent to may change but all machines should be doing it and should support TSIG as a minimum. The missing pieces here include: - what sane ISP/campus/home network/hotspot operator gives credentials to customers or even random users to complete dynamic updates to one of their master servers? - how can a TSIG key be shared between a network operator and a client that potentially don't know each other? - what name should a user be allowed to specify in their PTR RDATA? - what stops user A from sending authentically TSIG-signed UPDATEs to a nameserver and changing (or removing) user B's PTR? - what consumer systems do this by default? (I think it's none, but I thought I'd ask) Individual hosts should be able to work out where to send the updates by querying the DNS to find the nameservers of the containing zone after processing and DNAME/CNAME mappings. I think you skipped a step -- you need to find the zone cut before you can find the nameservers responsible for the zone. I guess I do that by asking for blah.ip6.arpa/IN/SOA and checking the authority section, but what if the authority section is empty because of software choices in some nameserver? I guess then I need to [krill:~]% ifconfig en0 | grep inet6 | grep -vi fe80:: inet6 2001:4900:1042:100:7ed1:c3ff:fee8:102f prefixlen 64 autoconf [krill:~]% [krill:~]% dig 7.7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig 7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig 2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig 6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig 4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig 8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig 7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig 2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig 4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig 8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig 5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig 0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig 0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig 1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig 0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short [krill:~]% dig 2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short . jabley.hopcount.ca. 2011032174 10800 3600 604800 86400 [krill:~]% Ah, there it is. There's no MNAME specified (I rudely called it .) but let's pretend I didn't do that. Now I need to know: what is my name? how do I know the name is unique within this network? what TSIG key should I use? Let's suspend disbelief and suppose that I am capable of knowing a reasonable name that represents a reasonable, valid FQDN, that I know it's unique, and that I have somehow discovered a TSIG secret for the local network that is still a secret, and isn't shared knowledge amongst 300,000 other customers. Once I've answered those questions, I send a TSIG-signed UPDATE to the MNAME-specified server and update: 7.7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN PTR krill.hopcount.ca. Presumably we're encouraging PTR records to make sense, in which case I also want to update: krill.hopcount.ca. 2001:4900:1042:100:584e:a27e:8df4:6277 Since hopcount.ca is my own domain, and I run the server referenced in the MNAME (assuming again I change it from . to something sensible), there is some chance I could make this work. What if the domain is hosted elsewhere? What if it's the ISP's domain I've decided to use? What if I have no reasonable parent domain configured, and the local hostname is Joe's Computer? I need to repeat this for every v6 address I have (I have five right now, apparently, not counting the link-local) and also handle deletion of s and PTRs that might already be there, accommodating the full range of abrupt disconnects that phones and networks enjoy six hundred times per day. Even without harping on about the many unanswerable questions in the
Re: [DNSOP] new version of IPv6 rDNS for ISPs
In message 30776e96-c575-4fde-899c-fdc8441c5...@icann.org, Joe Abley writes: On 2012-11-22, at 18:10, Mark Andrews ma...@isc.org wrote: Individual hosts should be doing dynamic DNS. Where that update is sent to may change but all machines should be doing it and should support TSIG as a minimum. The missing pieces here include: - what sane ISP/campus/home network/hotspot operator gives credentials = to customers or even random users to complete dynamic updates to one of = their master servers? ISP's have a contractual relationship often with shared secrets (username / password) for updating all sorts of information via a web interface. TSIG is just a username / password pair operated over DNS instead of HTTP / HTTPS. You can still do all the sanity checking you want on the names if you want. Named has the hooks to do this today. What it doesn't have yet is a external TSIG database but that is realitively easy to add. - how can a TSIG key be shared between a network operator and a client = that potentially don't know each other? Use a DH TKEY exchange with packets sourced from the address you want to be updated. You then have a TSIG that is bound to a address. You only allow that TSIG to update the associated reverse name. - what name should a user be allowed to specify in their PTR RDATA? Any legal multi label hostname. You can do checks on the name for obsenties if you want. - what stops user A from sending authentically TSIG-signed UPDATEs to a = nameserver and changing (or removing) user B's PTR? See above. - what consumer systems do this by default? (I think it's none, but I = thought I'd ask) We are designing for the FUTURE. The consumer systems WILL do this if the operators add support. This is all existing protocols being bolted together. Individual hosts should be able to work out where to send the updates by querying the DNS to find the nameservers of the containing zone after processing and DNAME/CNAME mappings. I think you skipped a step -- you need to find the zone cut before you = can find the nameservers responsible for the zone. I guess I do that by = asking for blah.ip6.arpa/IN/SOA and checking the authority section, but = what if the authority section is empty because of software choices in = some nameserver? I guess then I need to We shipped code to do this back before the turn of the millenium with BIND 8 as it was needed for nsupdate. [krill:~]% ifconfig en0 | grep inet6 | grep -vi fe80:: inet6 2001:4900:1042:100:7ed1:c3ff:fee8:102f prefixlen 64 = autoconf=20 [krill:~]%=20 [krill:~]% dig = 7.7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. = IN SOA +short [krill:~]% dig = 7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. = IN SOA +short=20 [krill:~]% dig = 2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN = SOA +short=20 [krill:~]% dig = 6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN = SOA +short=20 [krill:~]% dig = 4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = +short=20 [krill:~]% dig = f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = +short=20 [krill:~]% dig = d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = +short=20 [krill:~]% dig = 8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = +short =20 [krill:~]% dig e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. = IN SOA +short =20 [krill:~]% dig 7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. = IN SOA +short =20 [krill:~]% dig 2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN = SOA +short =20 [krill:~]% dig a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN = SOA +short=20 [krill:~]% dig e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = +short=20 [krill:~]% dig 4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = +short=20 [krill:~]% dig 8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = +short=20 [krill:~]% dig 5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20= [krill:~]% dig 0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20= [krill:~]% dig 0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20 [krill:~]% dig 1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20 [krill:~]% dig 0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20 [krill:~]% dig 2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20 . jabley.hopcount.ca. 2011032174 10800 3600 604800 86400 [krill:~]%=20 % nsupdate -dd update add e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. 0 in ptr dummy.example.net. send Reply from SOA query: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 5017 ;; flags: qr rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA ;; AUTHORITY SECTION: 2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. 0 IN
Re: [DNSOP] new version of IPv6 rDNS for ISPs
And with IPv6 I would expect most homes *will* get dynamic forward zones. More likely no forward zones, since they serve no useful purpose. IPv6 *is* a game changer and people are still rooted in IPv4 think. Agreed. Why do you think that a host that is not a server and will never be contacted by (non-malicious) other hosts needs a name? R's, John PS: If you were planning to say that with the magic of IPv6, everyone will be able to run servers on their home cable connection, don't bother. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
In message 20121123014642.23974.qm...@joyce.lan, John Levine writes: And with IPv6 I would expect most homes *will* get dynamic forward zones. More likely no forward zones, since they serve no useful purpose. IPv6 *is* a game changer and people are still rooted in IPv4 think. Agreed. Why do you think that a host that is not a server and will never be contacted by (non-malicious) other hosts needs a name? Because servers out there won't allowing it access without a name. I know this is stupid but they exist. R's, John PS: If you were planning to say that with the magic of IPv6, everyone will be able to run servers on their home cable connection, don't bother. I expect to have fibre to the home within 5 years as part of the NBN rollout here in Aus. With that there is no good reason discourage running servers at home as there are with asymetric access technologies like cable and aDSL. 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] new version of IPv6 rDNS for ISPs
Agreed. Why do you think that a host that is not a server and will never be contacted by (non-malicious) other hosts needs a name? Because servers out there won't allowing it access without a name. I know this is stupid but they exist. Given a choice between rolling out complex and fragile rDNS systems, and telling people with such servers that the IPv6 world is different, I know what I'd do. PS: If you were planning to say that with the magic of IPv6, everyone will be able to run servers on their home cable connection, don't bother. I expect to have fibre to the home within 5 years as part of the NBN rollout here in Aus. With that there is no good reason discourage running servers at home as there are with asymetric access technologies like cable and aDSL. Nothing personal, but if you think that upload speed has anything to do with the rules against servers on consumer broadband, you don't understand the internet access business very well. (Hint: ADSL uptream bandwidth is unshared to the DSLAM.) R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
In message 20121123021341.2672.qm...@joyce.lan, John Levine writes: Agreed. Why do you think that a host that is not a server and will never be contacted by (non-malicious) other hosts needs a name? Because servers out there won't allowing it access without a name. I know this is stupid but they exist. Given a choice between rolling out complex and fragile rDNS systems, and telling people with such servers that the IPv6 world is different, I know what I'd do. PS: If you were planning to say that with the magic of IPv6, everyone will be able to run servers on their home cable connection, don't bother. I expect to have fibre to the home within 5 years as part of the NBN rollout here in Aus. With that there is no good reason discourage running servers at home as there are with asymetric access technologies like cable and aDSL. Nothing personal, but if you think that upload speed has anything to do with the rules against servers on consumer broadband, you don't understand the internet access business very well. (Hint: ADSL uptream bandwidth is unshared to the DSLAM.) There are lots of reasons. Most of which don't make any sense at all if you examine them critically. If you are paying for bits to be moved it should matter where they are being moved from. R's, John -- 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] new version of IPv6 rDNS for ISPs
On Nov 22, 2012, at 8:46 PM, John Levine jo...@taugh.com wrote: PS: If you were planning to say that with the magic of IPv6, everyone will be able to run servers on their home cable connection, don't bother. Why not? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
On Nov 22, 2012, at 10:37 PM, George Michaelson g...@algebras.org wrote: On 23/11/2012, at 1:18 PM, Ted Lemon ted.le...@nominum.com wrote: On Nov 22, 2012, at 8:46 PM, John Levine jo...@taugh.com wrote: PS: If you were planning to say that with the magic of IPv6, everyone will be able to run servers on their home cable connection, don't bother. Why not? Because the lack of public IPv4 was only an *excuse* for blocking this functionality: ISPs in the main don't want you to equalise traffic coming from their CAN network out to the world, they didn't build with that model in mind. I hear you, but this isn't really a meaningful rejoinder, because this equalization you are talking about isn't a prerequisite for selling devices that will want to publish services from the home. You can't have a network that only lets traffic go in one direction. IPv4+NAT makes it hard for traffic to go in both directions, and yet still we have bittorrent, Skype, limited VoIP, and lots of back-to-my-pc solutions. We have dyndns.org, which wouldn't have needed to exist if people weren't setting up home servers. So really, while it may be true that ISPs will resist certain kinds of home servers being set up, and I don't people to be running web servers targeted to the general public on home network connections, it's entirely reasonable to think that low-use home servers will be a reality in the near future. We know that ISPs are talking about serious, high-reliability M2M applications. So external reachability is going to be a reality. It's easy to dismiss this (which I don't think you were doing—I'm really referring back to what John Levine said) by putting down home servers as a hobbyist sort of thing, which ISPs won't feel market pressure to support, but I think that this attitude is actually what's unrealistic. There is a *huge* untapped market in peer-to-peer applications. We can think now about how to make sure that this market has the tools it needs to grow, or we can ignore it until it becomes big, at which point it will be too late. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] new version of IPv6 rDNS for ISPs
You may remember this draft from a couple of years ago. People keep asking me what a residential ISP should do for IPv6 PTR records, and I keep repeating what's in the draft. The intent is to document existing solutions, since prepopulating PTRs like we did in IPv4 doesn't work. Last time I brought it to DNSOP, there was interest, but not necessarily as a working group document. Since it's been a while, and the operator community is still asking for guidance, I've updated it, and would like a renewed review of it as an individual submission (unless this WG or v6ops wants it). Filename:draft-howard-isp-ip6rdns Revision:05 Title: Reverse DNS in IPv6 for Internet Service Providers Creation date: 2012-11-20 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-05.txt Status: http://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns Htmlized:http://tools.ietf.org/html/draft-howard-isp-ip6rdns-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-howard-isp-ip6rdns-05 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 for ISPs to manage the ip6.arpa zone for IPv6 address space assigned to many customers. Thanks, Lee ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
On Nov 21, 2012, at 10:01 AM, Lee Howard l...@asgard.org wrote: Since it's been a while, and the operator community is still asking for guidance, I've updated it, and would like a renewed review of it as an individual submission (unless this WG or v6ops wants it). The document looks pretty good to me, except that the motivation section is likely to be controversial (as I'm sure you are aware). The reasons you state are not reasons that I personally find motivational; I want a working reverse tree because it's a way to publish information about an address, both for debugging purposes and for operational purposes (e.g., DANE). I could make some suggestions about this section, but I think it might be better to just take it out. I would just ditch the text in the introduction starting with Some of the most... and the three bullet items that follow it. Aside from this quibble, I think the document is useful and should be published. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
On 2012-11-21 4:44 PM, Ted Lemon wrote: ... Aside from this quibble, I think the document is useful and should be published. my quibble is different. ipv6 is bringing some tough love to the consumer-facing edge. the fact that ISP's auto-populated the IPv4 PTR tree made it impossible for mail server operators to distinguish between consumer grade and business grade internet connections. since consumer grade connectees should really not be connecting to SMTP servers on other networks, there's been a great deal of work to find all of the common auto-populated PTR naming patterns in use anywhere in the world, in order to reject off-net e-mail from consumer grade connections. this work is inefficient, ineffective, painful even when correct, and often wrong. there are some excellent reasons not to use PTR RR records for this purpose, starting with good security practices and continuing through good engineering practices. nevertheless this is a pre-existing property of the existing server plant, and even if server operators were willing to give it up, the tail would be very long. i'm going to treat this as an unavoidable universal mistake that all of us will have to live with, forever, period. network operators should provide PTR RR's for specific addresses which have real names. the inability due to IPv6's richness of address space to provide auto-naming for PTR's does not to me, a problem statement make. paul -- It seems like the rules for automagic completion of incomplete names typed into browsers are going to start to look like those for the game of fizbin. --rick jones ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
On 21 Nov 2012, at 18:07, Paul Vixie p...@redbarn.org wrote: network operators should provide PTR RR's for specific addresses which have real names. the inability due to IPv6's richness of address space to provide auto-naming for PTR's does not to me, a problem statement make. +1 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
