In message <87mwmao693.fsf@nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
Joe Abley <jabley@hopcount.ca> writes:
On 2013-10-15, at 10:57, Bj=C3=B8rn Mork <bjorn@mork.no> wrote:
People keep saying the PTR records don't mean anything yet still demand really strong authentication for updates of PTR records. TCP is more than a strong enough authenticator to support update from self. =20 This sounded like an excellent idea at first, but then I started
Mark Andrews <marka@isc.org> writes: =20 thinking: As a home user, would I really want to give anyone with access to my network the right to change my reverse delegation?
I think what you'd be doing is giving anybody you have assigned an IPv6 address to the ability to update the PTR (or a delegation, since Mark suggested that too) for that particular address.
So, it's not "my reverse delegation", it's "my 2^80 or fewer reverse delegations" (if you've been assigned a /48).
Ah, right. I understood the proposal as "any address within then /48 can update the delegation for the /48 reverse".
But if that would be 2^80 distinct delegations or PTRs, then I am worrying about luser stupidiy and the ability to DoS the name server. I guess this can be combined with some sort of limit, making it fly? Still don't see the advantage of being able to delegate if it's only single address delegations. But allowing a limited number of PTR updates based on TCP sounds like a nice idea. Going to consider that.
No that would be 1 delegation. e.g. x.x.x.x.8.b.d.0.1.0.0.2.ip6.arpa
For the full /48 delegation I don't see any other option than making it part of a self service portal. But the marketing/product droids usually don't want that sort of "complex" techical stuff for retail users. Probably for good reasons...
I can see this being done completely automatically by the CPE device. It is trivial to code. It just required ISP's to *allow* it to happen. * CPE generates a RSA key pair. Stores this in non-volatile memory. [needs to be coded, no protocol work required] * CPE generates DHCP PD request which includes a "KEY-RDATA" option which contains a RSASHA256 KEY RDATA. [needs to be coded, needs code point allocated but otherwise no protocol work required] * DHCP server updates DNS server based on the prefix it is delegating and the KEY-RDATA using TSIG for authentication and responds with prefix. If this is a new PD it will clear out all the old DNS records as part of the delegation processs. If there are multiple prefixes being delegated the DNS server will be updated for all of them. [needs to be coded. uses existing protocols] * The CPE device configures the nameserver built in to it to server the reverse of the delegated prefixes. [needs to be coded, no protocol work required] * CPE device generates DNS update which delegates the reverse name space to itself and uses SIG(0) to sign the request with owner name matching the reverse of the delegated prefix. [needs to be coded, uses existing protocols] * The ISP's DNS server is configured to accept self signed requests. It examines the request. Looks at the KEY record added by the DHCP server and decides the request is valid. [exists, uses existing protocols] At this stage the reverse space has been delegated to the CPE device which can accept updates from machines within the home.
In any case: All of you should expect legitimate, technical brilliant users attempting to connect to your SMTP servers from IPv6 addresses with no PTR records. This is not going to go away. You are of course free to refuse those connections, but personally I find a that rather arrogant and pretty stupid decision. The existence of a PTR record is one of many factors to consider for your spam filter. There never has been any reason to make it an absolute requirement, and I am pretty sure the score needs to be lowered with IPv6.
Bj=C3=B8rn (yes, my mail server has a proper IPv6 reverse record, but that's only because I am in a position to create the reverse delegation....) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org