Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

New Feature: ContinueOnEmptyResponse setting #64

Closed
MichaCo opened this issue Mar 14, 2020 · 0 comments
Closed

New Feature: ContinueOnEmptyResponse setting #64

MichaCo opened this issue Mar 14, 2020 · 0 comments

Comments

@MichaCo
Copy link
Owner

MichaCo commented Mar 14, 2020

In version 1.2.0, LookupClient stops querying any other server in case the response was valid.
Valid responses are any responses without an error code. (Error responses might be retried, depending on configuration...)

But a no-error response might have zero answers, which can have many reasons.
It is very likely that every DNS server in your network will return the same empty response, but there are some network configurations where DnsClient will auto-resolve servers from multiple network adapters which might not return the same result.
So, it might make sense to try the other servers anyways.

Starting with version 1.3.0 of DnsClient, LookupClient will now try to find an answer from all configured DNS servers (per default).

The logic here is relatively simple:

  • If the question is answered, return the response, as usual.
  • If no other servers are available, return the empty response
  • If there are other servers
    • and no answers are in the response, try the next server
    • and there are answers in the response but they are not matching the question, try the next server.
      (this part is ignored if the question is either ANY or AXFR)

The behavior can be disabled with a new setting called ContinueOnEmptyResponse.

I don't think this will change anything for most use-cases, as most setups usually just resolve one NameServer anyways, like in most VMs or containers.

Example

dotnet run -f netcoreapp3.1 --time 10000 --tries 0 -s 192.168.0.2 -s 8.8.8.8 -s 8.8.4.4 abc

Log output

DnsClient Verbose: 1 : [LookupClient] Begin query [59669 - Qs: 1 Recursion: True OpCode: Query] via UDP => abc IN A on [8.8.4.4:53, 192.168.0.2:53, 8.8.8.8:53].
DnsClient Verbose: 2 : [LookupClient] TryResolve 59669 via UDP => abc IN A on 8.8.4.4:53, try 1/1.
DnsClient Verbose: 10 : [LookupClient] Got 0 answers for query 59669 via UDP => abc IN A from 8.8.4.4:53.
DnsClient Information: 12 : [LookupClient] Got no answer for query 59669 via UDP => abc IN A from 8.8.4.4:53. Trying next server.

DnsClient Verbose: 2 : [LookupClient] TryResolve 4589 via UDP => abc IN A on 192.168.0.2:53, try 1/1.
DnsClient Verbose: 10 : [LookupClient] Got 0 answers for query 4589 via UDP => abc IN A from 192.168.0.2:53.
DnsClient Information: 12 : [LookupClient] Got no answer for query 4589 via UDP => abc IN A from 192.168.0.2:53. Trying next server.

DnsClient Verbose: 2 : [LookupClient] TryResolve 16265 via UDP => abc IN A on 8.8.8.8:53, try 1/1.
DnsClient Verbose: 10 : [LookupClient] Got 0 answers for query 16265 via UDP => abc IN A from 8.8.8.8:53.

Result

; <<>> MiniDiG 1.0.0.0 Microsoft Windows 10.0.18363 <<>> --time 10000 --tries 0 -s 192.168.0.2 -s 8.8.8.8 -s 8.8.4.4 abc
; Servers: 192.168.0.2:53, 8.8.8.8:53, 8.8.4.4:53

...

; (3 server found)
;; Got answer:
;; ->>HEADER<<- opcode: Query, status: No Error, id: 53991
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512; code: NoError
;; QUESTION SECTION:
abc.                                    IN      A

;; AUTHORITIES SECTION:
abc.                                    92      IN      SOA     ac1.nstld.com. info.verisign-grs.com. 1584144303 1800 900 604800 86400

;; Query time: 24 msec
;; SERVER: 8.8.8.8#53
;; WHEN: Sat Mar 14 00:33:53 Z 2020
;; MSG SIZE  rcvd: 99
@MichaCo MichaCo added this to the 1.3.0 milestone Mar 14, 2020
@MichaCo MichaCo self-assigned this Mar 14, 2020
MichaCo added a commit that referenced this issue Mar 14, 2020
+ some other cleanup and fixes
+ decided to pull in a better implementation of StringBuilderObjectPool. There was one edge case breaking only in one very specific benchmark
MichaCo added a commit that referenced this issue Mar 14, 2020
* changed how opt records are created and used. Added configuration to disable EDNS and to set the requested buffer size and DnsSec
* Changes the behavior in case of bad responses which were truncated by some middleman proxy or router - fixes #52
* Changing default unknown record handling to preserve the original data so that users can work with those records.
* Reworking error handling see #60
* Adding new setting ContinueOnEmptyResponse #64
@MichaCo MichaCo closed this as completed Jun 20, 2021
Repository owner locked and limited conversation to collaborators Jun 20, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

1 participant