There is no ability to manipulate sub-delegation NS records via Fog (tested with Route 53)

[CpuID]

Due to the behaviour in lib/fog/aws/models/dns/records.rb on Line 37:

36 # leave out the default, read only records
37 data = data['ResourceRecordSets'].reject {|record| ['NS', 'SOA'].include?(record['Type'])}

We do not return any NS or SOA records in record lookups. We also can't do a record.find() and a destroy on the resulting object because of this.

This possibly makes sense for the NS and SOA record/s for the zone itself, but sometimes you have NS records in a zone for a subdomain, to perform delegation.

Please provide such a capability, thanks.

[geemus]

@CpuID thanks for the detailed description. I would certainly welcome this fix and would be happy to help you work on it if you need this functionality. Otherwise we will try to fix it, but it might be a little while before we get to it. Thanks!

[CpuID]

No problem :)

I don't mind taking a stab at this one if you want, I just need some clarification on some of the fog internals across other providers etc.

Is this NS/SOA behaviour standardised across all providers? I suspect it may be.
It would be quite easy to perform a lookup when doing the exclusion I guess within lib/fog/aws/models/dns/records.rb to check if the Record/RRSet Name matches the zone name, if not allow it to be added to the list. Thoughts?

[geemus]

@CpuID - I wouldn't say this is standard (none of the other providers include these by default/in the first place, that I'm aware of). Doing something like you describe (to weed out the default ones, which just seem like noise to me at least) sounds reasonable.

[CpuID]

After looking at it, these NS/SOA records are not completely read only in the Route 53 Console. You can't modify the type for them, but you can modify the values and TTLs respectively.

@geemus thoughts on just removing that line 37 altogether?

[geemus]

@CpuID - that is probably fine. I didn't really think that they were very relevant or changeable, so I hid them for simplicity at the time. But if we need them, we might as well just include them I suppose. Sound like a plan?

[CpuID]

sounds good to me - PR ready for inclusion :)

[geemus]

closed by above

[rhenning]

@geemus @CpuID Hi gents. We've noticed that this behavior of pruning NS & SOA records from the list of records in reponses is reflected in some other providers as well (Dyn in our case). Thoughts on removing the reject of NS & SOA across the board? Our use case is similar to the one @CpuID mentioned: Look up a record by name and use the value of its NS records to determine if it is delegated to another nameserver. If not, potentially create a new NS record to delegate it. I'm happy to work a pull request if you think the proposal is appropriate. Thanks.

https://github.com/fog/fog/blob/master/lib/fog/dynect/models/dns/records.rb#L17

[CpuID]

Seems plausible here, deferring to @geemus for a definitive answer :)

Nathan Sullivan
Sent from a mobile device

On 22 Apr 2015, at 9:21 pm, Richard Henning notifications@github.com wrote:

@geemus @CpuID Hi gents. We've noticed that this behavior of pruning NS & SOA records from the list of records in reponses is reflected in some other providers as well (Dyn in our case). Thoughts on removing the reject of NS & SOA across the board? Our use case is similar to the one @CpuID mentioned: Look up a record by name and use the value of its NS records to determine if it is delegated to another nameserver. If not, potentially create a new NS record to delegate it. I'm happy to work a pull request if you think the proposal is appropriate. Thanks.

—
Reply to this email directly or view it on GitHub.

[geemus]

@rhenning sounds good, just let me know if I can assist. Thanks!