Hi Greg, I know PTRs are strictly 'DNS' but this seems like it belongs in the compute driver instead of the DNS driver. the implementation is going to be a bit wonky otherwise. That way you could just set PTR record for a node. Then it can lookup the public_ips from the existing field.
Ant On Wed, Nov 25, 2015 at 3:43 AM, Greg Hill <[email protected]> wrote: > I'm working on adding PTR support to the Rackspace DNS driver as an > extension. It's my understanding that not all providers offer an API for > RDNS, so I didn't think it was worth adding to the base dns driver. > Because you don't own the zone, the API endpoint is different (/rdns in the > case of Rackspace). > > My current plan is to add these methods to the rackspace dns driver: > > ex_create_ptr_record > ex_delete_ptr_record > ex_iterate_ptr_records > ex_get_ptr_record > _ex_to_ptr_record > > And the returned type will be a subclass of dns.types.Record called > RackspacePTRRecord. The primary difference is that PTR records belong to a > zone that the customer doesn't own, so the Record.zone accessor makes no > sense. I plan to make it throw an exception informing the user as such. > Alternatively I could make a fake zone record with the relevant rdns zone > name (x.x.x.in-addr.arpa), but no id, but I didn't think that was worth the > bother since it might make a user think they can just treat it like other > zones and pass it to create_record, etc. > > Since one of the things with RDNS is that they need to validate a) that > they serve RDNS for the IP in question and that b) you as a customer > actually own that IP, I have to imagine every implementation is unique. > Rackspace requires you to pass in an 'href' to the cloud server or cloud > loadbalancer, and they then do a lookup on the backend to verify that a) > your tenant owns that resource and b) the IP in question belongs to it. At > LiquidWeb (my previous employer), we did that automatically so you didn't > have to pass anything extra in, but it was still a unique API endpoint > because it was a zone the customer didn't control. > > Another related fix is that the current DNS implementation lets you > attempt to create a PTR record in your regular DNS zone, which just fails. > I was planning to alter the regular DNS provider to throw an exception if > you attempt to add a PTR record so it fails before submitting it to the API > and saves you some trouble. Should I extend this to other DNS providers as > well? I seriously doubt any of them let you attempt to add a PTR record to > a regular zone because that's not how RDNS works. > > I appreciate any input. I don't have the cycles right now to attempt to > do this for all of the supported providers, but if someone does and wants > to help out, I'd accept the help. Otherwise, maybe we can use this as an > mvp and add other driver support over time. > > Greg >
