Header id mismatch on Windows Subsystem for Linux #79
Comments
|
Hi @sipsorcery Do you have any DNS proxy or anything else custom? Might be very much related to your DNS server not returning valid results. |
|
Thx for taking a look. My Windows DNS config is: WSL uses some kind of virtual network interface and sends all DNS requests through a gateway, in my case Perhaps this "forking" of the DNS queries causes the duplicate headers? Here's the packet capture of both my WSL and Ethernet interfaces. The
Sigh, I've spent so much time attempting to get a grip on Task Asynchronous Programming and still struggle. I realise it's not part of the DNS problem but any chance you could elaborate to help my understanding? Do you mean that I should use |
|
If that really forks the DNS request then yes, that could be the issue. I have no idea why WSL would do that though, I'll might try to research it a bit, seems strange. Regarding your async sync code, maybe this helps, I rewrote it primarily to fix the secondary call. using System;
using System.Linq;
using System.Net;
using System.Threading.Tasks;
using DnsClient;
using DnsClient.Protocol;
namespace DnsClientConsole
{
internal class Program
{
private static async Task Main()
{
Console.WriteLine("DNS Test");
LookupClientOptions opts = new LookupClientOptions(NameServer.GooglePublicDnsIPv6)
{
Retries = 1,
Timeout = TimeSpan.FromSeconds(1),
UseCache = false,
};
var lookup = new LookupClient(opts);
string hostname = "google.com";
int defaultPort = 5060;
QueryType queryType = QueryType.AAAA;
try
{
var result = await lookup.ResolveServiceAsync(hostname, "stun", "udp");
if (result.Count() == 0)
{
Console.WriteLine($"Dns SRV lookup returned no results for {hostname}.");
}
var srvResult = result.OrderBy(y => y.Priority).ThenByDescending(w => w.Weight).FirstOrDefault();
IPEndPoint endPoint;
if (srvResult != null)
{
Console.WriteLine($"Using SRV result: {srvResult}");
endPoint = await HostQuery(lookup, srvResult.HostName, srvResult.Port, queryType).ConfigureAwait(false);
}
else
{
endPoint = await HostQuery(lookup, hostname, defaultPort, queryType);
}
Console.WriteLine($"Result: {endPoint}.");
}
catch (Exception ex)
{
Console.WriteLine($"Dns SRV lookup failure for {hostname}. {ex.InnerException?.Message ?? ex.Message}");
}
}
/// <summary>
/// Attempts to resolve a hostname.
/// </summary>
/// <param name="host">The hostname to resolve.</param>
/// <param name="port">The service port to use in the end pint result (not used for the lookup).</param>
/// <param name="queryType">The lookup query type, either A or AAAA.</param>
/// <returns>If successful an IPEndPoint or null if not.</returns>
private static async Task<IPEndPoint> HostQuery(LookupClient lookup, string host, int port, QueryType queryType)
{
try
{
var addrRecord = (await lookup.QueryAsync(host, queryType).ConfigureAwait(false))
.Answers
.FirstOrDefault();
if (addrRecord != null)
{
return GetFromLookupResult(addrRecord, port);
}
}
catch (Exception excp)
{
Console.WriteLine($"Dns lookup failure for {host} and query {queryType}. {excp.Message}");
}
if (queryType == QueryType.AAAA)
{
return await HostQuery(lookup, host, port, QueryType.A);
}
return null;
}
private static IPEndPoint GetFromLookupResult(DnsResourceRecord addrRecord, int port)
{
if (addrRecord is AddressRecord addressRecord)
{
return new IPEndPoint(addressRecord.Address, port);
}
return null;
}
}
} |
|
I might change the behavior of the library to log a warning instead of throwing a hard error in that case. I anyone has a strong opinion on this let me know |
|
+1 for the warning instead of exception. |
|
This is closed however 1.4.0 isn't released yet. I'm seeing this same error using the AWS Lambda .NET Core 2.1 runtime which uses Linux. Have multiple threads using the same LookupClient instance, as recommended. @MichaCo Any closer to understanding what the issue is here and whether just having a warning here is safe? If I upgrade to 1.4.0 will I be getting the wrong DNS response for my queries? |
|
Well, in the cases reported, there was another layer between my UDP request and the server altering the original DNS request. In general, the assumption is that you'd not get a different/wrong response for the same question anyways. Its just odd that you'd get a cached or different response with a different ID. Checking the request ID is more a guard check and cannot really be trusted, or used as a security check, anyways. That's why I think making it a warning should be fine. Yeah 1.4 is still not release, just came back from vacation - happy new year! |
|
Happy New Year to you too! The other potentially important factor is that I'm using TCP rather than UDP there's this outstanding issue about Socket thread-safety for TCP on Linux... dotnet/runtime#44422 I haven't dug into the DnsClient code enough to know how it's working with sockets under the hood but is it possible this is related? |
|
Could be related. Not sure. |
|
It ends up in a I don't think it's exactly the same (especially as it's async rather than sync) but from some other comments where we people are talking about the SocketAsyncContext and some more low level stuff it sounds like it may be related. That said I am surprised that we're consistently getting that same error and, if it is randomly interleaving sent and received packets, that it doesn't fail with more variety of error messages. I'll dig into our logs further I think and maybe try the workaround of putting a big |
I use the
ResolveServiceAsyncmethod extensively for SIP and STUN service lookup (big thanks for providing such a clean approach).The issue I've noticed is that on WSL I get
Header id mismatchexceptions when attempting lookups. If I use the same code on Windows I don't get the exception. It's possible/likely that a bigger factor is the different DNS configurations on my Windows machine compared to the WSL VM.I'm using the
DnsClientnuget package v1.3.2. Below is a sample program that generates the exception for me.Windows Output:
WSL Output:
The text was updated successfully, but these errors were encountered: