Little late for the QnA but here it is. DNS is often fetched by intermediate servers. Your system is configured to use say 192.168.1.1 (your router), which in turn uses your ISP's DNS, which in-turn could be using n number of intermediate DNS servers. DNS is also cached, and TTL is sometimes not respected by intermediaries. Even if TTL was respected, due to the dynamic nature of requests and responses the caching mechanism in the intermediate DNS servers are going to be overwhelmed. All these systems would be designed with assumption that responses are short, TXT queries are rare, records, especially potentially long ones like TXT are not going to change that often. The whole caching mechanism will be optimized for the "normal" DNS use case. So widespread adoption of this technique could cause some chaos.
DNS as efficient as it may, is still an application layer protocol. So it's still an abstraction over UDP, and not only do DNS servers treat it as such, like caching results etc, but the whole "no need to install a client to use this service" is counterintuitive to the data efficiency argument. Your own application layer program, is still the most efficient possible protocol there can be. So by just writing something as simple as a bash script or a powershell script, whose whole job is to send a udp datagram of a string without newlines to a server you host, is still the most efficient way to have a highly efficient service
Yes technically , this could be done but , but this still feels really cool. Though udp is unreliable , we could probably use something like reliable udp but IDK
Little late for the QnA but here it is. DNS is often fetched by intermediate servers. Your system is configured to use say 192.168.1.1 (your router), which in turn uses your ISP's DNS, which in-turn could be using n number of intermediate DNS servers. DNS is also cached, and TTL is sometimes not respected by intermediaries. Even if TTL was respected, due to the dynamic nature of requests and responses the caching mechanism in the intermediate DNS servers are going to be overwhelmed. All these systems would be designed with assumption that responses are short, TXT queries are rare, records, especially potentially long ones like TXT are not going to change that often. The whole caching mechanism will be optimized for the "normal" DNS use case. So widespread adoption of this technique could cause some chaos.
What a day! I just configured one dns server and got to see an amazing use case.
DNS as efficient as it may, is still an application layer protocol. So it's still an abstraction over UDP, and not only do DNS servers treat it as such, like caching results etc, but the whole "no need to install a client to use this service" is counterintuitive to the data efficiency argument. Your own application layer program, is still the most efficient possible protocol there can be. So by just writing something as simple as a bash script or a powershell script, whose whole job is to send a udp datagram of a string without newlines to a server you host, is still the most efficient way to have a highly efficient service
Yes technically , this could be done but , but this still feels really cool.
Though udp is unreliable , we could probably use something like reliable udp but IDK
Learning about DNS from someone else's cool side project 😅
Didn't click in my brain for a few hours that this is the CTO of Zerodha lol. Pretty cool to see a CTO that still has coding side projects!
wait really , that's so cool
so cool !
lol i love this.
im making use of this in my next project (i exactly needed something like this hahahha)
His voice 😮
12:46 thanks :)
Now that's cool
It's so cool to be a geek
Cooooooooooool
whoa that first guy who asked question sounded really rude 😅
chill dude its a toy project
not all queries are for that TXT , bot probing