-
-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
How to new LookupClient with old LookupClientOptions? #72
Comments
Creating an oiptions instance from settings doesn't exist because you can just keep an instance of That should work in your case too maybe? Instead of using the readonly settings of the client instance, just keep an options variable somewhere? Just out of curiosity, what are you doing with it in powershell? ;) |
Hah, yes. That would be the obvious thing I was missing. Thanks!
Got tired of waiting for MS to add a decent cross platform DNS module. So toying with making my own using DnsClient.NET so I can stop having to parse dig/nslookup output for every one-off DNS thing I need to do that's more complicated than resolving an IP from a hostname. |
Wait no, I think I'm still missing something.
In my head, the use experience I'm going for is something like this. When the module loads initially, a Resolve-Dns example.com CAA
Resolve-Dns example.com CAA -NameServer 8.8.8.8 No problem so far. We can just use # module loads with default settings using system nameservers
# user turns off recursion and makes queries
Set-DnsClientSetting -Recursion:$false
Resolve-Dns example.com CAA
# user changes default nameservers and makes additional queries
# with same client options as before
Set-DnsClientSetting -NameServer 8.8.8.8
Resolve-Dns example.com CAA
# user switches back to default nameservers
Set-DnsClientSetting -UseDefaultNameserver I suppose I could just keep a copy of the active nameserver list around and just use that via |
Ah, yeah right, forgot about that ^^ The reason for making the name servers readonly is relatively stupid. Maybe we should make it writeable. Options are supposed to be writeable. The list of servers is readonly because of the server auto discovery flag.
That would probably work, yup, but I also agree that it is not perfect ^^ |
I figured it might have been related to having the cache tied to the current nameservers. And so being able to change them would/should invalidate that cache if it exists. |
Cache is not bound to the source nameserver(s) (anymore). So that shouldn't be an issue |
In any case, yes. Having nameservers settable on the options object would definitely solve my problem. |
You can do something like this
|
I also just realized that not all of the The way I'm currently handling things in order to future proof myself is to keep an instance of The only minor downside (or feature depending on perspective) is that changing any setting empties the cache since a new |
@MichaCo I've got a basic v1 version of the module released now. Thanks again for the library and the help. |
I'm fairly new to the library, but liking it a lot so far. Thanks for the effort in maintaining it!
I'm currently playing with it directly from PowerShell and trying to figure out if there's a way to create a new instance of
LookupClient
with different nameservers, but copy the settings from my old instance. I'm trying to avoid having to create an emptyLookupClientOptions
and then copy the values to it individually from the old instance's settings.Something like a
LookupClientOptions
constructor that takes aLookupClientSettings
object....or maybe a static method likeLookupClientOptions.FromSettings()
. Is there something obvious I'm missing?P.S. I know about the
QueryServer*
methods for one-off queries against other nameservers. This would be for a more long term change.The text was updated successfully, but these errors were encountered: