Repository navigation
Querying via TCP broken #11
Description
Activity
Sorry, forgot to mention: As per RFC 5966 this library prefers UDP over TCP. TCP is only used as a fallback if either the query or the answer message do not fit into a single UDP datagram (512 bytes max).
This means that this issue does not apply to most queries. However, this can easily be reproduced by using xip.io to query an arbitrary long domain name like:
$resolver->resolve('aaaaa.bbbb....zzzzz.xip.io');Doesn't this & that already take care of it?
I believe you mean this and this? If so, I think we might have a slight misunderstanding :)
RFC 5966 demands that DNS implementations MUST support both UDP and TCP transports.
This is in fact implemented in this library as you rightfully pointed out.This library prefers UDP over TCP because it has less overhead and is therefor significantly faster.
However, due to some smaller issues listed in my initial post, the TCP implementation is completely broken and in fact completely without function.
Because this library prefers UDP over TCP, you might not notice this in normal operation. TCP is only used as a fallback if either the query or response message do not fit in a single 512 byte datagram. This can easily be reproduced as per my second post.
@clue okay I see what you are saying about UDP preference and TCP fallback.
- modified the milestone:
on Feb 24, 2016 @kelunik Yes and no :-)
No, response messages tend to be larger than request messages and certain response messages are almost certainly guaranteed to require a TCP/IP transport because a UDP message would include a fragmentation flag otherwise.
So yes, this is something that many people likely won't even notice, because normal
Amessages usually fit into a single UDP message.If a response message is received over UDP and includes a fragmentation flag, we try to retry the corresponding request over TCP/IP (which is completely broken as per this ticket).
This lib implements communication via UDP and TCP, however the TCP implementation is broken in several ways:
stream_socket_client()call to connect to the DNS server, hereConnectionfrom the react/socket (server!) component, should use react/socket-client, hereLooks like some of these points are currently being addressed as part of #8.