dropped malformed message waiting for id: 45650 err: unexpected end of input reached
dropped malformed message waiting for id: 26004 err: unexpected end of input reached
dropped malformed message waiting for id: 35252 err: unexpected end of input reached
dropped malformed message waiting for id: 33116 err: unexpected end of input reached

Do you see these error messages with exactly the above example, or do you modify the URL part?

If I ran the first example, I saw the errors like:

$ deno -A a.ts
2025-01-15T07:57:35.165Z Request failed with status code 404
2025-01-15T07:57:35.169Z Request failed with status code 404
2025-01-15T07:57:35.169Z Request failed with status code 404
2025-01-15T07:57:35.169Z Request failed with status code 404
2025-01-15T07:57:35.169Z Request failed with status code 404
2025-01-15T07:57:36.542Z Request failed with status code 404
2025-01-15T07:57:36.544Z Request failed with status code 404

which is the same as what Node.js shows.

Second case (I discovered this by accident):

This case seems a regression in 2.1.5. I'll work on it.

Note: We changed the internal implementation of Node compat http(s).request in 2.1.5 (#25470). In the new implementation we started using dns.lookup for resolving domain names, and this is probably related to it.

I guess probably our dns resolver (It internally uses Deno.resolveDns which internally uses hickory-dns) is now too strict about handling dns data.

The error message is likely from here https://github.com/hickory-dns/hickory-dns/blob/b942d68020ee6f88bbd459812c5fab22b748413c/crates/proto/src/udp/udp_client_stream.rs#L318

@kt3k for the first case - yeah, I see errors in the console with that exact code. It takes some time to get them though, a few seconds perhaps. This is what dig returns for that domain:

test.openai.azure.com.  900     IN      CNAME   koreacentral.api.cognitive.microsoft.com.
koreacentral.api.cognitive.microsoft.com. 3600 IN CNAME cognitivekcprod.trafficmanager.net.
cognitivekcprod.trafficmanager.net. 30 IN CNAME cognitivekcprod.azure-api.net.
cognitivekcprod.azure-api.net. 900 IN   CNAME   apimgmttm6jlrkljhsnxfyj4ybmjxuinaoxgxjlz8tpdomzoya.trafficmanager.net.
apimgmttm6jlrkljhsnxfyj4ybmjxuinaoxgxjlz8tpdomzoya.trafficmanager.net. 300 IN CNAME cognitivekcprod-koreacentral-01.regional.azure-api.net.
cognitivekcprod-koreacentral-01.regional.azure-api.net. 900 IN CNAME apie98ecb42422c43a49d717dbbb805352ekhsube4o75jbgtwcyzkxp.koreacentral.cloudapp.azure.com.
apie98ecb42422c43a49d717dbbb805352ekhsube4o75jbgtwcyzkxp.koreacentral.cloudapp.azure.com. 10 IN A 20.194.72.197

Do you see the same error (dropped malformed message waiting for id: 45650 err: unexpected end of input reached) when executing the below script?

console.log(await Deno.resolveDns("test.openai.azure.com.", "A"));

Hmm, no, if I do this (even in a loop or multiple concurrent ones), it's all fine. Is there a way I can understand why I'm getting all those console errors? I could build Deno if needed

Sounds very strange situation to me..

axios uses node:https.request which uses node:dns.lookup which uses Deno.resolveDns. So can you also check if the issue reproduces with the below scripts? (This should narrow where the issue exists)

import dns from "node:dns"
dns.lookup("test.openai.azure.com", console.log);

import https from "node:https"
https.request("https://test.openai.azure.com", console.log).end()

Yeah, I get the error with the first snippet, but it's inconsistent. Sometimes it just gives the IP straight away, sometimes it does this:

dropped malformed message waiting for id: 62340 err: unexpected end of input reached
dropped malformed message waiting for id: 24232 err: unexpected end of input reached
null 20.194.72.197 4

Thanks for the replies!

This issue might be related to hickory-dns/hickory-dns#2140

Do you know if the size of the response from the name server in your environment exceeds 512 bytes? Can you share the full result of dig test.openai.azure.com A and dig test.openai.azure.com AAAA? (These should include the actual message sizes)

I'll try to reproduce the issue by simulating the name server with large response

Yep, nevermind, @kt3k you don't need to care about the first part - apparently for some really weird reason my router defaulted to 4096 max udp packet size for DNS, and it worked so far for years in every software on every OS, but I guess that Rust crate is really strict to the spec :) I set it to 500 and it works fine now.

Thanks for the further inputs!

It's interesting to see that changing the router settings fixes the issue.

it worked so far for years in every software on every OS, but I guess that Rust crate is really strict to the spec

I'm not completely sure if we should ignore larger DNS packet sizes when they work on most OSes and software..

I was able to reproduce the issue (of hickory-dns) by the below script:

import dns2 from "npm:dns2";
const { Packet } = dns2;
const server = dns2.createServer({
  udp: true,
  handle(request, send) {
    const response = Packet.createResponseFromRequest(request);
    const { name } = request.questions[0];
    for (const i of [...Array(256).keys()]) {
      response.answers.push({
        name,
        type: Packet.TYPE.A,
        class: Packet.CLASS.IN,
        ttl: 300,
        address: "1.2.3." + i,
      });
    }
    send(response);
  },
});
server.listen({ udp: { port: 5333, address: "127.0.0.1", type: "udp4" } });

setTimeout(() => {
  Deno.resolveDns("example.com", "A", {
    nameServer: { ipAddr: "127.0.0.1", port: 5333 },
  });
});

The DNS server returns large result of 6941 bytes. Deno.resolveDns never resolves, and it keeps showing dropped malformed message warning messages.