On Tue, Dec 15, 2015 at 6:07 PM, Mark Andrews <marka@xxxxxxx> wrote: > RFC 1123 said DNS/TCP is a SHOULD. Most of the name servers in the > world actually implemented DNS/TCP. All the stub resolvers in the world > actually implemented DNS/TCP. > > The problem is that a myth grew up that DNS/TCP was only for AXFR so > people configured firewalls to block DNS/TCP as a way of blocking AXFR. > > And there are others that turned the SHOULD into MAY when reading RFC > 1123. > > There were also a few CPE vendors that appear to have not read RFC 1123 > because if they had I fail to see how they can justify not supporting DNS/TCP. > > Then there are idiotic CPE vendors like the one below that outright lie to > DNS/TCP queries. No where does any RFC permit that. This gets back to the earlier discussion on 'red lines'. DNS was designed in a different age, at a time when nobody knew what they were doing because it was research. Some architectural principles I draw from the design of the DNS are: 1) The architecture anticipated the use of local resolvers at an early stage, the protocol should have reflected this. The client-resolver protocol should have been considered separately from the resolver-authoritative protocol. 2) Don't expect a protocol to be able to use TCP as fallback for UDP. Pick one or the other. 3) When using UDP to a stateless server, requests cannot be longer than a single packet but multipacket responses are possible. 4) Don't put arbitrary size limitations in specifications. Yes, having users really sucks. They do things to suit their particular needs and then they expect future protocol changes to support their activities. The only thing worse than having users is not having users.