[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ees0ke2g.fsf@mid.deneb.enyo.de>
Date: Sun, 03 May 2020 21:34:31 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: TCP support in the stub resolver
* Rich Felker:
>> Can't you do DNS with really large packet sizes on localhost?
>>
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
>>
>> That's the one place where TCP does not make much sense, except to get
>> the last 30 or so bytes in packet size.
>
> No, the protocol simply does not support it. Normal (non-EDNS) DNS
> protocol forbids UDP packets over 512 bytes. A nameserver that replied
> with them rather than with TC would be non-conforming and would break
> conforming clients that expect to see the TC rather than a short read.
> With EDNS0 longer packets can be sent but I think there's still a
> limit of 4096 bytes or something. I don't understand this entirely so
> I may be wrong and it may be possible to just support EDNS0 and say
> "run a server with 64k EDNS0 limit on localhost if you want to
> guarantee non-truncated replies".
On localhost, one could just disregard the protocol limit, perhaps
with special configuration of the recursive resolver. (The stub
resolver would not need configuration, it just has to accept the
packets if they arrive.)
The other option would be to use a UNIX Domain datagram socket instead
of UDP. Since it is a new transport protocol, it's possible to make
up different rules about packet sizes.
(Even on localhost, TCP has some denial-of-service issues not shared
by datagram transports, so there might be some other benefit of avoid
TCP, not just reduction in implementation complexity.)
> However, this also runs into the issue that you have to mangle the
> query (by adding OPT to it) and get back a response that's not going
> to look like what the application requested (since it has extra OPT,
> etc. in it) unless you do the work to reverse that and reformat the
> response to look like what the application would have received if it
> were using normal DNS protocol over TCP. So it's probably *more*
> unwanted complexity and bug surface to do this right, even if it is
> possible...
True, if query mangling is required *and* TCP fallback is needed in
some cases, there is little incentive to do this from a complexity
point of view.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
