On Sunday, 6 July 2025 20:29:50 CEST Tommy Jensen wrote: > Happy Second to Last I-D Submission Day! > > This draft is short and to the point: it's time to stop accommodating > Classic DNS over UDP when writing new protocols that can use encrypted > DNS or Classic DNS over TCP instead. This draft is super short, so > please see it for my arguments. > > Thoughts? > > Thanks, > Tommy
At the risk of beating a dead horse, there is something I came across recently that I think might be relevant. So, over the last year or so, I've been building this time interface into a variety of my Arduino-like platforms (Uno, Mega, ATtiny85). And so far, I have largely been successful. I can now run a wristwatch's worth on an ATtiny85, and make it pull pins up and down within those time loops. I will likely continue this into a cluster of 2 ATtiny85 chips, communicating with an ATmega328p master to emulate a multi-core architecture. So I have the option to have that drive a MOSFET for DC loads, and have that MOSFET drive a relay for AC loads even. At that point, the IoT sky's the limit. Except for a network stack, serial only! And that brings me to the argument I want to bring here tonight. See, the ATtiny85 doesn't even support serial in hardware. The way I'm using it right now, it reallocates 2 GPIO pins to bit-bang the serial interface instead, using SoftwareSerial.h. Which is unidirectional, and as such does not even recognize any inbound responses unless single-threaded timed to do so. Which it is not. So unidirectional serial, half-duplex some might call it. Or UDP-like, because it would be shouting into the void for the most part. And that's what I actually want for these ATtiny85 chips in situ. They will have a serial interface for whenever I want to interface with them and probe their internal state. But for the most part, they will be shouting into the void. In a TCP-like infrastructure, these things will be endlessly waiting for a response, which will likely never come. That is what I think UDP-like avoids, and which for DNS is useful. A more TCP-like flow may, however, end up being more useful for a client-to-resolver setup, where otherwise timeouts of 2s would be presumed. An active denial by a suitable host on the network (either server or broadcast), could allow the client to fail-over more quickly. -- Met vriendelijke groet, Michael De Roover Mail: [email protected] Web: michael.de.roover.eu.org Activisme is pas nuttig, wanneer het kan bereiken wat het wenst te bereiken, binnen de limieten van het huidige systeem. De rest is geschiedenis. -- [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
