Eg.
dig newyork.time.dns.toys with a low ttl?
This way folks operating in an environment where they can't egress on port 53 can still use the tools?
21–30 of 111 posts
Eg.
dig newyork.time.dns.toys with a low ttl?
This way folks operating in an environment where they can't egress on port 53 can still use the tools?
I guess you could deliver web pages over DNS too, if you wanted... though I'm not sure why you'd want to. Instead of DoH it would be HoD.
You can also use iodine ( https://github.com/yarrick/iodine/ ) to tunnel IPv4 data through DNS (useful e.g. when on a captive portal network that doesn't block DNS requests). Performance isn't great obviously, but the concept is fascinating nonetheless.
Fun :). It would be interesting to see how accurate one could get the time records (I see a TTL of 1 second, but what if the algorithm for reporting the time could try to measure latency between DNS client and itself and . . . yadda yadda yadda). Wish we had more submissions like this one.
“Why? For fun.” I love this. It doesn’t need a reason to exist. It’s interesting on its own. That being said, can anyone think of additional interesting reasons for why this would be useful rather than the same toys over HTTP?
maybe on a wifi network before authentication when it may allow DNS resolution but not HTTP requests?
Earlier quoted context omitted.
You can also use iodine ( https://github.com/yarrick/iodine/ ) to tunnel IPv4 data through DNS (useful e.g. when on a captive portal network that doesn't block DNS requests). Performance isn't great obviously, but the concept is fascinating nonetheless.
So you could tunnel ipv4 through DNS, and serve HTML via DNS, and use DNS over HTTPS?
“Why? For fun.” I love this. It doesn’t need a reason to exist. It’s interesting on its own. That being said, can anyone think of additional interesting reasons for why this would be useful rather than the same toys over HTTP?
“Why? For fun.” I love this. It doesn’t need a reason to exist. It’s interesting on its own. That being said, can anyone think of additional interesting reasons for why this would be useful rather than the same toys over HTTP?