Live data from Hacker News

Mess with DNS

jvns.ca

81–90 of 94 posts

Re: Mess with DNS

#81
post #70

Earlier quoted context omitted.

After reading through the draft I think I don't understand the argument about user privacy. Does QNAME minimization try to prevent the scenario where a malicious party has setup a DNS tracker that responds with the same A/AAAA entries for a specific subdomain in the sense that e.g. "session-id.actualserver.company.tld" results in the same entries as "actualserver.company.tld"? How would a client detect this before ac…

QNAME minimization is for recursive resolvers. The scenario is that you want to resolve alice.example.com but you don't want the root servers or the .com servers to know any more information than they need to. Historically you would send the whole query to all servers. Even the root servers would see the entire fully-qualified domain name (alice.example.com) even though all they're going to do is refer you to the .co…

> Your ISP used to see the query going to the root servers or the .com servers and know the FQDN even if the query to example.com was encrypted. Now they don't.

In practice your recursive resolver either is your ISP (in which case this helps nothing) or is outside of your ISP (and your ISP can't see its queries). The only realistic privacy leaks that is addresses is leaking subdomains to the root servers and other delegating servers higher up the chain an their network operators.

Re: Mess with DNS

#82
post #31

Earlier quoted context omitted.

Pretty much all major browsers check against Google's safe browsing list so it's pretty much a death sentence to be on it.

Indeed. Google basically gives this service away to browsers. It costs money if you want to build a commercial service using it, but if you give away browsers, no problem. You can switch it off, but you probably shouldn't, even if you're sure you would spot a phishing scam, actually maybe even especially if you're sure you would spot the scam. The service is capable of being quite nuanced since it works on (hashes of…

> You can switch it off, but you probably shouldn't

You really should disable it because Google cannot be allowed to be the gatekeeper of the internet. The list contains tons of non-malicious URLs [0] and Google has absolutely no incentive to remove them. And even if you haunt them enough to do so the same broken process that added it in the first place will just add it again. Any browser that enables this list by default is actively making the web a worse place an engaging in mass-defamation.

[0] Example: dgVoodoo2 downloads from http://dege.freeweb.hu/dgVoodoo2/

> It does NOT contain any malware. Use a browser that is free of Google Shit Browsing security service crap (which is based on tons of noname antivirus "engines", look at VirusTotal if interested).

Re: Mess with DNS

#83
post #61

This is a really great resource. I wrote a DNS Server in C# once upon a time, it was hard, I wouldn't suggest it to anyone unless the benefit weights up as $millions. I could have killed for a tool like this, instead I spent a tonne of time in PCap and NetMon :( Its out there on my GitHub if folk are interested. Ironically 53 comments just before I added this comment...

> 53 comments

Maybe, just maybe, it is an omen? ;-)

Re: Mess with DNS

#84

Earlier quoted context omitted.

The oauth flow you just mentioned exists, I just did it to confirm my domain in cloudflare with google workspace: google did an oauth flow and I got a cloudflare popup asking me to add a dns record for an hour. It was very cool.

This is news to me. Can you provide more details or point to some documentation of this feature?

My friend, it took me a few hours to find it -- there's zero documentation on Cloudflare about cloudflare supporting it, but it's supported [1], but godaddy luckily is a lot more vocal about it [2], here's the spec:

https://www.domainconnect.org/

Don't you hate it when you have a good idea and someone already did it, but also love it because it's validation of your good idea?

[1] https://www.godaddy.com/engineering/2019/04/25/domain-connec...

[2] https://dash.cloudflare.com/domainconnect/v2/domainTemplates...

Re: Mess with DNS

#85

Neat project! Setting up your own DNS server for a throwaway domain is definitely a pain, especially if you've never done so and use anything other than PowerDNS really, so this is useful for messing around with. I do hope the author has set some limits on the DNS configuration you can freely enter. One annoying trick DDoS spammers will use is that they will set up DNS records that are as large as possible to use for…

CoreDNS which is commonly used in Kubernetes as a caching DNS server also supports RFC zone files and is very easy to configure. Written in Go, with just a few system library dependencies. I use it for LAN domains + cache + DoT client and it works nicely. I would probably not use it for big production deployments but it actually even supports master-slave transfers. :) Maybe worth having a look at this too.

Re: Mess with DNS

#86
post #65

Earlier quoted context omitted.

That's a good idea, but it would require all the registrars agreeing on a few different protocols and people doing the hard work of implementing them reliably at many, many, many different participants. Since lots of those participants are competitors (e.g., many registrars provide hosting, email service, etc), I think it would be very hard to get enough momentum that places like, say, GoDaddy would feel obligated to…

It seems like a pretty useful feature one of the big boys could offer to differentiate themselves. Or I could see a new entrant in the domain seller space marketing this as a main feature.

But it only works if it has significant compliance. If a new entrant offers the service, there's little reason for other places to implement it, because only a tiny percentage of their customers will be using it. And the big boys have a disincentive because they already offer things like email and web hosting. Making it easy for people to buy those services elsewhere will cut in to their revenue.

Re: Mess with DNS

#87

Earlier quoted context omitted.

This is news to me. Can you provide more details or point to some documentation of this feature?

My friend, it took me a few hours to find it -- there's zero documentation on Cloudflare about cloudflare supporting it, but it's supported [1], but godaddy luckily is a lot more vocal about it [2], here's the spec: https://www.domainconnect.org/ Don't you hate it when you have a good idea and someone already did it, but also love it because it's validation of your good idea? [1] https://www.godaddy.com/engineering/2…

Wow, I'm still reading the spec but on the surface this appears to be almost exactly what I've been looking for for over a year[0] and somehow unable to find. I really appreciate you taking the time.

And yeah I hear what you're saying about ideas haha.

[0]: https://news.ycombinator.com/item?id=23761788

Re: Mess with DNS

#88

This tool is so neat! One thing I've learned from it is my ISP (sonic.net) seems to be doing queries to _.example.com. For instance: $ dig @50.0.1.1 nelson.lily6.messwithdns.com a Results in two queries being answered by the messwithdns server. One for nelson.lily6.messwithdns.com as expected, but also one for _.lily6.messwithdns.com. Any guesses what that naked underscore query is for? Not every nameserver does it (…

Sonic.net is using bind9, where this "qname-optimization" is a default setting for protecting user privacy. https://www.isc.org/blogs/qname-minimization-and-privacy/ https://bind9.readthedocs.io/en/latest/reference.html (look for qname) (I work at Sonic)

Thanks for the info and the awesome ISP!

Re: Mess with DNS

#90
post #70

Earlier quoted context omitted.

QNAME minimization is for recursive resolvers. The scenario is that you want to resolve alice.example.com but you don't want the root servers or the .com servers to know any more information than they need to. Historically you would send the whole query to all servers. Even the root servers would see the entire fully-qualified domain name (alice.example.com) even though all they're going to do is refer you to the .co…

> Your ISP used to see the query going to the root servers or the .com servers and know the FQDN even if the query to example.com was encrypted. Now they don't. In practice your recursive resolver either is your ISP (in which case this helps nothing) or is outside of your ISP (and your ISP can't see its queries). The only realistic privacy leaks that is addresses is leaking subdomains to the root servers and other de…

Many organizations operate their own recursive resolvers. There is also nothing stopping an individual from doing so, even if most don't.
Post reply on HN