4 ms·
>> I disagree that technical people should not have to understand DNS I think that any good technical developer/sysadmin has at some point set up their own BIN
by developer2 10y ago
>> I disagree that technical people should not have to understand DNS
I think that any good technical developer/sysadmin has at some point set up their own BIND server or similar, if only to play with it for a few hours before uninstalling. This is something that is often missing from developers who went through a CS program just to get a degree in an industry that pays well, without really having an interest in the field.
Good developers/sysadmins, who actually have an interest in the work they do, have an innate curiosity that leads them to try their hand at things like a DNS server. For no reason other than to learn something new and understand a topic they didn't knowing anything about before the experimentation.
Of course, you can learn about DNS without actually configuring a DNS server from scratch - but the real "aha" moments come from working with the server itself rather than only understanding the difference between A/CNAME/MX et al. Learning about FQDN syntax, how DNS master syncs to slaves, SOA serial numbers, etc. - so many interesting things to discover.
- manyxcxi 10y agoAlthough I have repeatedly in my life set up and configured BIND servers, and manage DNS zones monthly if not weekly, I disagree that a could developer should have to know these things very well if at all. As a developer you should know the basics of networking and the protocols you will be using to communicate, as well as their drawbacks but DNS as far as a developer is concerned, generally is a means to an end. They just need to know where to send a message to. I feel like you could be a great developer and not have a freaking clue how to configure a BIND server or manage a zone file- they're fairly unrelated to creating, maintaining, or deploying code (unless you're getting into containers and auto-provisioning).
- daurnimator 10y ago> they're fairly unrelated to creating, maintaining, or deploying code Actually it's very useful to know and understand potential misconfigurations. e.g. if your 3rd party integration starts failing, it's useful to know the signals that imply their sysadmin messed up a zone transfer. This sort of 'hands-on' knowledge that you only really get from messing around with the daemons yourself reduces downtime and emergency maintenance from hours to minutes.