Live data from Hacker News

TXT Record XSS

who.is

171–180 of 236 posts

Re: TXT Record XSS

#171
post #57

I am half serious, but how about making HTML served in TXT records a standard trick for serving small web pages very quickly? There are way fewer network round trips: 1. DNS query for TXT record for example.com 2. DNS reply with HTML content Compared with the traditional 7 steps: 1. DNS query for A record for example.com 2. DNS reply with x.x.x.x 3. TCP SYN to port 80 4. TCP SYN/ACK 5. TCP ACK 6. HTTP GET 7. HTTP rep…

> I am half serious Good. Still, it needs to be pointed out. This idea is an awesome hack to show how can you piggyback on existing infrastructure to make it work as something it was not intended to. But it absolutely, terribly sucks at anything practical. Actually, it's a non-solution . Here's why. > There are way fewer network round trips: > 1. DNS query for TXT record for example.com > 2. DNS reply with HTML conte…

I don't think you understand his hack - but then, that's understandable, because it wouldn't work anyway without modifying the browser. You'd need a special client (or a proxy) to feed the content of DNS TXT record directly to the browser, because you're not using HTTP (or even TCP) anymore.

Exercise for the reader (the proxy soln): write a server called txtdns.com that returns the content of TXT records as HTML. The path would look like http://txtdns.com/example.com - and the key is that the server is only accessing DNS, even though your client is using TCP and HTTP.

Re: TXT Record XSS

#172
post #57

I am half serious, but how about making HTML served in TXT records a standard trick for serving small web pages very quickly? There are way fewer network round trips: 1. DNS query for TXT record for example.com 2. DNS reply with HTML content Compared with the traditional 7 steps: 1. DNS query for A record for example.com 2. DNS reply with x.x.x.x 3. TCP SYN to port 80 4. TCP SYN/ACK 5. TCP ACK 6. HTTP GET 7. HTTP rep…

A UDP dns response will be truncated if it is longer than 512 bytes.

If you want more stuff you have to use TCP and that is not very preferable.

Re: TXT Record XSS

#174
post #57

I am half serious, but how about making HTML served in TXT records a standard trick for serving small web pages very quickly? There are way fewer network round trips: 1. DNS query for TXT record for example.com 2. DNS reply with HTML content Compared with the traditional 7 steps: 1. DNS query for A record for example.com 2. DNS reply with x.x.x.x 3. TCP SYN to port 80 4. TCP SYN/ACK 5. TCP ACK 6. HTTP GET 7. HTTP rep…

A UDP dns response will be truncated if it is longer than 512 bytes. If you want more stuff you have to use TCP and that is not very preferable.

False. IP fragmentation allows the size of a single UDP DNS response to be up to 65535 bytes, regardless of the network MTU.

Re: TXT Record XSS

#177
post #57

I am half serious, but how about making HTML served in TXT records a standard trick for serving small web pages very quickly? There are way fewer network round trips: 1. DNS query for TXT record for example.com 2. DNS reply with HTML content Compared with the traditional 7 steps: 1. DNS query for A record for example.com 2. DNS reply with x.x.x.x 3. TCP SYN to port 80 4. TCP SYN/ACK 5. TCP ACK 6. HTTP GET 7. HTTP rep…

> I am half serious Good. Still, it needs to be pointed out. This idea is an awesome hack to show how can you piggyback on existing infrastructure to make it work as something it was not intended to. But it absolutely, terribly sucks at anything practical. Actually, it's a non-solution . Here's why. > There are way fewer network round trips: > 1. DNS query for TXT record for example.com > 2. DNS reply with HTML conte…

You are incorrect. An HTTP GET still requires a 3-way TCP handshake, so your suggestion requires 5 steps not 2:

  1. TCP SYN to port 80
  2. TCP SYN/ACK
  3. TCP ACK
  4. HTTP GET
  5. HTTP reply with HTML content

Re: TXT Record XSS

#178

Earlier quoted context omitted.

> I am half serious Good. Still, it needs to be pointed out. This idea is an awesome hack to show how can you piggyback on existing infrastructure to make it work as something it was not intended to. But it absolutely, terribly sucks at anything practical. Actually, it's a non-solution . Here's why. > There are way fewer network round trips: > 1. DNS query for TXT record for example.com > 2. DNS reply with HTML conte…

I don't think you understand his hack - but then, that's understandable, because it wouldn't work anyway without modifying the browser. You'd need a special client (or a proxy) to feed the content of DNS TXT record directly to the browser, because you're not using HTTP (or even TCP) anymore. Exercise for the reader (the proxy soln): write a server called txtdns.com that returns the content of TXT records as HTML. The…

would make more sense to have it be a local proxy, IMO?

(and probably be easier to boot, given the right scripting language/libraries that should be doable in 10-30 lines of code or so)

Re: TXT Record XSS

#179
post #125

Earlier quoted context omitted.

As someone who prefaces comments with similar things, I don't think it's unreasonable. Sometimes we know ideas are a bit of a cludge (Thinking back to the first time I did an IP over DNS tunnel) but it's still fun and interesting; but that doesn't stop some people jumping down your throat if they think you're suggesting it in earnest. Twice, maybe much? But the sentiment itself, I can see where it's coming from.

"but that doesn't stop some people jumping down your throat if they think you're suggesting it in earnest. " Or downvoting as they have done with my comment.

> Or downvoting as they have done with my comment.

That's because nobody came to this thread because they wanted to read your meta-discussion.

Re: TXT Record XSS

#180
post #57

I am half serious, but how about making HTML served in TXT records a standard trick for serving small web pages very quickly? There are way fewer network round trips: 1. DNS query for TXT record for example.com 2. DNS reply with HTML content Compared with the traditional 7 steps: 1. DNS query for A record for example.com 2. DNS reply with x.x.x.x 3. TCP SYN to port 80 4. TCP SYN/ACK 5. TCP ACK 6. HTTP GET 7. HTTP rep…

If you want to access this in a web browser, you still need some server which speaks HTTP and makes the DNS request and forwards the result to the browser. So you're really not saving much there. In fact, you'll have higher latency since you now need HTTP plus an extra DNS request. Unless of course browsers support dns://...

But DNS is cached; to some degree you're getting a free CDN when you do this.
Post reply on HN