DNS suffix isn't being honored on Linux

[toddschilling]

It appears that the DNS search suffix in the resolv.conf file isn't being appended to the hostname during query. I can see that the source code has a parser for it but didn't see any obvious places where it was being used.

[MichaCo]

No, I'm not doing that and also not reading the configuration if available. Same as dig doesn't do it per default. You'd have to explicitly add +search I think.

Could be a configuration option for the ILookupClient maybe. Not sure though what exactly I'd have to do to retrieve it and what the behavior on other platforms would be?

Also, the Linux specific code I have there right now for is meant to be removed. I added because there were a few bugs in .NET Core 1.0.0 which might be fixed now. Not sure if GetAllNetworkInterfaces is working fine now on all platforms on .NET Core 1.1.0... At least UWP is still not implemented I think.

[toddschilling]

Got it. +search definitely would be nice to have. I can compensate in the meantime by handling my specific case in a wrapper. If I get spare time I might try to assist and open a PR.

BTW..the last issue is working quite nicely now. ty!

[MichaCo]

Sure go ahead, happy to accept PRs ;)

[ingenthr]

Found this issue after some debugging. One challenge here is that running a dotnet-core app under Kubernetes, one doesn't necessarily know their search paths. If it was there as a configuration option to explicitly pass these in, we wouldn't (necessarily) know what to pass in. Some method of honoring the resolv.conf would be useful.

[MichaCo]

@ingenthr @toddschilling I just added DnsSuffix to my NameServer type, if a network adapter has a DnsSuffix set, that property should be set, too.

I might not build anything which uses that automatically with each .Query call though because it is not that easy to determine if the suffix should be appended.
There is an example in DigCommand in the sample app of how to use it. Basically it checks if the query has only one label (typical for just a hostname) and the query doesn't end with Dot. In that case you can now just concat the 2 DnsStrings with + and query that.
That's I think basically how NSLookup works.

Tested that on Ubuntu, at least under .NET5 QueryNetworkInterfaces returns DnsSuffixs, too, which is used by this library if you don't pass in any NameServers.

see #122

[mateuszdrab]

I think I just got affected by the same issue.
I've been using the DnsClient-PS PowerShell module to query the endpoints in a K8s pod and I notice the query fails with the following:

Resolve-Dns speedtest-node-backend

NameServer   : 10.43.0.10:53
Additionals  : {.}
AllRecords   : {.}
AuditTrail   :
Answers      : {}
Authorities  : {}
ErrorMessage : Server Failure
HasError     : True
Header       : ;; ->>HEADER<<- opcode: Query, status: Server Failure, id: 19790
               ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
Questions    : {speedtest-node-backend. IN A}
MessageSize  : 51
Settings     : DnsClient.LookupClientSettings

I worked around it by specifying the FQDN, however it would be nice if the search-domains from /etc/resolv.conf were respected