I am trying to evaluate the risks of allowing users to modify PTR records. 90% of them don't have a clue what a PTR record is but in my case giving access to colocation customers some of the could cause harm with the ptr records. Correct me if I'm wrong but a user can enter free form the in-addr.arpa address for their domain. Thus if the user manages domain foo.com which should point to 1.2.3.4 and my domain is bar.com pointing to 5.6.7.8 it would be quite trivial for the user of foo.com to munge the 8.7.6.5.in-addr.arpa by simply adding extra PTR records outside his control.
This is true, and I've been thinking about this.. I think the best way would be to allocate IP ranges to users, and only allow them to add PTR records for those ranges. So verify_record() would need its own permission checking in the PTR section.
I have been thinking about this for a bit and prior to using vegadns when new domains were created the SLD (foo.com or foo.co.uk) used an = record which automatically created a PTR record. With that in mind I came up with this really strange solution (read: there is probably an easier way and I'm all ears!).
A colleague of mine brought this up as well. He runs a mid-sized ISP network, and complains that it's a pain to have to add a PTR record in a separate step. I suggested perhaps adding a check box: "check here if you would like to create a matching PTR record", or something like that. It could be offered only to senior_admins, or perhaps delegated to specific users or group_admins.
This is not a high priority for me personally, since I work more in the hosting/email world, where most IPs are shared anyway. But once VegaDNS gets on its feet, I could make time to do it, as I think this could be really useful to a lot of people in the ISP world.
When creating writing the data file check for A records that are an exact match of the zone (in order to include foo.co.uk) and create them with the = data type. Additionally make the PTR record a restricted record type that is granted to specific users.
This is an interesting idea, but I'm not sure it's that necessary. The = abbreviation is intended as a shortcut, and a means of cutting down the size of the data file. But since that file is generated automatically, you're really not gaining much. Would tinydns-data run that much quicker on = instead of 2 separate records? Also, I currently group domains in the data file, so that organization would have to be re-thought.
If this seems like a good solution I will gladly work on a patch.
Go for it! I have "view logs" working now, and need to clean it up a bit. But I'll likely have 0.8 ready next week with the long overdue logging in place.
Cheers,
Bill
