Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 1 down vote favorite

Why don't many programming languages have real DNS client libraries built-in core? For example Python, Ruby and C# lack it.

You usually get only methods to get hostname out of IP or vice versa and only one record is returned. This then leads to building for example load balancing with only one IP which is seen by the world instead of pointing those IPs in DNS level.

Is this lazy DNS method/function the underlying reason why so much software fails if one of many hosts are down but all others are not in DNS perspective?

Email servers seem to get it right as they collect all MX records information (10 mail.domain.tld, mail2.domain.tld, mail3.domain.tld 20 backup.mail.tld) plus those mail.domain.tld could have many A records and try them all.

Is that one method relic from the times when the internet was small and there was no load-balancing and nobody cared to think there could be more of same kind of record? Are we programmers just too lazy to build retry logic?-)

share|improve this question
In Python on Linux, you could make a system call to dig, I guess. I'm not sure what you would do in other environments, though. Can you give some examples of this in the languages you named? I honestly haven't run into this problem and never thought about it (but I managed DNS servers for a couple of years). – lunchmeat317 Feb 26 at 21:03
Also, for what it's worth....due to Python's open nature, modules have been built for DNS tasks that require more than a hostname/IP check. Checking google, Ruby seems to be in the same boat. This functionality may not have been high on Microsoft's list (or perhaps there's a lower-level system call for it)? – lunchmeat317 Feb 26 at 21:09
8  
Why would this go into a programming language? If anything, it belongs into a library, and then your question should be "why aren't there any proper DNS libraries for so many popular programming languages". – tdammers Feb 26 at 21:11
3  
-1 multi-response DNS is not itself a reasonable load-balancing scheme, and DNS itself does nothing to verify whether the hosts in its lookups are valid or not anyway. Relying on DNS for multi-host reliability is foolish. – fluffy Feb 26 at 21:49
3  
-1, why do you think this is within the scope of a language spec? who gets to decide 'proper'? This is just a rant, voting to close. – GrandmasterB Feb 26 at 21:52

closed as not constructive by mattnz, GrandmasterB, GlenH7, Dynamic, Martijn Pieters Feb 26 at 23:05

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

2 Answers

up vote 2 down vote

The people who are good at language design will focus on the core language. After that, it depends on how good the module support is and if a good collaborative module distribution community gets established (Perl CPAN, Ruby Gems, Python Eggs).

Another factor is that people sometimes want flexibility in their resolver, and want to follow their OS conventions for looking up hostnames. Therefore you really need good integration with the OS, in order to get the same results as a getent hosts ... would give.

share|improve this answer
up vote 7 down vote

Things go into the standard library when they are used often enough that people expect them to exist. Most people still do not need in-depth DNS querying.

share|improve this answer
Yeah. It's "good enough". – raspi Feb 26 at 21:37
4  
@raspi: You don't appear understand the differences between Language, OS, Library and application - until you do, drop the sarcasm. – mattnz Feb 26 at 22:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.