Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TXT Record XSS

who.is

Post reply on HN
Print view View original

181–190 of 236 posts

Re: TXT Record XSS

#181

Post by jacquesm »

Joyfield wrote: post #150
mrb wrote: 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 wrote something like that but distributing torrents. Wrote it AGES ago : http://netrogenic.com/dnstorrent/

The phrase 'knows just enough to be dangerous' comes to mind :)

Re: TXT Record XSS

#182

Post by tantalor »

mrb wrote: 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…

isinterneton.com implemented something like this circa 2011 but it looks dead now.

You can still see how it worked: http://whois.domaintools.com/isinterneton.com

It defined a few nameservers,

  IS-INTERNET-ON.TITLE.ISINTERNETON.COM 
  YES.BODY.ISINTERNETON.COM
The server reads these values and constructs a page like,

  Is Internet On
  Yes

Re: TXT Record XSS

#183

Post by dschatz »

venaoy wrote: post #177
TeMPOraL wrote: post #153

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…

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

FYI both a TCP SYN and SYN/ACK can carry a payload (which could be the GET and RESPONSE)

Re: TXT Record XSS

#185

Post by michaelmior »

aidenn0 wrote: post #180
michaelmior wrote: post #84

Earlier quoted context omitted.

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.

Not really. Unless you have direct browser support for these DNS pages, you still need the proxy server close to your client to get the benefits of a CDN. Besides, the content is static, you could just dump that on a web server anyway.

Re: TXT Record XSS

#186

Post by nucleardog »

danellis wrote: post #136
jameshart wrote: post #106

Earlier quoted context omitted.

Used to work in the DNS business. "It will take up to 24 hours to propagate" is a way to manage expectations and prevent support calls from coming in within the first 24 hours after a DNS change, not a reflection of actual DNS propagation times.

I hate the term "DNS propagation". It confuses people, and makes them think things that aren't true, like a new domain isn't usable until it "propagates" through the Internet.

Again, managing expectations.

We tell clients that we've launched their site, but that the DNS changes might take up to 48 hours to propagate.

Realistically, from our office and to most of the world it's probably live within 5 minutes. One of our local ISPs happens to be one of those irritating ones that just ignores your TTL and caches records for days at a time.

Sometimes one of their servers will end up with the new record and one with the old. That combined with peoples' home routers caching records (again, sometimes ignoring TTLs) can lead to fun situations where the site might load fine for a couple hours (hit the good ISP server, local router cached) then the old site for a couple of hours (hit the bad server, local router cached...).

I used to try and explain it to people but after having enough people freak out about how their site switched back, it's not live yet, etc, etc... I just tell them it's going to take 48 hours. If it's visible earlier it's a pleasant surprise, and if it takes two days I don't get any panicked phone calls.

Re: TXT Record XSS

#187

Post by WiseWeasel »

jrockway wrote: post #156
Steuard wrote: post #149

Earlier quoted context omitted.

I hope you're not still talking cruise ships here! Those folks are often paying high prices by the minute or by the megabyte for access: you'd be pretty literally stealing from your neighbors in that situation. (The moral issue for pay-by-the-day systems is one step further removed, but I think it's still real.)

802.1x covers access control to networks. MAC addresses are not for access control. Not that a court would agree with my logic, of course.

Yeah, you might have a tough time explaining to the judge that Media Access Control addresses are not for access control.

Re: TXT Record XSS

#188

Post by click170 »

milkshakes wrote: post #138
BuildTheRobots wrote: post #123

Earlier quoted context omitted.

For another fantastic abuse of DNS, the Iodine* project uses DNS to tunnel IP which is just obscene. http://code.kryo.se/iodine/ (Why? Lots of captive portal wifi hotspots (think hotel/train etc) seem to allow DNS resolutions before stopping your other traffic.) * DNS uses port 53 which is the same as the atomic number for Iodine ;)

malware authors have been using this technique for some time: http://www.cs.berkeley.edu/~mobin/publications/2013/DNS_USEN...

How to start protecting yourself against this.

http://www.neustar.biz/blog/how-to-identify-prevent-dns-tunn...

Re: TXT Record XSS

#189

Post by brianpgordon »

batbomb wrote: post #142
galvan wrote: post #128

Earlier quoted context omitted.

Ah, iodine. I've used it in airports, hotels, cafes - it's great. The only drawback is that it's slower than dialup and latency is off the charts. But when you're stuck on a cruise ship and internet access is $8 a minute, being able to ssh somewhere and browse the web and check your mail very slowly through links is worth it.

I usually just spoof mac addresses of people who already paid in most of those cases, the caveat usually being somebody had to pay.

I was staying at a Hilton (Omaha, NE) last night and their captive portal scared me off by putting the MAC address, IP address, and user agent in the query string, plus network stuff like the VLAN id and the MAC address of some piece of network gear that's servicing you. It seemed like they had a pretty complex system to deter abuse.

Of course, I just tethered my phone and got way better service than their crappy $10/day wifi.

Re: TXT Record XSS

#190

Post by callesgg »

venaoy wrote: post #174
callesgg wrote: post #172

Earlier quoted context omitted.

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.

It does not have to to with link, udp or ip it is a limitation of the dns spec.

Here is a extention that "fixes" it: https://tools.ietf.org/html/draft-ietf-dnsind-udp-size-02 I have not seen that spec extention implemented in the wild. I just found the extention so I have on the other side not looked for it.

Post reply on HN