Real answer: many ISP’s DNS servers are set to ignore whatever you set and use a value they feel works best for themselves.
Mess with DNS
11–20 of 94 posts
Re: Mess with DNS
#12Why not just... use an authoritative DNS server?
> I think I’m doing a pretty bad of following the DNS RFCs
Yeah, probably, which makes this experiment much less worthwhile than just... doing the same thing on an actual DNS host.
BTW, experimentation is no replacement for training/education/experience. Just because an experiment results one way on the computer you're testing with, doesn't mean it will resolve the same way in another browser - or on another OS - or even just on a different ISP(/resolver).
> finding out who owns IP addresses with an ASN database - When a DNS requests comes in, it comes from an IP address. I wanted to tell users who owns that IP address (Google? Cloudflare? their ISP?). The obvious way is to do a reverse DNS lookup. But what if that doesn’t work?
Or just use one of the many databases that exists for exactly this purpose (and are free, like MaxMind's GeoLite ASN). Except, oh wait, you did do that (although with some random, auto-scraped database). Not sure what the point of rDNS is.
> I do a database write every time a DNS request comes in
Why? There's no reason to store that info on disk. As you say, "I could easily clear out old requests every hour and it probably wouldn’t make a difference"
> let’s talk about security
Sure, except you skipped over the "huh, I'm sharing cookies across all these people because I'm not on the PSL". But at least "the website's domain" isn't sharing cookies with 'em too?
Oh, and you also skipped over things like whether or not your roll-your-own DNS server is vulnerable to being used as an amplification vector (probably).
> I have one main opinion about programming, which is that deeply understanding the underlying systems
It's a shame she doesn't deeply understand the underlying systems she's using.
Re: Mess with DNS
#13Earlier quoted context omitted.
Humans individually are pretty useless. Abandon a random human in a jungle and they will likely perish soon no matter how smart and well educated they are. The strength of humanity is teamwork, working together to build things other groups can build things upon. Abandon 100 random humans in the same jungle and they will build a town.
How many would actually be able to build anything if it was purely random? How many tries of 100 people batches until they've built something? Not arguing, just questions that came into my mind.
Even non-random groups like your coworkers or immediate neighbors can have unexpected skills that will make you feel dumb.
Re: Mess with DNS
#14Re: Mess with DNS
#15Julia Evans continues to do so many cool projects! The blog, the zines, now this, such great work! It always amazes me when one person can create so many useful things.
Re: Mess with DNS
#16Re: Mess with DNS
#17Re: Mess with DNS
#18https://blog.benjojo.co.uk/post/dns-filesystem-true-cloud-st...
Re: Mess with DNS
#19On the security aspect, I wonder how is this site affected services that do domain ownership verification [1] where they assume that only a person who owns the domain can edit dns records. I think letsencrpt ACME protocol [2] does it for SSL certs too. This site does create a subdomain for every user, so may be these issues don't apply. [1] https://support.google.com/a/answer/183895?hl=en [2] https://letsencrypt.org/…
If you don't trust across separator boundaries you're mostly safe. That is, mytxt.foo.com shouldn't be blindly trusted for my.subdomain.foo.com nor mytxt.subdomain.foo.com shouldn't be trusted for foo.com.
IMO the biggest concern is with organizations that blacklist domains for various reasons, because they are not eager to just build very fine-grained blacklists.
Re: Mess with DNS
#20There's another AWS outage, & presently the top comment is talking about us as barbarians that have stumbled into fancy hot baths & are amazed but have no idea how to keep them running. And a wonderful follow-up reply[1] talking about living in an apartment in a storm versus living in a cave during a storm. It presents another severe image of how much drift there has been in the world, how much more built up, but how…
Julia Evans's cool stuff aside (and it is _very cool_, we need all the high quality didactic material we can get!), all this info _is_ on the net. I'm always surprised when I see engineers (like in that linked post) who don't understand how to do things like regional failovers, DNS load balancing, load balancing strategies, load shedding, circuit breaking, AZ balancing/failover, etc. These are pretty standard concept…
And I think that makes all the difference. I tend to believe very strongly in hands on experience, think that seeing things happen yourself & getting to play is by far the best way to learn, just incredibly surpassing.
There's a theory of education called Constructivism[1] that is broadly similar. Adherents include folks like Seymore Papert[2], creator of Logo, employee at One Laptop Per Child (which I think is the most interesting & innovative software environment we've ever created, vastly under-appreciated). Projects like Logo are supposed to create that hands on feedback, to make programming not just writing scripts & having programs run, but ways to see the code really execute, to create more interactive modes.
With software eating the world, it is so so so important to me not just to create knowledge, to tell tales of what software is, but to let people have the experience themselves. To create playgrounds to meddle, to mess around. I wish so much that applications could actually show & explain what they are doing, what's inside of them, could reveal their workings, but we're so far away from that Enlightened world, we've fallen into such deep shadows imo.
(Side note, I see things very differently, but I also am disappointed folks would downvote your perspective like this. As for the lack of knowledge/experience, I'd say that most engineers don't have familiarity because there's not a lot of opportunities to set up & learn systems work; most coders spend their time coding, not setting up bits of infrastructure to run code on. You yourself also say "writing the code is the easiest part", which underscores just how complex/inter-related/particular all the systems/infrastructure stuff is, how probable it is engineers might not feel fully competent or brave enough to engage.)
[1] https://en.wikipedia.org/wiki/Constructivism_(philosophy_of_...