[HN Gopher] Why is DNS still hard to learn?
___________________________________________________________________
Why is DNS still hard to learn?
Author : TangerineDream
Score : 255 points
Date : 2023-07-28 16:33 UTC (6 hours ago)
(HTM) web link (jvns.ca)
(TXT) w3m dump (jvns.ca)
| m3047 wrote:
| In a kind of corrollary of Dunning-Kruger, there is often a chasm
| between what people think DNS is and all of the things it can be.
| The article points some of that out (stub resolvers, even
| different implementations of libc); recursive versus
| authoritative responses; the recursion process; recursive versus
| authoritative servers.
|
| A lot of deployment implementations are "bottom of the barrel"
| and aren't correct to begin with, although they work for the
| intended purpose. There is no checklist for server
| implementations which I am aware of (I've asked where people
| should know!). There's a lot of folklore which persists because
| if it works it's presumed correct.
|
| There's "DNS" and then there's "The DNS", the "one true root"
| with arbitrary restrictions on the contents of labels. There's
| political interference with implementations in terms of the "one
| true root" doctrine, which interferes with marrying a resolver
| which e.g. queries a control plane and serves an application
| plane (where they have different roots): there are e.g. notions
| of forwarded zones, but there is no notion I am aware of of a
| "always recurse and lie that you're authoritative" zone (you can
| hack source code to accomplish this of course).
|
| Even MITRE ATT&CK doesn't always get it right. They had it listed
| that DNSSEC "traffic" had to be examined with SSL tools, until I
| pointed it out (I didn't get credit). DNSSEC related records are
| ordinary DNS records, nothing is being encrypted.
|
| I could go on: the experts were wrong on (UDP) frags, anycast...
| nineteen999 wrote:
| Another one of these articles. We learnt very easily back in the
| 1990's when the Internet was smaller, and the computers were much
| much slower and less capable.
|
| DNS, LDAP, SMTP, IMAP etc were the bread and butter of ISP's back
| then and people actually referred to the official documentation
| (RFC's etc). You had to learn them if you wanted to run servers
| on the Internet at all, and with a bit of an investment of time
| (ie. your paid time on your job) you learned it.
|
| This generation of developers and devops people don't have the
| patience or initiative and expect to be spoon fed and just cut
| and paste crap from StackOverflow and various low value blogs.
| Rather than learn the infrastructure that the Internet is built
| on, they grab the latest fashionable wrapper tool of the week,
| follow some shitty blog instructions, and then cry foul when it
| all falls apart and they cost their company lots of money. Just
| because they didn't take the time to learn the foundations of how
| things _actually_ work on the Internet.
|
| I've seen it time and time again. It's not actually that hard
| kids. You just need to do your homework.
| lannisterstark wrote:
| Ah another one of those "dese damn kids and millennials I tell
| ya hwat, back in my grandpappys days we used to mine our own
| copper before laying them lines!"
| nineteen999 wrote:
| The "get off my lawn vibe" was totally intended. Doesn't
| change the fact that there are a bunch of "AWS architects"
| out there running Terraform and building future disasters
| because they don't properly understand the infrastructure
| that the whole thing sits upon.
|
| It's just like the morons who think that dynamic linking
| should be abolished for everyone, because they don't
| understand the use cases for distributors from a security
| standpoint, developers/users who require binary modules, or
| how to use their distributions packaging tools to avoid
| conflicts, and are too lazy to learn. But oh no, "ma DLL
| hell". Good grief.
| mqus wrote:
| For me, the issue isn't so much DNS itself, but more that there
| are more things that try to resolve names on your PC, like
| /etc/hosts and all the stuff you put into resolv.conf.
|
| Then you read online that you should try dig or so and those
| tools don't really match up with what your tools do(=resolving
| via libc), because dig really only does the DNS part.
| pavel_odintsov wrote:
| Great article. Thank you!
|
| I used to develop and maintain one of the World largest DNS
| services and summarised my experience with DNS protocol in this
| blog post: https://pavel.network/please-stop-using-dns-protocol-
| for-you...
| gjvc wrote:
| I remember being stymied by the BIND zone files (which are plain
| text) being called .db files (they may actually be called
| anything -- some people used the .db extension). I had just
| learned about sendmail, and I knew it kept alias tables in
| Berkeley DB files (which are binary), which in sendmail parlance
| were also called .db files.
|
| As Alan Kay is fond of quoting Bob Barton... "Systems programmers
| are high priests of a low art."
| supportengineer wrote:
| This was an outstanding writeup, and I have felt the same
| frustrations in many other contexts. I enjoy going the "make your
| own, friendlier tools" route.
| cafard wrote:
| Some years ago, I had a miserable couple of days when an internal
| DNS server quit working. Eventually I traced it to a corrupted
| cache file. Once that was deleted, life returned to normal.
|
| Though unpleasant, it was an enlightening experience. I had never
| imagined how much of the internet ran on Amazon by then (2010?).
| pgray wrote:
| the joke i've always heard is DNS combines 2 of the hardest
| problems in CS: naming things and cache invalidation
| paulddraper wrote:
| Yes, but not a joke.
| fauria wrote:
| you forgot the second, off-by-one errors.
| Dylan16807 wrote:
| It comes with a validity counter in seconds, and you can be
| very very loose about counting those seconds.
|
| It's not the hard kind of cache invalidation. You don't really
| have to do "invalidation" at all.
|
| And on the server side, it's perfectly acceptable to send a mix
| of old and new versions for a while.
| dclowd9901 wrote:
| > It's not the hard kind of cache invalidation. You don't
| really have to do "invalidation" at all.
|
| One of the points he brings up is negative cache, or caching
| the dns into a state that it won't retrieve a resolved
| address even if it's available simply because the negative
| case is cached.
|
| Invalidation is definitely a part of it, mostly because you
| kind of can't.
| andrewaylett wrote:
| That definitely helps things to _work_ , but it makes it very
| much more difficult to work out why things might _not_ be
| working.
|
| Not least because an unexpected cache can lead to things
| looking like they're working when they're actually broken at
| source, as well as things looking like they're still broken
| when you've actually fixed them at source already.
| Dylan16807 wrote:
| "I didn't know that cache existed" isn't because of the
| difficulty of invalidating the right items, though.
|
| And the occasional cache that keeps things forever is so
| extra broken that it's not doing that because cache
| invalidation is _hard_ , it's either a supreme
| misunderstanding or it's incompetence.
| zhengyi13 wrote:
| > And the occasional cache that keeps things forever is
| so extra broken that it's not doing that because cache
| invalidation is hard, it's either a supreme
| misunderstanding or it's incompetence.
|
| Working in phone technical support in the early 2000s, I
| encountered first in CF6 and then at least one J2EE
| implementation (Websphere, maybe?) where the $^&#ing
| _default_ was to cache DNS results _forever_.
|
| The behavior was borderline undocumented, and the setting
| to fix it was even less well documented. It's like they
| _wanted_ DNS to not be a thing.
| lanstin wrote:
| Sadly reboot the VM is still a valid step in debugging
| DNS, while you google "clear cache for this type of
| client resolver"
|
| Also, the dreaded caching of negative
| results/authoritative no such domain just before you get
| the new domain working properly.
| 8organicbits wrote:
| You sometimes can perform an invalidation, but it's a manual
| process and you need to know who to ask. Slack did this when
| they botched their DNSSEC rollout[1]:
|
| > Our team quickly started contacting major ISPs and
| operators that run public DNS resolvers, with the request to
| flush all cached records for slack.com.
|
| DNSSEC is another part of DNS that is still hard to learn.
|
| [1] https://news.ycombinator.com/reply?id=36910054&goto=item%
| 3Fi...
| kabdib wrote:
| DNS itself is pretty simple. Implementing a basic DNS server or
| client is not a big deal.
|
| The management software around it is what is generally terrible.
| neilv wrote:
| At one point, I had to make and maintain my own DNS zone text
| file, knowing only a little. Today, cheap providers give me
| various Web forms interfaces, but that doesn't mean it will
| always "just work", so knowing a little can still help.
|
| I still had to break out `dig` the other day, when a DNS provider
| started answering records days past TTL, breaking email and Web.
|
| To know when if/when that happened again, I looked around for a
| monitoring service, but didn't quickly find one that did what I
| wanted (and was overwhelmed by SEO, and very aggressive robo-
| sales emails from one of them), so I wrote a script that
| essentially runs `dig` and `diff`:
| https://www.neilvandyke.org/check-my-dns/
|
| The monitoring script discovered one of a provider's DNS servers
| had ongoing problems, so I sent them a monitoring report, saying
| I wasn't a DNS expert, but perhaps, if there's a problem, the
| report would be helpful to their DNS experts. This seemed to
| immediately get past any "have you tried rebooting Windows"
| front-line flowchart response that I wouldn't have been surprised
| to hear, and they said they're working on it.
| 1vuio0pswjnm7 wrote:
| I'm not a "developer" and I learned DNS without any problems.
| Therefore agree with other commenter that DNS is not actually
| difficult to learn. I like the output from DNS utilities such as
| BIND and tinydns format.
|
| DNS is worth learning for any internet user, IMHO. I've written
| primitive utilities that when used together can do stuff none of
| the popular DNS utilities can do. I use these every day.
|
| Here's DNS challenge for readers. Try to look up the domain
| "bootable.com". Use whatever is the preferred method.
|
| People writing about DNS often compare it to a telephone book.
| IMO the way most people use DNS is more like "directory
| assistance".
|
| IP addresses do change but by and large most stay the same for
| long periods. Old zone files, publicly available scans^1 and
| other bulk DNS data collected from web crawls and public DNS
| caches comprise the "phone book" for me. Absolutely essential.
|
| 1. Sadly, in recent some of these sources have changed to non-
| public. No phone book for you! Call directory assistance.
| rconti wrote:
| > DNS is not actually difficult to learn.
|
| > tinydns format.
|
| You earned my disagreement right there!
| jl6 wrote:
| It's one of those things where there is a mismatch between how
| easy it seems to be, and how hard it turns out to be.
|
| We all use DNS every day, and it _seems_ really easy. The
| everyday language of DNS is: domain names, lookups, IP addresses.
| This language is exposed in browsers for all to see, and through
| this exposure we develop a mental model of how we think it works.
|
| But under the covers there is a whole new language: zones,
| resolvers, delegated authority, that weird dot _after_ the top-
| level domain...
| gerdesj wrote:
| "that weird dot after the top-level domain"
|
| That weird dot is called root. Without it, a name is
| unqualified, with it the name is completely defined. That means
| that context is everything. Without the dot, a resolver might
| add the resolver's domain or parts of it, repeatedly.
|
| Now, you and I know exactly what: host.example.co.uk is
| supposed to mean but without the trailing dot a resolver could
| try to look up host.example.co.uk.example.co.uk
|
| Windows out of the box, if this happened would also try
| host.example.co.uk.example.co then host.example.co.uk.example
| and then host.example.co.uk.example, then host.example.co.uk.
| and get a result. However I never saw Windows actually try the
| first effort and I think the behaviour was designed to deal
| with large corp with DNS federated monstrosity Active
| Directories.
|
| Your browser is probably toddling off to a DNS over https (DoH)
| server these days without your say so and canoodling with all
| sorts of ne'er do wells. Your DNS lookups are basic data - your
| ISP used to love seeing where you go. Your OS vendor (if you
| buy your OS) obviously can pass back "telemetry". Mr Google,
| doesn't own the desktop but does own the browser, so by
| ensuring you use "safe" DNS servers for your browser instead of
| whatever you have configured, its all good. All these
| shenanigans does make IT troubleshooting far more exciting than
| it used to be.
|
| I shouldn't worry too much about trailing dots. You will almost
| certainly not be using the DNS servers you think you are. I get
| why DOH was invented and there is a good reason for some
| "civilians" to use it - ie a non IT specialist using a nasty
| wifi hotspot will be protected from some harm by their browser
| going home securely to do DNS lookups. However is it up to the
| browser vendor to trample all over the user's choice of
| Endpoint Security?
|
| DNS is way more complicated than simply looking up addresses.
| Its about money these days (actually it always has been since
| around 2000) and there are now a lot of very opinionated mega
| corps who want to decide who profits off you.
| dclowd9901 wrote:
| It's the distribution part that makes it hard right? There's a
| shit ton of dark magic happening above the atomic level of an
| individual node that both introduces the majority of the
| complexity and also the majority of the obfuscation.
|
| DNS is easy. An organization agnostic distribution of
| information is _really_ tricky.
| chasd00 wrote:
| i hate to be that guy but it's not hard to learn. The tools are
| just from a different era where expectations where... different.
| However, even in my day BIND was avoided in favor of other
| servers like that one by the qmail guy.. can't remember his name.
|
| this comment reminds me of one of my favorite Dilberts
|
| old guy watching Dilbert at his computer: you kids today and your
| fancy graphical user interfaces. Back in my day all we had were
| ones and zeros ...and sometimes we didn't even have ones.
|
| Dilbert: you had zeros? we had to use the letter 'o'
| TZubiri wrote:
| Non-issue
| jesuspiece wrote:
| +human flag is a sick idea, would love to see that PR.
|
| inb4: you do it
| tristor wrote:
| I don't agree with this article. I think DNS is something few
| people take the time to learn, but it's not actually hard to
| learn. One of the great things about DNS is that the system
| itself will tell you about it's internal state in response to
| queries. It's very easy to inspect a DNS server for a known zone
| and understand how it works, and there's very good tooling that's
| free and widely available to do this (like dig).
|
| It's always been a big surprise to me that my DNS expertise is
| what seems to be most memorable for a lot of folks I've worked
| with through my career, when I don't believe I know anything
| mystical or special. DNS is extremely well standardized, the most
| common server and client implementations rigorously follow the
| standard, and it's very easy to inspect with free tooling. It
| just takes some effort and time to learn, but it's not really
| hard.
| f1shy wrote:
| Absolutely agree. Back in the days, I was very inexperienced, I
| was thrown to the task of administering DNS (with BIND) and
| Sendmail. I had 100+ servers. The first couple of month was a
| lot of reading, and understanding things, but relatively fast I
| got a good understanding of it. After 6 month I was teaching
| DNS to other teams in other countries for the same company. It
| was not at all hard. I'm a very average engineer, and from 0 to
| explaining to others in 6 month, is by no means a difficult
| topic.
| pessimizer wrote:
| DNS isn't at all hard, it only takes two months to learn when
| you're being paid to, and after only _6 months_ you 'll be
| knowledgeable enough to teach!
|
| > from 0 to explaining to others in 6 month, is by no means a
| difficult topic.
|
| You should have seen almost anything else. Many things can be
| learned within days.
| Vaslo wrote:
| You have the curse of knowledge my friend. It's hard to learn
| and way more complicated than it needs to be.
| jvns wrote:
| I don't usually reply to HN comments, but I want to take a
| minute to address this one. It took me many years to feel
| totally comfortable debugging DNS problems, and I wrote this
| post to explain why I think it was hard for me.
|
| I also used to think that "no, actually, it's easy!" was an
| encouraging response to "this is hard to learn". And I kind of
| get it! I love DNS! I think it is surprisingly simple in many
| ways, and I've written about that a lot, for example in
| https://implement-dns.wizardzines.com which shows you how to
| implement a DNS resolver from scratch in some pretty simple
| Python code.
|
| But over the years I've learned that "no, it's easy to learn!",
| instead of coming off as an encouraging comment ("you can do
| it!"), often gets received as "no, it's not hard, actually the
| problem is that you're dumb". Like, I've been confused about
| this for years, and you're telling me that, no, actually it's
| easy? Not that helpful!
|
| So I've stopped telling people that, and instead I put a huge
| amount of work into trying to understand _why_ people find
| certain things hard and work to help remove some of those
| barriers.
| dogleash wrote:
| > I think DNS is something few people take the time to learn
|
| I kinda agree and think DNS one of those technologies where you
| can go an entire career without picking up more than bits and
| peices here and there. Those things gains a sense of mystique
| in industry as more complicated than it otherwise would if more
| people had to tackle it full on.
| WarOnPrivacy wrote:
| > I kinda agree and think DNS one of those technologies where
| you can go an entire career without picking up more than bits
| and peices here and there.
|
| As far as that's true it's weird, because DNS basically does
| one straightforward thing. But then you get into all the
| places where that one thing has to be done in different ways.
|
| Where I wouldn't mind some more magic is with reverse DNS.
| Too many tables don't know a name pointing to an IP until
| something tries to resolve that name.
|
| Reliably historical rdns would be even more awesome but
| that's more of a service than a spec thing.
| josho wrote:
| If you read the article the author points out why it's hard to
| learn. The concept is easy, but when teaching the concepts we
| don't include all the details of the modern internet.
|
| As an example what are the rules that your browser uses to
| cache and expire DNS entries? Are those rules consistent
| between browsers?
| antonjs wrote:
| And does your browser have settings which bypass or
| supplement the host's DNS configuration. Secure DNS (DoH etc)
| is great, but damn that's confusing when you first run across
| it. Not to mention how phones do it; you can't override a DoH
| DNS server when connecting to a VPN which offers internal DNS
| on Android, for instance.
| WarOnPrivacy wrote:
| > you can't override a DoH DNS server when connecting to a
| VPN which offers internal DNS on Android, for instance.
|
| True. I set my VPN server to force DNS thru the tunnel to
| an intercepting DNS server - and it replies as if it were
| the intended DNS server.
|
| DNS server is setup this way in response to LAN devices
| that have their own DNS configured, but it handles
| Android's private DNS too.
| TheNewsIsHere wrote:
| Aren't all of those concerns out of scope for DNS itself,
| though? DNS can only give you a TTL, for example, it cannot
| require you follow it.
|
| Ideally that's what RFCs are for, but even organizations
| that pay smart people to come up with clever standards
| don't always follow them. Implementations frequently
| disregard or guess about the things standards cover.
| tikhonj wrote:
| From the point of view of the standard, maybe, but not
| from the point of view of somebody learning or using DNS.
| TheNewsIsHere wrote:
| I don't disagree, and I think that's why we need to make
| it clear that there's a difference between implementation
| and standard.
|
| My education is a mix of formal and autodidactic. One of
| the best things I got from formal education is the
| structured introduction to fundamentals like the OSI
| model.
|
| If you don't have that kind of foundation, it can be
| much, much harder to understand the "why" of the endless
| differences between documented standards and in-the-wild
| implementations. It's good to know where you are in the
| stack to help inform what you're seeing.
| neilk wrote:
| How did you learn DNS? And when?
| dahfizz wrote:
| I was tasked with setting up & maintaining a dnsmasq server
| in college, which handled DNS, DHCP, and pxe booting.
|
| I learned it like anything else. Googled it, read the docs,
| and trial & errord my way into a working setup. I was
| comfortable with all the technologies in a couple weeks
| (working part time).
| Terretta wrote:
| > _How did you learn DNS? And when?_
|
| I wrote one of the world's first dynamic DNS servers for our
| dialup modem customers in the early 90s, so when connected to
| our Livingston Portmasters with an assigned IP address you
| could be username.isp.com while online.
|
| Later updated this so you could also be
| http://www.username.isp.com all the time just by dropping an
| index.html file in your ~username/site directory.
|
| I learned both by spelunking BSD, reading man pages, and
| rapid prototyping in Perl. So I'm with tristor, it felt
| relatively straightforward.
|
| // I don't say I wrote the first because I don't know. I am
| not aware of any other regional or national commercial dialup
| ISP in the U.S. that offered this before we did.
| j16sdiz wrote:
| Same here.
|
| I implemented some dynamic dns system. I still remember how
| to handcraft a RRUPDATE request.
|
| After reading the RFC, every bit in dig output makes sense
| tristor wrote:
| I had a slow day at work in the beginning of my career (I was
| a help desk monkey then) and I wanted to learn more about how
| Active Directory actually worked. One of the things that I
| found out and became more curious about was why DNS was so
| critical for Active Directory, upon where I discovered the
| magic of SRV records. After that I decided I wanted to learn
| DNS in detail, so I read the RFCs, poked around with nslookup
| and dig, and then set up a local copy of BIND on a Linux VM
| to experiment with. In the numerous intervening years I've
| picked up more over time and been involved in numerous
| situations where I had to assist someone by doing DNS
| spelunking, often learning something in the process. I jumped
| from being a help desk monkey to being an L2 sysadmin in my
| very next job largely on the basis of my DNS and Active
| Directory knowledge, all of which was learned by reading
| documentation and poking at things, nothing particularly
| difficult about either.
|
| What always causes challenges is weird edge cases, but if you
| understand how things are supposed to work at a protocol
| level you have the basis of knowledge to troubleshoot the
| edge cases, which is how you learn about the more esoteric or
| implementation specific behaviors of things. I wouldn't
| expect anyone to particularly have deep knowledge of AD or
| DNS edge cases, but the basics of how they work aren't
| particularly hard knowledge to acquire and it's a constant
| surprise to me how few tech people understand DNS in
| particular, since it's a critical system for nearly every
| aspect of modern computing.
|
| As far as resources, when learning these things way back when
| I only used the official Microsoft documentation, the RFCs,
| man pages, and sites like nixCraft to learn about it. These
| same resources still exist (although Google sucks now and
| makes anything decent hard to find), and these protocols have
| changed very little in the intervening nearly 20 years, so I
| don't think it's any harder for folks to learn today than it
| was for me back then. This stuff is very literally not rocket
| science, DNS is an extremely basic protocol. In fact, nearly
| all its weird edge cases is because it's such a basic
| protocol that some behavior isn't clearly defined, however
| /most/ behavior is. It's very nearly all text on the wire,
| and all of the zone records, queries, and responses are human
| readable. As someone else mentioned, you can just use
| Wireshark and learn about DNS. It's inspectable on the wire,
| not just through tooling.
|
| FWIW, Active Directory is far more difficult to learn in
| detail than DNS, largely because Kerberos is deeply complex,
| and Active Directory has many unique complexities (like how
| FSMO roles work). DNS in comparison to most other things you
| are expected to know as even a semi-competent systems
| administrators / SRE is mindbogglingly simple.
| WarOnPrivacy wrote:
| Setup an in-house server to sinkhole malware requests.
| jeroenhd wrote:
| I think it is hard to learn... using the tools people used to
| learn DNS with.
|
| BIND is great at what it does, but its configuration files suck
| and its manual is long, terse, and unnecessarily complex
| sometimes. Dig is powerful, but abbreviates everything like
| we're on an 80 column terminal. At times Wireshark was a better
| tool debugging DNS issues than Dig was.
|
| Give someone PowerDNS or another modern DNS server and I think
| they'll have a much better time configuring a working DNS
| server. I don't know a good modern DNS client, so I've learned
| to deal with Dig instead. As a user of the "--color" flag for
| the `ip` command, I'd love to see tools like dig produce more
| modern output (I'll alias the command line flags, just add it
| to the command!)
|
| Seriously, "MSG SIZE rcvd: 71" did not need abbreviation.
| "flags: qr rd ra" could've been full words as well. I don't
| know what the semicolons before the lines are supposed to
| convey but they're only making things confusing.
|
| I find it no wonder people get confused learning DNS with the
| materials provided to them.
| dataflow wrote:
| To the extent I learned DNS, it was via nslookup, definitely
| not dig.
| chefandy wrote:
| I'd conservatively estimate 90% of the people who make core
| FOSS software interface decisions haven't had to learn
| anything technical in an entirely unfamiliar domain where
| there existing mental models didn't apply in _decades._
| Beyond that, many consider having learned these arbitrary,
| terse interfaces as a badge of honor, and for some reason
| thinks that makes them better technologists. I 'll bet they'd
| be even better had they been able to focus on the core
| concepts rather than trying to get into some systems
| engineer's head who worked at Berkley in 1984.
| TheNewsIsHere wrote:
| I think of this in the same way I think of documentation. I
| try to write documentation that is as clear as it is
| concise and well structured. But sometimes that's just not
| realistically possible, and expressing information often
| _has_ to assume some level of familiarity with the
| underlying concepts.
|
| I've never considered DNS to be a complicated technology,
| and I've never considered that tools like dig and the
| abbreviations they use need to change much. If there's
| something that isn't clear, it'll be in the man page, a
| mailing list, Internet based documentation, StackOverflow,
| etc.
|
| Personally, I value information density, and I don't mind
| terseness at all.
|
| That doesn't necessarily mean I would design some of this
| stuff the same way, but after more than a decade using it,
| I feel like changing it now is just an appeal to futility.
| A tool like dig more or less looks and works the same today
| as it did 15 years ago, and there's value in that kind of
| stability.
| dahfizz wrote:
| I disagree.
|
| The CLI is inherently a super-user oriented interface. The
| CLI _needs_ to let an experienced user be as productive as
| possible.
|
| If you need a pretty UI with everything spelled out, you
| should go on GitHub and find a GUI that someone built on
| top of the core tool. But dumbing down the core tool is not
| the way to go.
|
| The --help message should be good, and the man page needs
| to be good, but the tool itself should favor power and
| productivity over handholding someone who doesn't want to
| Google a how-to.
| sdf4j wrote:
| I disagree.
|
| I'm a super-user and as such I have to use hundreds of
| tools to GTD. What you call "pretty UI" I call
| ergonomics. So I appreciate when the tooling is
| respectful of my time and don't require me to visit the
| man page just because the developer was so situational
| myopic that thought sparing a few characters was a good
| idea.
|
| It all smells like unconscious gatekeeping.
| tmpX7dMeXU wrote:
| This is full of false dichotomy. Making things more
| understandable isn't "dumbing them down". There isn't
| necessarily a trade-off. An application being CLI-based
| is not a get out of jail free card for UX critiques, nor
| is it an implication that it's for power-users. You can't
| just put the minimum viable effort into considering how
| someone will use your software without any thought to
| intuitive mental models and cry "it's for power users".
|
| Old-school FOSS nerds have a hard time admitting that
| they tend to be absolutely useless at considering user
| experience, because then that's something On Computers
| that they're not good at. The best they can do is shoo it
| away by claiming that the sort of UX concerns I'm talking
| about only apply to software used by Lesser Beings and
| not Smart Computer Boys such as themselves.
|
| It's such an outdated user-hostile boys club attitude
| fuelled by insecurity and misplaced and not even well-
| thought-out elitism, and I'll never pull any punches when
| talking about it.
| hitpointdrew wrote:
| > nor is it an implication that it's for power-users.
|
| Yes it is. As an administrator being a CLI tool means
| that I can automate configs and deployment with ansible
| or Nix OS. I would argue doing these sorts of automation
| what are what "power-users" would do.
|
| GUI's often lack any sort of automation capability or
| have some half-cocked API that usually lacks features or
| endpoints that would be trivial if the thing was just a
| CLI tool with a config file.
| zehemer wrote:
| > As a user of the "--color" flag for the `ip` command, I'd
| love to see tools like dig produce more modern output
|
| https://github.com/ogham/dog is pretty good in that regard
| j16sdiz wrote:
| rcvd, qr, rd, ra
|
| are defined in the RFC. It need the abbreviation to fit in
| the ASCII art in RFC text.
|
| back in those days, dig users are those who read rfc
| jeroenhd wrote:
| I can see that they were truncated in the block diagram,
| but they were also explained with one or two words just
| lines below that. RFC1035 calls them "query"/"response",
| "authoritative answer", "Truncation", "Recursion Desired",
| "Recursion Available", and CD/AD become "Checking Disabled"
| and "Authentic Data".
|
| dig already translates things like record types from
| integers to strings, why not use the full, descriptive
| names for these flags as well? Why shouldn't I be able to
| dig +pretty domain.example?
|
| I suppose dig is mostly maintenance mode these days, but
| it's quite annoying to see so many tools rely on it when
| it's so... 90s.
| knome wrote:
| >I don't know what the semicolons before the lines are
| supposed to convey but they're only making things confusing
|
| all of the lines that aren't part of the query answer are
| prefixed with semicolons. so it's basically a comment
| character. presumably to ease processing of the data it spits
| out.
|
| You know. So you can `dig google.com | grep -v '^;' | grep .
| | awk '{ print $5 }'` easily.
|
| I can imagine people using it in a shell script 20 years and
| more ago to grab a list of IPs to do some domain's health
| check or whatever
|
| Not that you would want to in any modern stack. obviously
| you'd just use dig's `+short` option :)
| tux1968 wrote:
| > dig google.com | grep -v '^;' | grep . | awk '{ print $5
| }'`
|
| It wasn't really your point, but hopefully you'll forgive
| me sharing an equivalent one-liner, without grep:
|
| dig google.com | awk '/./ && !/^;/ {print $5}'
| redundantly wrote:
| I believe both you and the parent meant to escape the
| dot, as to only return lines with a dot in them:
| dig example.com | awk '/\./ && !/^;/ {print $5}'
|
| If it isn't escaped it'll just match on everything.
|
| If matching everything was intended then you don't need
| it at all: dig example.com | awk
| '!/^;/ {print $5}'
|
| Will strip out the lines beginning with a semi-colon.
|
| However, parsing the output of `dig` this way is not
| needed. It can be ran to only return the answer, for
| example: dig +noall +answer
| example.com
|
| Or if you just want the IP for that record:
| dig +short example.com
| knome wrote:
| I was actually just using `grep .` to discard empty
| lines. The `grep -v '^;'` would have only left lines with
| answers after it discarded lines starting with `;`. That
| and the empty lines.
|
| I could have combined `grep -v '^;'` and `grep .` as a
| nice simple `grep '^[^;]'`
| redundantly wrote:
| Ahh. I was working from memory, I forgot about the empty
| lines it returns. That's what I get for replying from my
| phone. :)
|
| However, it's still better to just have the `dig` command
| return only the necessary information via the +short or
| +noall +answer flags, rather than parsing the full
| output.
| pests wrote:
| Remind me again where this weird syntax came from for
| passing arguments?
| [deleted]
| [deleted]
| jeroenhd wrote:
| Now I just wonder what the double semicolons mean and why
| they're different from single semicolons :) It's fine, I
| can Google the answer, I just wished I didn't need to.
|
| I already know to use +short when I just want the
| result(s). I use it in a script to detect and resolve my
| Pihole's random freezes (by timing the lookup and rebooting
| the VM every time a lookup fails or takes longer than
| 200ms, janky but it works).
| dclowd9901 wrote:
| Perhaps there is info that would normally be present and
| isn't, hence stacked semicolons.
| skrebbel wrote:
| A precision engineering tool shouldn't make its users
| guess like that.
| j16sdiz wrote:
| BIND expose (almost) every details of DNS. That's why
| learning their config would teach you 90% of the DNS system.
|
| dig output make sense after reading the RFC. It exposes every
| bit flag in the protocol level
| jeroenhd wrote:
| I have read the RFC. I just don't mess with DNS often
| enough that I know all the RFC definitions from the top of
| my head, and I don't want to need to find the appropriate
| RFC(s) every time I want to debug an issue.
|
| It's not as if tools like wget bother you with http/3 spec
| fields every time you download something from the internet
| unless you explicitly ask for them, and even if they do,
| they're more descriptive than just the shortcode coming
| from a diagram in the RFC.
| bombcar wrote:
| >I just don't mess with DNS often enough
|
| That's the root of all this, we only deal with DNS when
| something breaks, and it rarely breaks.
|
| If we did DNS all day every day it'd all be super clear
| and concise.
| manuel_w wrote:
| $ ip address --color Command "--color" is unknown, try
| "ip address help".
| matteotom wrote:
| try
|
| > ip --color address
|
| otherwise you might just have an old version
| manuel_w wrote:
| That helped, thanks!
| synergy20 wrote:
| or: ip -c -br a which is: ip --color --brief address add
| -4 if only ipv4
| thunderbong wrote:
| Because the only three hard problems in computer science are
| cache invalidation and naming things.
|
| And DNS is a caching system for names of things.
|
| https://reddit.com/comments/15c2ul2/comment/jtty9dy
| yard2010 wrote:
| Also, off by one errors, which is implied
| andrethegiant wrote:
| Julia also created this comic about DNS, which is helpful for
| learning: https://wizardzines.com/zines/dns/
| laserbeam wrote:
| Here's what's cool about the article:
|
| - Presents some nice theories which make things hard to learn
| (infrequent use, poor tools...)
|
| - Describes how DNS tools could be improved.
|
| - Gives you a few gotchas for how one may shoot themselves in a
| foot with DNS.
|
| Here's what's a bit (not much) less cool:
|
| - I really have no clue if those things ACTUALLY make things hard
| to learn (because it's not a research paper on learning).
|
| - It's a plug for other content on the side which actually
| describes the DNS protocol. I'll admit the sold content looks
| cool. I haven't purchased and can't vouch for the actual quality.
| dgb23 wrote:
| As for the last point: Check out the author's blog. She's a
| real hacker and can convey technical things in friendly and
| simple terms.
| mgaunard wrote:
| DNS is hard because cloud/web companies insist on taxing you to
| do very basic things.
| iAm25626 wrote:
| I used to specialized in these service enable services.
| DHCP/DNS/AAA/LDAP and etc; low level stuff tend to get take for
| granted. It's not difficult but there are much nuances. Not
| typical visible to layer7/Front end development per se. Embrace
| the "and". If you are a FE/BE dev AND understand
| system/dns/network. You just set yourself apart from the next
| person.
| swayvil wrote:
| Because complexity is easy. It practically generates itself. It
| has a natural economic advantage.
|
| Making sense of complexity, otoh, takes much diligent effort.
|
| So complexity tends to win and everybody tends to befuddlement.
| echan00 wrote:
| I thought you talking about aws lol
| roomey wrote:
| There's an old saying: if someone tell's you they know how DNS
| works, they're lying
| dap wrote:
| I went through this a few years ago, deciding that I had only a
| piecemeal understanding of DNS based on the specific things I had
| run into. I knew about `dig(1)` and BIND and a CS101 idea of how
| recursive DNS resolution works, etc. But I was missing the
| working knowledge needed for designing and implementing anything
| non-trivial or for debugging non-working systems. So I read "DNS
| and BIND" (not quite cover-to-cover, but close, skipping over the
| details on some of the more exotic features). I set up a real
| BIND server for some unimportant personal web sites. None of it
| was hard, but it did involve a bunch of (time) investment. To be
| clear, BIND is not the right thing for many use cases, but a lot
| of DNS ideas and terminology still come from BIND and I found
| that stuff very valuable.
|
| I think books are underappreciated for learning stuff like this.
| Most resources you find on the web are high-level theory ("here's
| a block diagram of how recursive lookup works"), task-oriented
| ("how do I get `dig` to do a recursive lookup"), or otherwise
| low-level (e.g., reading the source of your local DNS client to
| understand its retry policy). To understand the pieces and how
| they fit together, from the theory (what they're trying to
| achieve) down to implementation (what caches exist where), I find
| there's no substitute for a holistic approach that you usually
| find in books, but rarely (not never) find on the web.
| hairui wrote:
| TIL that `dig` does not have TLDR page https://github.com/tldr-
| pages/tldr
| teunispeters wrote:
| One of the gotchas I encountered is that DNS is asynchronous,
| with possibly a long delay before reply. C apis make it look
| synchronous - which I think makes it harder to work with. There's
| also the detail that order of replies can be any. (I found too
| many developers expected synchronous and instant replies)
| lanstin wrote:
| with the caching, it's a nice bimodal distribution, 99.99$ 0 ms
| response time, 0.01% 30 ms response time (with a small chance
| of having that query packet be dropped, with retries in the
| 1000s of ms). I've seen people write caches that use the old
| value and kick off a new query in the background to hopefully
| populate the cache again.
| NoZebra120vClip wrote:
| I remember the mid-90s when we were writing MUD servers and
| clients. You'd start the client, go "/world ZebraMUCK" and then
| the TUI would hang while the DNS name resolved.
|
| So then we figured out asynchronous DNS (this was in the days
| when you linked with "-lresolv" on SunOS) and it was like a
| breath of fresh air! You could go "/world ZebraMUCK", control
| was returned to the keyboard, and even if it took 120 seconds
| to resolve zebramuck.nozebra.example.com, you could go about
| your business, like in another world, or issue some other
| client commands.
|
| And client developers learned a little about select(3).
| magicmicah85 wrote:
| "(like, what if you could run dig +debug google.com and it gave
| you a bunch of extra debugging information?)"
|
| The flag they're looking for is +trace and it provides exactly
| what they're looking for which is a path of how resolution occurs
| from root nameservers all the way down to the domain.
| jstx1 wrote:
| People who use their DNS knowledge often - what is your job and
| problems do you solve with your DNS knowledge?
| m3047 wrote:
| I use DNS to define topology and services (what you'd expect)
| and of late I'm using it for federating telemetry (the actual
| data; think of "tags" in the industrial control sense).
|
| I've used it as an observable for asset discovery and
| classification, as well as for characterizing infrastructure.
| andrewfromx wrote:
| sometimes it's hard to even know WHERE to change the settings.
| Last week a friend was trying to setup heroku with api.foo.com
| and he needed to add a CNAME to the domain so heroku would make
| the cert and turn it on.
|
| I used dig, i used host, I used whois, I got invited to their aws
| route 53 and saw all sorts of stuff in there but each change had
| no affect. Finally I noticed from whois that the name servers
| weren't even aws they were google.
|
| So they gave me access to the google account but no domains in
| there.
|
| Finally I asked, have the CEO log in to his personal google
| account and sure enough, that's where the change could be made.
| shadowgovt wrote:
| This. The protocol isn't hard, but the protocol isn't the
| service.
|
| The _service_ of DNS is a decentralized, distributed, held-
| together-by-spit-bailing-wire-and-an-unprecedented-post-WWII-
| era-of-international-peace-and-collaboration hash-job of
| individually configurable nodes _kind of_ agreeing on a shared
| worldview of the information the service contains, unless your
| local government hates piracy or pictures of Winnie the Pooh,
| YMMV.
|
| It's like saying "I don't know why people struggle with
| databases; SQL isn't hard" and then the database contains ten
| thousand tables, a thousand indices, a hundred functions and
| triggers, and all of it was documented by someone who built it
| and never had a neophyte review the docs.
|
| Oh, and the database operates on eventual-consistency
| guarantees out to 24 hours of "eventually."
| 1bent wrote:
| djbdns is simple, easy to understand, easy to configure; it
| embodies a clear understanding of how DNS works.
|
| Unlike BIND and dig, it was designed after DNS had been in use
| for a while.
|
| Like sendmail, BIND suffers from being designed before anyone
| knew what it would need to do.
| fullstop wrote:
| I still use tinydns, but I've moved on from dnscache to
| unbound.
|
| djbdns was a great tool, clearly built with security in mind,
| and it forced you to understand how the whole system worked. It
| struggled with things added later like txt and srv records but
| they could still be added.
|
| qmail was also well ahead of its time.
| rconti wrote:
| and logging in hex is awful and should be punished
| egberts1 wrote:
| Doing:
|
| bastion named server
|
| Multizone
|
| Hidden Master
|
| Split-Horizon
|
| IXFR/AXFR firewalling
|
| DNSSEC and local network
|
| resolv.conf hijacking
|
| Remote admin security
|
| All of above would and should be hard.
| shon wrote:
| It's not. It's one of the few things that hasn't changed much and
| it's operation is fairly straightforward.
|
| dig is a little confusing. It's more capable but less
| straightforward than good old nslookup (which still works fine
| BTW).
|
| I think partly DNS and the core protocols may seem confusing to
| younger people in the industry because so much stuff "just works"
| now.
|
| For example, today wifi routers "just work" right out of the box.
| In the early 2000s it would have taken a network engineer with
| knowledge of DNS, IP, Ethernet, RFC1918, actual routing protocols
| and whole bunch of other stuff to set something like that up and
| they'd have well known how it worked and why it was configured
| the way it was.
|
| If you think DNS from a client can perspective is confusing, try
| configuring BIND ;-)
|
| /OldNeckBeardRant
| monksy wrote:
| I just wanted to add on to what you're saying:
|
| > I think partly DNS and the core protocols may seem confusing
| to younger people in the industry because so much stuff "just
| works" now.
|
| I've noticed it's become much worse since universities have
| been teaching Python to start with and with the whole
| aggressive comodization of developers. To some extent the
| social justice polices inacted in our communities to exclude
| people*. ("unsavory" people)
|
| We no longer have the culture where we had kids in early ages
| get a desktop, learn the ins and outs, play video games, trying
| to pretend to be a hacker, etc. We're getting developers who
| barely can script in javascript, barely do html, ignore the
| edge cases, and generally don't have a lot of interest in the
| craft. It's pretty frustrating to see this.
| Arcanum-XIII wrote:
| I don't know, I would be curious to meet out of school dev
| from 20 years ago. Those I meet at my current job are...
| young. The lack of experience shows.
|
| I guess at the time I was not better. Different, because
| using C I could still destroy hardware. Hard to program a CGA
| card from Python :D Maybe with MicroPython on an arduino now?
| fipar wrote:
| > I don't know, I would be curious to meet out of school
| dev from 20 years ago. Those I meet at my current job
| are... young. The lack of experience shows.
|
| I was a stil-at-school dev/sysadmin/multi-purpose nerd 23
| years ago, if that works, nice to meet you!
|
| I had more experience than average on some tasks because I
| was lucky enough that, against my own will, when I was a
| little kid my parents bought a computer and not a videogame
| console. I still spent most of my time in front of it
| playing games, of course, but I also learned to program a
| little bit, and by the time we had our first PC at home, I
| also learned troubleshooting because every time I broke it
| I had to get it working before one of my parents needed it.
|
| Other than that, I think school prepared me well in terms
| of foundations (perhaps better than what some kids see
| today, at least I'm surprised how few people who went
| through formal CS/SWE university training recently know
| enough about the reasons the relational model was
| introduced, or how operating systems work).
|
| On the other hand, practical skills taught at school were
| not immediately useful to me. In particular, the software
| stack most used at school (Pascal, then Delphi, we did have
| some courses using C, Prolog, ASM, COBOL, and SQL, but most
| of my programming hours in school were spent in
| Pascal/Delphi) was not used in any of the jobs I've had,
| with the exception of COBOL), so I did a lot of learning on
| the job.
|
| I make a living working on databases now, and I sometimes
| like to tell the story of how I got into them: while
| working at a bank, the web banking application had an SQL
| Server backend database for its frontend (actual banking
| happened in another network, on a mainframe, I don't know
| which DB it used but it was some IBM thing and it was not
| DB/2). There was a settings table that was basically a
| key/value store controlling different config options of the
| app. One of them was a maintenance flag which, if set to
| whatever the value for true was, would show a "we're under
| maintenance" page when serving any user request. One day
| they asked me to go put the site on maintenance ("go put
| the site" because I had to go walk upstairs and enter the
| datacenter to do this back then), so I went to the console,
| opened the query editor, and entered something like:
|
| update settings set value = 1;
|
| Notice the lack of a where clause. When I saw the number of
| rows affected, I panicked, ran downstairs, explained what I
| had done, and a colleague (who was also young but I think
| at his second job after school, and way more experienced
| than me) calmed me down, walked up with me again, showed me
| where the backups where, and helped me restore one.
|
| I've been hooked on databases since that day!
| NikolaNovak wrote:
| I may agree with your point but don't understand the social
| justice aspect at all; makes it feel like it's something just
| added in. I think both our perspective as a society and
| thereforo educational goals have changed over decades,
| laterally to any social justice aspect. If nothing else,
| there are order of magnitude more developers of all sorts
| today than 25 years ago, both as absolute numbers and as
| relative percentage of population. Basically the enthusiastic
| nerds who geek out about anything and everything and want to
| be hands on are still there, but also a LOT of people who
| just want a paycheck or just have more limited / specific
| interests. And they do ok. And education system will provide
| for them.
|
| But I just don't see e.g. for-profit bootcamps with their
| simplified curriculum as any kind of social justice project.
| Spivak wrote:
| And when there is social justice or involved it's about
| getting more people involved in engineering. I can see
| where "hey, quit being gross to women" can be read as
| excluding the unsavory but that framing presumes that a
| world where that's an intrinsic immutable property of a
| person.
|
| I really don't buy the "some people just can't help being
| an asshole so having a rule against assholes is
| exclusionary." The most controversial CoC is by far the
| Contributor Covenant and rules are be kind and empathetic,
| show others respect, don't insult or demean others, don't
| be creepy or sexually harass others, don't doxx people, and
| behave like adults at work. Like the bar is _so low_.
| monksy wrote:
| This is kind of where I was going with that, but I don't
| agree with the way its being described. I 100% agree with
| cracking down on individuals who are hostile based on
| identity, that was unreasonable and should continue to be
| excluded from projects.
|
| The history of the developer circles is that we've been a
| bit rough with the language. (mount, finger, touch, zip,
| etc are perfectly acceptable things for linux commmands..
| theres even a joke about it). Unsavory jokes in mailing
| list/code bases, etc. However, we've come upon a bunch of
| people who take the aggressively negative view on the
| words and interactions used and have taken it upon
| themselves to rename things and force changes.
| (Master/main, master/slave, whitelist/blacklist, [theres
| a whole list of these "undesirable" language things] etc
| ).
|
| On top of that the CoC has implemented toxic positivity
| rules on projects. Implementers overlook the fact that
| they have been used as a weapon to be put in the project
| it's self. (There have been examples of racial, and
| gender based discrimination in the enforcement of the
| rules)
|
| All of this brings in people who do not contribute in a
| UX, DX, engineering, management sort of way. Even when
| these things are abused/enforced poorly it still has a
| significant silencing effect and distancing effect from
| those who would be a positive contributor but is
| reluctant to participate.
| monksy wrote:
| The SJ part I gave more context in a reply to: Spivak
|
| But to address the level of statements: I see SJ as one
| part of it, not the only or major part.
|
| > enthusiastic nerds
|
| Maybe it's the spaces I'm in but I'm not seeing that these
| days. I'm not hearing about personal projects people have
| made anymore. I'm not seeing a lot of enthusiastic young
| presenters at conferences etc. I'm just seeing younger
| people trying to stand out in the rat race and they aren't
| similar to when I was growing up. (I.e. lan parties,
| identifying as nerdy people and grouping together, etc).
|
| The last young person I recall being like that was a guy
| who did a presentation on using Joycons at Scaladays 2017?
| This was a kid that did have experience in the us first
| robotics group. But f me.. a high schooler pretty good at
| Scala.. that's awesome!
| fipar wrote:
| > But I just don't see e.g. for-profit bootcamps with their
| simplified curriculum as any kind of social justice
| project.
|
| And you're right not seeing them that way!
|
| While I'm sure there are now good-faith bootcamps that have
| the goal of improving the career options of people who may
| otherwise never get those, the first time I saw the
| programming/sysadmin bootcamp concept implemented was
| around 2002, where a company was recruiting kids still in
| high school to train them for their openings.
|
| They did that because there were not enough skilled IT
| workers back then. Right, what that really meant is, they
| did that because there were not enough skilled IT workers
| they could afford back then. Someone did the math and
| estimated that for some openings, it would be more
| profitable to train first-time-job-seekers (in a lot of
| cases, not-yet-job-seekers) than to offer a better deal.
| They're still in business so I guess it worked!
| deltarholamda wrote:
| >It's one of the few things that hasn't changed much and it's
| operation is fairly straightforward.
|
| It's relatively straightforward, ignoring all of the potential
| ways that things can go wonky, e.g. random servers not
| respecting TTL.
|
| But I'll never forget when Firefox put out an update with DNS-
| over-HTTPS turned on by default. All of a sudden, I was
| inundated with "Email is gone! Everything is broken!" because
| we run an internal DNS server handed out to workstations by
| DHCP. We have internal webmail and intranet Web servers that
| were just gone.
|
| It took a lot longer than it should to figure out what was
| happening, partially because it's DNS! Why should things go
| blooey? But it's pretty clear that Mozilla did not anticipate
| this (easily forseen, IMO) sort of issue.
| throw0101b wrote:
| > _But I 'll never forget when Firefox put out an update with
| DNS-over-HTTPS turned on by default._
|
| Plenty of DNS old timers / neckbeards (e.g., Paul Vixie)
| warning that DoH was not a good idea; there was lively
| discussion on HN at the time.
|
| We used split-horizon DNS as well and I implemented the
| "disable DoH" canary where I was working at the time.
|
| * https://support.mozilla.org/en-US/kb/configuring-networks-
| di...
|
| * https://support.mozilla.org/en-US/kb/canary-domain-use-
| appli...
| icedchai wrote:
| I agree. I remember learning about DNS when I was a teenager.
| And I've been running my own authoritative DNS servers for
| almost 30 years now. Remember the O'Reilly book, "DNS and BIND"
| ? It's still out, those this would've been first edition,
| around 1993.
| alexjplant wrote:
| When I was 14 I (poorly) administered an Active Directory
| environment with mail, web, and CIFS for a restaurant without
| understanding DNS or DHCP. Instead of setting the WRT54G's DHCP
| server to hand out the domain controller's static IP as the DNS
| server for proper name resolution I just used IP addresses and
| host file entries to make everything work. I also had the MX
| record for the domain set to the router's WAN IP and didn't
| have any PTR records set - the fact that e-mail delivery went
| as smoothly as it did is an absolute miracle in retrospect. A
| few years later I figured out how DNS actually worked and in my
| early 20s I inherited a corporate intranet where BIND was used
| as the nameserver for all external corporate domain zones.
| Moving this setup to VPSes for increased reliability taught me
| a _lot_ (mostly zone transfers, SOA, etc). I'm grateful for the
| experience but these days everything is pretty much done for
| you so this is a low-value activity... "IT" isn't valued the
| same way that "software engineering" is for better or worse.
| TheNewsIsHere wrote:
| This is why I continue to maintain that ops and SE excel at
| remaining distinct fields, though I certainly don't mind
| overlap.
|
| Most of my friends are software developers and/or software
| developers working on cloud-based stacks.
|
| Two of those friends lead the platform engineering groups at
| their respective companies. One of them has a very basic
| understanding of networking and could figure out how to do
| subnetting that didn't come out of the box, but they'd need
| to stop and go learn that.
|
| That isn't everyone by any stretch, but I see it more often
| than not these days.
|
| I agree fully with the idea that younger professionals aren't
| as used to the infrastructure underneath the infrastructure
| being as complex as the higher layers of the OSI model that
| they're frequently more experienced with.
|
| What I hope we don't end up with is a future where all the
| data center people and all the network engineers (and so on)
| are almost exclusively employed by a small number of mega-
| corps. It's important that knowledge and experience in the
| fundamentals of the networked world remain widely distributed
| and openly accessible.
| bdavbdav wrote:
| Same boat at a similar age. (Ab)using AD taught me a lot
| about DNS, largely after the fact. Lots of "so that's why
| that didn't work..." moments later down the line.
| haroldp wrote:
| Can you help me find the mistake in my zone file?
| $ORIGIN example.net. $TTL 900 @ IN SOA
| ns1.example.com. hostmaster@example.com. (
| 20230728001 1800 300 3600
| 172800 ) @ IN NS 8.8.8.8. @
| IN NS 8.8.4.4. @ IN CNAME example.com.
| @ IN MX 10 172.253.124.27 www IN CNAME
| example.com
| somat wrote:
| Also the CNAME if you have a cname you don't want any other
| records with the same name. It ends up being a confusing and
| ambiguous situation to be if. You are supposed to use the
| cname to jump the the actual record. but now there is also a
| MX record here are we supposed to do anything with it?
| throw0101b wrote:
| Off the top of my head (haven't had to do zone files for ~2
| years):
|
| * hostmaster@example.com -> hostmaster.example.com
|
| * NS records are usually hostnames (not sure if IPs are even
| valid)
|
| * Ditto for MX records ; also add a period to the end,
| otherwise example.net will get appended
|
| * Also appending with the www record
|
| See also:
|
| * https://linux.die.net/man/8/named-checkzone
| TheNewsIsHere wrote:
| To add --
|
| You can do delegated zones by specifying NS records for a
| subdomain within the parent zone. If you're talking about
| NS for a second level domain ("example" in example.com) you
| would want glue records which are essentially a "lookaside"
| to prevent circular dependencies. Glue records are really
| just A records with clout, returned with the IP of your
| name server. This glue is maintained by the higher level
| authoritative zone. So you query for example.org and the
| nameserver for .org returns ns1.example.org as the name
| server for your zone, as well as the IP address for that
| server.
|
| This is why you could run a DNS server at ns1.example.org
| as your authoritative DNS.
| xtagon wrote:
| The downside to things that "just work" is that they become
| magical black boxes where learning how they work isn't a
| requirement until things _really_ go wrong.
| cduzz wrote:
| These things you're talking about are a small fraction of DNS
| though.
|
| For instance, you lookup "thing.behind.cdn.it" and get one
| answer, someone else looks up the same thing and gets a
| different answer. Pretty obvious, but when someone asks the
| reasonable question "can you open a firewall hole for
| thing.behind.cdn.it"
|
| Some servers forward requests, some delegate, some will look
| stuff up for you others won't. And there's the magic with
| search domains on clients, and if clients or internal resolver
| libraries will honor TTLs or not.
|
| There's also the myriad different types of records, and
| sometimes the server will tell you to reconnect in TCP instead
| of UDP, etc.
|
| So -- DNS is pretty complex; it has the illusion of being
| simple because it works so well and most of the fiddly bits are
| abstracted away by stuff that mostly just works.
| donretag wrote:
| That is what I assumed as well, until one day I got hit by a
| bug involving Extension Mechanisms for DNS (EDNS). Never knew
| it existed. All of a sudden DNS was failing and could not
| understand why. Took me a long time to fix the issue.
| WarOnPrivacy wrote:
| > For example, today wifi routers "just work" right out of the
| box. In the early 2000s it would have taken a network engineer
|
| Or a nerd buying a WRT54v1 to install hyperwrt.
| arjvik wrote:
| Is configuring BIND hard just because it's got an obtuse zone
| and configuration format? Or because there are a lot of DNS-
| server-level decisions that need to be made?
| Arcanum-XIII wrote:
| Yeah, BIND is hard to configure. Unbound/nsd are so much easier
| to deal with (once you find the correct documentation which is
| an exercice in frustration)
|
| The principle behind DNS are not that hard, once you understand
| it's recursive. Now to configure it with security in mind, the
| proper infrastructure and the final details... lot of things to
| learn, but not that hard. Without BIND I mean.
| vel0city wrote:
| Linksys was making home routers which were about as easy to
| deploy as any home router today starting in 1999. Their
| earliest Wireless G router came out in like 2002. The beloved
| WRT54GS came out in 2003.
|
| https://arstechnica.com/gadgets/2000/08/befsr41/
| KRAKRISMOTT wrote:
| Many modern APIs are more ergonomic and easier to use due to
| the benefits of hindsight. A redesign and upgrade of DNS is
| long overdue.
| bityard wrote:
| Pretty much what I came here to say. As a young system
| administrator, DNS was the second thing I learned after setting
| up my first Apache server and I didn't find it hard to learn at
| all.
|
| I will admit that it when you get to a certain point, you have
| to be careful not to shoot yourself in the foot when operating
| a production system but that is a slightly different concern
| which is more implementation dependent. Eg BIND.
| hiAndrewQuinn wrote:
| Re/ knowing older protocols, I recently took a few weeks to
| read _Networking for System Administrators_ and take+review
| copious Anki card notes. It's incredible just how much more
| confident I feel around understanding networking at a high
| level, including both DNS and all the stuff underneath it, like
| `ethtool` and Ethernet frames and stuff.
|
| I suppose this isn't surprising, since knowing things "from the
| ground up" is why I went for electrical engineering instead of
| CS in college.
| gjvc wrote:
| 20 years after doing a CS degree, I wish I had done EE
| instead.
| orangepurple wrote:
| If that is the case why is the recommended way to use DNSSEC is
| to turn it off?
|
| https://www.fastmail.com/blog/dnssec-dane/
| yodsanklai wrote:
| > I think partly DNS and the core protocols may seem confusing
| to younger people in the industry because so much stuff "just
| works" now.
|
| Younger people aren't dumber than old one, they build even more
| complex stuff on top of these old abstractions.
| vichle wrote:
| Because all great developers create More complexity (-:
| mrits wrote:
| A network engineer or a teenager motivated to communicate with
| his girlfriend when not at his dads office.
| dv_dt wrote:
| DNS concepts are pretty straightforward, but I agree with the
| article that there are a lot of little holes to fall into. No
| mention in any thread on dig vs /etc/hosts. Or of ISPs with bad
| actor DNS behavior... etc..
| redeeman wrote:
| > In the early 2000s it would have taken a network engineer
| with knowledge of DNS, IP, Ethernet, RFC1918, actual routing
| protocols and whole bunch of other stuff to set something like
| that up
|
| You remember things differently than I
| fps wrote:
| in the very early 2000s, home routers weren't a thing. Cable
| modems hooked up to a single computer. If you were a
| business, you got a PIX, but home setups were frequently done
| with a computer that had 2 ethernet ports and either used
| Windows's "home internet sharing" or Linux's ipchains and
| NAT. This was typically fine, because very few houses had
| multiple computers. I knew many people who would get a
| separate cable modem for each computer in their house.
|
| By the mid 2000s, Linksys started coming out with their
| little WRT routers, which were affordable by home users and
| mostly just plug and play.
| icedchai wrote:
| What you describe is late 90's, not early 2000's. Broadband
| was rolling out across many areas of the US in the late
| 90's (@Home cable modems, DSL, etc.)
| icedchai wrote:
| Me too. Plug-and-play consumer wi-fi routers were common
| place by the early 2000's.
| hackboyfly wrote:
| I actually tried to learn about sockets today. I gave it around 3
| hours but I never reached the end of the rabbit hole which led me
| to give up.
| ertian wrote:
| 'Still'? There's a famous talk[1] in the network community about
| how DNS complexity is growing so fast that effectively _nobody_
| can keep up with it. There 's so many competing, overlapping, and
| overriding RFCs that it's hard to make sense of it anymore.
|
| [1] https://blog.apnic.net/2018/03/29/the-dns-camel/
| mkeedlinger wrote:
| I found out about https://www.nslookup.io/learning/ recently,
| which greatly increased my knowledge of DNS. If you look at the
| list of DNS record types [0], you might be surprised at how many
| their are. Knowing how to use those can be a bit much.
|
| [0] https://www.nslookup.io/learning/dns-record-types/
| teddyh wrote:
| > _the list of DNS record types_
|
| Actually authoritative list:
| <https://www.iana.org/assignments/dns-parameters/dns-
| paramete...> That list also has linked references for each
| entry, whereas the list you gave only has references for 9 of
| the 51 types it lists.
|
| If we exclude entries explictly marked as experimental,
| obsolete, deprecated, or reserved, the list you gave is still
| missing these:
|
| * AMTRELAY
|
| * ATMA
|
| * AVC
|
| * DOA
|
| * EID
|
| * GPOS
|
| * ISDN
|
| * L32
|
| * L64
|
| * LP
|
| * MINFO
|
| * NID
|
| * NIMLOC
|
| * NINFO
|
| * PX
|
| * RKEY
|
| * RT
|
| * SINK
|
| * SPF
|
| * TALINK
|
| * WKS
|
| * X25
|
| (I know, many of these are de-facto deprecated: SPF is
| abandoned for TXT, GPOS was replaced by LOC, and the entire
| usage of WKS was obsoleted by the recommendation of RFC 1123.
| But they are not marked as such in the list from IANA, and I
| still often see SPF records in the wild.)
|
| Also incomplete, but often has better references:
| <https://en.wikipedia.org/wiki/List_of_DNS_record_types>
|
| (Not to mention TYPE, which I have also occasionally
| encountered.)
| labcomputer wrote:
| These all seem to be super-niche or obsolete though?
|
| * ATMA, ISDN, NIMLOC, EID, X25, are all for relatively niche
| or obsolete physical layer protocols (I guess ATM isn't that
| niche, but most people never run into it).
|
| * WKS, PX, NID, LP, L64, L32 seem to be defined but unused in
| practice (I had never even heard of ILNP, which what NID, LP,
| L64 and L32 are for, until I googled it just now).
|
| * RKEY, NINFO, MINFO and several others are expired without
| adoption or never made it to an RFC
|
| * GPOS is an earlier version of LOC
| joshcafe wrote:
| Shameless side project plug: they mention a "debug" mode for dns
| resolving being nice to have. ComfyDNS has this in its web UI :3
|
| https://comfydns.com/
|
| It's the picture that says "TRACE google.com A IN" at the top.
|
| ComfyDNS is partly scratching a personal itch - I was tired of
| hand modifying bind9 zone files. And also I was curious as to how
| DNS works - I knew surface level stuff but no details. So I
| implemented the RFC from "scratch" (I used netty but no DNS
| libs). It was a lot of fun.
|
| (Also if/when the site goes down from hugging, forgive me, it is
| a rails app running on the oracle cloud free tier lol)
| chaps wrote:
| One of the best, but also strangest explanation of DNS I've seen
| is from "A Cat Explains DNS". It's wonderful.
|
| https://www.youtube.com/watch?v=4ZtFk2dtqv0
| Spooky23 wrote:
| DNS is easy in the same way that chess is. The game mechanics are
| straightforward, and it gets more complex from there.
|
| DNS bears the burden of delivering you to complex IT systems.
| It's abused in various ways to enforce geographic restrictions,
| service levels, etc. It generally works, so long as everyone
| upstream knows how to configure things so that downstream things
| they don't know exist work well.
|
| When things don't work... that's not easy.
| gunapologist99 wrote:
| It's probably a good idea for all IT people to have a working
| knowledge of how to debug DNS issues.
|
| DNS has historically been a vector for _significant_ security
| holes and it 's likely that this will continue to be true for the
| indefinite future. These holes also lead to other vectors in
| nearly every other protocol like SMTP. Even the CA system used
| for HTTPS is highly dependent on a basically insecure protocol.
| (Would you notice if your bank bought a DV certificate instead of
| OV? likely not)
|
| So, perhaps it's not such a bad thing that it _seems_ hard to
| learn to those who don 't have enough interest, since even now we
| see people building DNS things without taking the time to really
| understand the history of things like port randomization, cache
| poisoning, AXFR, etc.
| dgb23 wrote:
| It seems to me that everything which broadcasts/asserts routing
| decisions in a network (any layer) is deceptively simple and
| potentially dangerous.
| chasd00 wrote:
| > deceptively simple and potentially dangerous
|
| Also, there's not a lot of people keeping the whole thing
| running. iirc there's only like 13 or 14 root DNS servers on
| earth.
| bratgpttamer wrote:
| I feel like DNS is one of the more straightforward protocols,
| especially on a practical level, and especially given that most
| interfaces are a dropdown and two text boxes.
|
| I have noticed a lot of developers shy away from it, probably
| because they don't use it much or it's not their job (rather than
| it being hard).
| paulddraper wrote:
| "Dropdown and two text boxes" undersells it.
|
| Here is the list of several dozen record types:
| https://www.iana.org/assignments/dns-parameters/dns-paramete...
| naniwaduni wrote:
| Yeah, that's the dropdown.
| bratgpttamer wrote:
| Sure, but I'm talking about a day-to-day practical level.
| Most people will only ever need to modify A/CNAME, occasional
| MX and TXT, and _maybe_ an SOA /PTR.
|
| Even the more arcane record types (as far as I've ever used
| them) are essentially key-value pairs with the record type
| analogous to a namespace.
| paulddraper wrote:
| AAAA
|
| Also NS is reasonably common.
| msie wrote:
| Exactly. Why waste time learning something I will only use once
| or twice a year or 10 times in my career? Or that someone else
| (who is an expert) can fix for me?
| dclowd9901 wrote:
| I guarantee the problem space that dns solves is something
| you will run into in your career. Best to have some knowledge
| of systems like that so you can design them.
| Joel_Mckay wrote:
| DNS has been repurposed for everything from security validation
| to load balancing.
|
| DNS over HTTPS and DNSSEC attempted to address some longstanding
| issues, but in the end everyone still has a host they know is
| going to get hammered harder.
|
| Not too difficult to understand, but it is complicated given the
| number of sub-optimal use-cases that emerged. =)
___________________________________________________________________
(page generated 2023-07-28 23:00 UTC)