Closed DrProbie closed 3 years ago
Hi @DrProbie - it's on my ever-growing To-Do list! Therefore, if you're happy to implement these, then go for it 👍
Fine...! I'll start with one, follow it all the way through then move on... :)
That's the spirit and a good plan! There may be some discussion/comments about coding style and test implementation etc. on the first commit. However, once you've got that nailed down, the rest should be easy 😉
I'll do my best to nail that one on the first, but you know how it is...! :D
@DrProbie Have you had a chance to look at adding these additional record types?
Only briefly, been waiting for the more quiet summertime that now is upon us… So I expect to start doing something serious about it now in July. Are you looking for something to do…? ☺
Mvh/Jonni
From: Iain Brighton [mailto:notifications@github.com] Sent: tirsdag 5. juli 2016 13.48 To: PowerShell/xDnsServer xDnsServer@noreply.github.com Cc: Jon Agust Reynisson jar@provendo.no; Mention mention@noreply.github.com Subject: Re: [PowerShell/xDnsServer] More DNS record types (#34)
@DrProbiehttps://github.com/DrProbie Have you had a chance to look at adding these additional record types?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/PowerShell/xDnsServer/issues/34#issuecomment-230456975, or mute the threadhttps://github.com/notifications/unsubscribe/AQq_Mn5JbK5arZG7JZPpTGGB21FHRck8ks5qSkSKgaJpZM4IpZDC.
PTR is being worked on in PR #60. The other should be added as well. I will relabel this as Help Wanted, so that someone in the community can run with this.
I would am going to take over this issue, but I strongly disagree with, and will not be continuing the approach established here:
This will lead to having an incredibly large, complex, resource that must either rely on text parsing or redundant properties to expose the myriad of different record types.
I will be creating a PR containing resources for individual record types again, these will share a common "helper" to handle aspects that are common (such as TTL).
I propose MSFT_xDnsRecord be deprecated and MSFT_xDnsARecord returned to service (with perhaps some cleaning up).
Cheers,
Chris
@1800Zeta Moving this conversation here for consistency.
I am not a fan of the proposal to merge all record types under DNSRecord.
A minimum useful set of supported record types should consist of A (done), AAAA, CNAME, NS, MX, and TXT. SOA and SVR might be included as well. Attempting to merge all of these under a single resource adds an unnecessary degree of complexity to a single resource.
DnsARecord looks like it might be a suitable starting point but it has a number of flaws.
And probably a few more. I have some private DSC resources for configuring DNS record types. I was going to port these over to this module (they're class-based resources at the moment).
Which record types did you need initially?
Thank you @indented-automation
I think we need SRV and A records initially. Looking at the Add-DnsServerResourceRecord cmdlet I think you might be right and it would be worth keeping to a smaller subset. Would it be a case of create xDnsARecord, xDnsAAARecord, xDnsMXRecord etc?
That's my opinion on it, yes.
For the class-based resources I have they all inherit from a common parent which implements most of the checks and functionality. A helper module in the script-based resource world essentially.
It's too hot here to plot out that change today. If you're happy to wait a few more days I'll re-implement what I have in the scope of this module. My resources cover A, CNAME, NS, and PTR at the moment.
I envisage the A record resource would accept something like the following (scribbled a bit):
[Parameter()]
[ValidateSet('Present', 'Absent')]
[String]$Ensure = 'Present',
# The name of the resource record, relative to the zone name.
#
# If the resource record should be created at the zone apex, the Name parameter should be set to a period.
#
# Key
[Parameter(Mandatory = $true)]
[String]$Name,
# Zone name
#
# Key
[Parameter(Mandatory = $true)]
[String]$ZoneName,
# A list of IP addresses, an A record will be created for each IP address. IPAddress is mandatory when Ensure is Present.
[Parameter()]
[String[]]$IPAddress,
# The time to live for the record. If the TTL is set to 0, the default TTL for the zone will be used.
[Parameter()]
[ValidateRange(1, 4294967295)]
[Int64]$TTL,
# Indicates that all A records the specified name should be replaced by this record or set of records.
[Parameter()]
[Boolean]$ReplaceRecordSet = $false
The challenge is that while IP addresses are easy to list, this does not fit so well for SRV records without an embedded instance. In that case Key is much harder to define.
Thank you @indented-automation I am more than happy to wait a few days and see what's what.
There was a resource added xDnsRecord a while back. If this issue is not covered by that resource, please comment on or re-open this issue.
@johlju The xDnsRecord resource does not support all the record types listed in this issue. One I'm specifically interested in is MX records.
Reopening this issue so community can work on the goal that was discussed, splitting up xDnsRecord into several resources. The old xDnsARecord that was deprecated with xDnsServer was removed when the module was converted to the new pipeline. If the code from xDnsARecord is of any help it is available in the 1.16.0.0 version in PowerShell Gallery.
@jcuzzi please contribute a new resource DnsRecordMx
if you have the opportunity. 🙂
Suggest resource names DnsRecordA
, DnsRecordMx
, DnsRecordAAA
, etc.
Reopening this since I thing there are more resources that need to be added before closing this. Or split up this issue into separate issues.
Merged so far:
Closing this issue sine @Sudman1 have opened new resource proposal issues for each record that. Thank you! 🙇
Hi there...
This module is excellent to work with - as far as it goes.
I wish to see at least support for SRV, MX, PTR and AAAA records come in soon. It would make it so much more useful for me.
If nobody else is half ways or more with it, I'd like to give it a shot. After reading through the discussions under Pull request #14, I agree with the approach to keep the record management in one resource, and in line with Add-DnsServerResourceRecord.
If there are no comments, I'll go ahead and implement, and then take the heat from the Pull request.