Closed thomaseizinger closed 2 weeks ago
What you have highlighted is the EDNS0 buffer size, not what transport it used. It's sometimes referred to as "UDP size", "UDP message size" etc.
You can see transport under "proto".
Okay, something is still not quite working though. I am only just now implementing TCP support for my resolver and wanted to test that.
If I run check-my-dns on my Android phone with the VPN that I am developing active (that cannot yet do DNS over TCP), I expected all the TCP queries to fail. But they don't. Check-my-DNS says it is working. This is on Firefox for Android.
If I use this app to test it and forcs TCP DNS, it times out (as expected).
Is this a limitation for Firefox for Android not respecting the DNS servers? Any clues?
Have you checked that Firefox doesn't use DoH servers?
In the screenshot you can also see where the queries comes from and those IPs look like Google's DNS resolver cluster.
Check My DNS can only test the last resolver on your path, if your resolver forwards queries then it's not your resolver that gets tested.
BTW: I highly recommend NOT developing your own resolver :) DNS is not as easy as you may think, better to use getdnsapi
, libunbound
or other libraries.
Have you checked that Firefox doesn't use DoH servers?
I'll check.
In the screenshot you can also see where the queries comes from and those IPs look like Google's DNS resolver cluster.
Check My DNS can only test the last resolver on your path, if your resolver forwards queries then it's not your resolver that gets tested.
My resolver does forward queries, yes! Every DNS server on the system gets replaced with a proxy IP and then the VPN app intercepts the DNS queries sent to them, answered some and forwards other to the original resolver.
How does Check My DNS test TCP queries? By forcing a fallback with the truncated bit?
How does Check My DNS test TCP queries? By forcing a fallback with the truncated bit?
It sets the TC bit yes, but you will never see that if you forward since then the upstream resolver will do all the work.
How does Check My DNS test TCP queries? By forcing a fallback with the truncated bit?
It sets the TC bit yes, but you will never see that if you forward since then the upstream resolver will do all the work.
Well, but the response is still truncated, right? So shouldn't it set the TC bit in the UDP response back to me?
So shouldn't it set the TC bit in the UDP response back to me?
No, that's not how DNS works.
In this context, your "resolver" is a client and it asks the upstream to resolve for it.
So shouldn't it set the TC bit in the UDP response back to me?
No, that's not how DNS works.
In this context, your "resolver" is a client and it asks the upstream to resolve for it.
Right and I guess the final response served to my resolver fits into a UDP packet, and thus the TC bit isn't set?
So to force the very first client to retry over TCP, the response to the initial query needs to exceed the UDP size, thus forcing the resolver that is serving my resolver to set the TC bit.
Would it make sense for Check My DNS to support such a scenario?
Right and I guess the final response served to my resolver fits into a UDP packet, and thus the TC bit isn't set?
No.
First off, you do not have a resolver. You have only made a forwarder.
You forward your query to the upstream resolver and it will try it utmost to give you an answer - that's its job!
So to force the very first client to retry over TCP, the response to the initial query needs to exceed the UDP size, thus forcing the resolver that is serving my resolver to set the TC bit.
Would it make sense for Check My DNS to support such a scenario?
No, because the upstream resolver will retry over TCP to get the answer and it will construct an answer back to your forwarder that fit within that transport.
It's job is to give you an answer, not a carbon copy of what ever it received.
Thank you for explaining this. I have one more question if you don't mind :)
The thing that doesn't want to click for me is:
example.com
example.com
If that is the case, wouldn't it be possible to construct such records and thus force TCP DNS all the way to client?
If you're aim is to ensure TCP is used for every communication in every layer, no - you can't do that as a forwarder.
If you are looking to ensure you have an authenticated answer you need to implement DNSSEC and do client side validation.
My aim is for my forwarder to be correct and as transparent as possible whilst being able to intercept some queries. I was looking for a tool to test that with and thought Check My DNS kind of fits the bill here!
I guess my question now is, do you think it makes sense to extend the tests that Check My DNS is making such that it also tests whether the end-user client correctly falls back to TCP for truncated responses?
If I understand correctly, that is what this situation can be reduced too. The presence of my forwarder doesn't really matter, because even if it is not active, the way Check My DNS is currently implemented means that TCP DNS is only tested upstream from the resolver that I am using, but never between my client and the configured resolver. Is that correct?
On Wed, 9 Oct 2024, 22:14 Thomas Eizinger, @.***> wrote:
I guess my question now is, do you think it makes sense to extend the tests that Check My DNS is making such that it also tests whether the end-user client correctly falls back to TCP for truncated responses?
No.
If I understand correctly, that is what this situation can be reduced too. The presence of my forwarder doesn't really matter, because even if it is not active, the way Check My DNS is currently implemented means that TCP DNS is only tested upstream from the resolver that I am using, but never between my client and my resolver. Is that correct?
Yes.
First off, thank you for making this great tool! It is pretty much exactly what I need to test my resolver! I did however notice that the TCP test seems to be not quite working? In particular, it doesn't seem to force TCP and when reproducing the query locally with dig, it just succeeds over UDP.
The UDP queries prior to that one also succeed and don't seem to have the TC bit set.