KDE team removes support for underscore, starts enforcing STD3 from RFC1122

Interestingly, the latest build of KDE 4 (4.3.90 aka 4.4 RC1) no longer supports the underscore character in host names.

While this was allowed in previous KDE4 versions, the KDE team have removed support for the underscore as “STD3 requires all DNS domain names to be limited to Letters, Digits and Hyphen.”

Here are two examples of bugs that have been filed and subsequently closed with a ‘WONTFIX’ resolution: 220500 222291

So, any of you sysadmins out there who have the audacity to have hosts (or DNS aliases/addresses) on your network with the underscore character in them, you’ll no longer be able to connect to those hosts using KDE4 apps like KRDC (Remote Desktop) or the Konqueror web browser.

22 Replies to “KDE team removes support for underscore, starts enforcing STD3 from RFC1122”

  1. I'm not 100% sure this is a good thing. Ok. The RFC's and such don't allow host_names but Windows does (and I'm guessing so does Linux, etc).

    It'd be nice if everyone followed the standard but they don't. I can see this not being a good thing…

  2. D'OH!

    When KDE4 first came out, it drove me to Gnome. But I'd always thought I'd look at it again once it had matured more. However, if this demonstrates the foresight of the development team, that event will be a long, long time coming. High-handed idiocy indeed!

  3. It's that classic KDE problem of not having anyone to manage the developers' undoubted skills. Developers need someone they can look up to to tell them when they're behaving like donkeys.

  4. This is a good thing. Bind doesn't allow this per the RFC, why should KDE? Compliance makes stuff work together nicely. KDE has always worked towards a closely knit and cohesive environment between their K* apps. There's no reason they wouldn't turn the same attention to detail to other services that their software interacts with on a normal or frequent basis.

  5. Anon, that's an interesting link – it seems to be saying that underscores ARE still used in the DNS process but it would seem they are more of a 'reserved character' type.

    Although it was hard for a Saturday morning fuzzy brain to decipher… šŸ˜‰

  6. While annoyed at the change, I do see this as a good thing too – it's always difficult in the fuzzy middle period of standards adherence.

    My initial reaction was “aww crap – that's not cool!”. But I waited for those feelings to subside before I made the blog post. But I thought it was important to let everyone know about the change as it may affect some. Like me at work where we have some older servers with underscores in the name.

    These servers should all be gone by mid-2010 and, in the meantime I've created DNS aliases for them with a hyphen instead of an underscore. Just for me on my KDE 4.4 RC1 box to connect too…. (because I can). šŸ˜‰

    For many many years now, whenever a Windows box was given a name with an underscore in it, a warning would appear saying that this is a non-standard name and you may have difficulty connecting to it from some clients. I just had never experienced that until now.

  7. Personally, I think that underscores should be allowed in host names, but the standard doesn't permit it, and in this case I believe following the standard is more important.

    The fact that some OSs have ignored (or bent) the standard for years is not a justification for continuing to do so.

  8. Having been a DNS practitioner since the early '90's, I can say that the behavior of DNS servers WRT hostnames with “_” has always been unpredictable. At some point in the mid-nineties I saw bind releases start to choke on them, returning SERVFAIL errors under some circumstances. Changed them (all Netware servers then) to “-” in all my zones and never looked back. The underscore has never been legal in DNS names, and there's an old saying: “The fact that something used to work doesn't mean it was supposed to”.

  9. I use KDE and I have done so since the Mandrake OS about 10 years ago. The last version from 4 onwards has left me struggling with 'Plazmoids and _ugg_ _DOLPHIN_' and I quite often revert to the KDE3.5 and its associated Konquerer File manager, which I found very acceptable. If KDE Project is going to drop the 'underscore' how will it affect me in my contact with so many very large International Companies who use the 'underscore' symbol? Will the 'New version of KDE' pre-empt me from my contact abilities? If so, I will do what I did with 'Microsoft' and eliminate KDE from everything I do using my computer networks. (It may be I will have to resort to Gnome.)

  10. @Donkey

    I think you missed annon's point about rfc2782 in that the rfc refers to service records NOT fqdn's. In effect, by using an underscore in the fqdn you are possibly conflicting with SRV RR. I glean that from the sentence:

    An underscore (_) is prepended to
    the service identifier to avoid collisions with DNS labels that
    occur in nature.

    The inverse of this statement is that if you use an underscore in a fqdn then you may have a collision with SRV RR's.

    The underscores in rfc2782 are for use in service and proto symbolic names; not the fqdn.

    From personal experience administering mail servers (specifically using EXIM) fqdn's with underscores are a bother and have ALWAYS been set up by uninformed (I'm being kind here) Exchange admins. Typically these servers have lot's of other issues.

    The rfc's are there for a reason and although they are not LAW, if everyone follows them it makes life easier.

    I'm no longer a fan of KDE having switched to Gnome after the KDE 4 fiasco but I applaud them in this instance.

    That's my $.02, $.01 after taxes..

  11. Dear Konqueror devs, what's my favorite color? You don't know? Then you must be stupid.

    Yes, that is a ridiculous answer. Just like your “answer” in the bug report, and Konqueror's useless error messages. Just think of all the ill will that could be avoided if you would give informative answers. Unless your goal is to write software with no users.

    Personally, I see zero value in being hard-core on this particular bit of functionality in Konqueror, because it does absolutely nothing to cure a perceived problem. It inconveniences users, and makes Konqueror even less useful as Web browser than it is now. What are we supposed to do, force offending DNS admins to clean up their acts? Good luck with that.

  12. Thanks for the clarification Frank – that makes more sense!

    I agree this is a good thing – just getting the word out there as it may affect more than me. šŸ™‚

  13. I love KDE, but don't use Konquerer.
    But other browsers Firefox and Opera support the “_” in the dns name.

    The “non-support” of the underscore in the dns name is similar (I'm drawing a WIDE analogy) to Web Developers that refused to support browsers that didn't follow Web Standards, namely IE. They web sites broke and didn't look good on IE browsers and in essence blocked out 70% of browsers (for a time). As more and more people began using Firefox, Opera, Safari etc to get those Web Standard sites, IE began to move over to following Web Standards (well, sort of).

    Now, the IE market is less than 50%. People are tired of not being able to go to those sites.

    Maybe the people at KDE Dev are “ahead of their time”. But eventually, sites with underscores in their DNS will adopt the standard, things will work in Konquerer….

    And I will still be using Firefox.

  14. Intranets are not bound to follow the RFCs. There is a huge number of intranet domains containing underscores. They won't change, simply because they don't have to. Why should I be blocked from connecting to them?

    And if a browser forces you to whatever, especially to something not mandatory, this is not a free software anymore. If I wanted this, I would stay with IE.

    So:

    apt-get remove konqueror
    apt-get install firefox iceweasel opera…

  15. @Grigor

    I hear you. As mentioned in my post, I've had to deal with this from time to time. In the cases where the customer 'just had to get email' from the offending server and the fqdn could not or would not change then I would allow an exception for that fqdn.

    The problem has never been with the top level domain but with server name eg. smtp_server.domain.com

    It might be convenient if there were a configuration option that would allow the use of the underscore in a server name for people in your situation. But you really should try to follow the rfc's.

    Also, I take exception with your statement:

    'this is not a free software anymore'

    This IS free software. You are allowed to do with it as you please. Go ahead and download the source and change it to allow underscores. Try doing that that with IE.

  16. @Grigor: Intranets are not bound to follow the RFCs.

    No, they're not. But the equipment and software that the Intranet is made of should, otherwise your intranetz will break. And nobody wants broken intranetz.

    It's about this point it's worth invoking the Robustness Principle; “Be liberal in what you accept and strict in what you send” ( http://ironick.typepad.com/ironick/2005/05/my_history_of_t.html )

    By this principle, I would expect Konquerer (or anything else) to let me enter any bizzare characters I wanted to type in, and deal with them gracefully. I would also expect it to reject these, and not forward them to any other component or system, as non-RFC behavious would be unpredictable.

  17. @Frank: Changing an intranet policy, esp. in a big organization, usually is not possible for the vast majority of its users. Most often such a change is not needed at all. And even if the CIO plans it, the need for reconfiguring some dozens of thousands of PCs may delay it by years. Should in this situation the Konqueror coders force their preferences on me?

    An option to switch this limit off would make the change OK for a free software, but the bug reports are rejected with 'WONTFIX'. “My way or the highway”. Well, we have free software now because some people chose the highway…

Leave a Reply

Your email address will not be published. Required fields are marked *