Describe the bug
Querying for SRV or TXT records (the ones most likely to exceed the UDP packet size of 512 bytes), inet_res:getbyname/2 returns {:error, :nxdomain} when it should not - nslookup on the same server returns results correctly.
According to the docs on name resolving, " If the query is too large for UDP, TCP is used instead." I do not see this working as expected.
To Reproduce
(Apologies: I'm using iex from Elixir side, but the same should work in Erlang)
Assuming you have a large TXT DNS entry at a domain:
:inet_res.getbyname(~c"example.com", :txt)
{:error, :nxdomain}
(If you have no such entry readily available, contact me directly and I'll provide you a concrete example.)
On the same server, running nslookup -type=TXT example.com returns results as expected.
To verify that this is a UDP issue, and that UDP is not falling back to TCP, on the same server I can run the following just fine:
# set a larger UDP packet size
:inet_res.getbyname(~c"example.com", :txt, [udp_payload_size: 4096, edns: 0], :infinity)
{:ok,
{:hostent, ~c"example.com", [], :txt, 8, [...]
}}
# use TCP only
:inet_res.getbyname(~c"example.com", :txt, [usevc: true], :infinity)
{:ok,
{:hostent, ~c"example.com", [], :txt, 8, [...]
}}
Expected behavior
A clear and concise description of what you expected to happen.
I would expect an {:ok, {:hostent, ... response with the DNS record's contents.
Affected versions
This is present in OTP 28.5. I did not test in 28.4.
It is not present in 28.3.
Describe the bug
Querying for SRV or TXT records (the ones most likely to exceed the UDP packet size of 512 bytes),
inet_res:getbyname/2returns{:error, :nxdomain}when it should not -nslookupon the same server returns results correctly.According to the docs on name resolving, " If the query is too large for UDP, TCP is used instead." I do not see this working as expected.
To Reproduce
(Apologies: I'm using
iexfrom Elixir side, but the same should work in Erlang)Assuming you have a large TXT DNS entry at a domain:
(If you have no such entry readily available, contact me directly and I'll provide you a concrete example.)
On the same server, running
nslookup -type=TXT example.comreturns results as expected.To verify that this is a UDP issue, and that UDP is not falling back to TCP, on the same server I can run the following just fine:
Expected behavior
A clear and concise description of what you expected to happen.
I would expect an
{:ok, {:hostent, ...response with the DNS record's contents.Affected versions
This is present in OTP 28.5. I did not test in 28.4.
It is not present in 28.3.