Date: Thu, 27 Mar 2003 10:02:45 -0600 From: David J Duchscher <daved@nostrum.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Mark_Andrews@isc.org Subject: Re: Resolver Issues (non valid hostname characters) Message-ID: <8CA22BDE-606D-11D7-80C5-0003930B3DA4@nostrum.com> In-Reply-To: <3E822AA2.B5D34120@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, March 26, 2003, at 04:33 PM, Terry Lambert wrote: > David J Duchscher wrote: >> The 'national security' comment as made do the shifting of arguments. >> We go to from the maxim of being generous to to accept and then to its >> a security issue. With respect to the underscore character, I see >> this >> as a week argument when balanced against the breakage that happens to >> users. > > You mean the programs that break when they are returned an "_" > from gethostbyaddr(), or the programs that "break" when they > call gethostbyname() an invalid hostname containing an "_", > and don't get an IP address back? > > The first one is the security problem. > > The second one is the one you apparently care about. The breakage I am talking about is from the users perspective. I also feel that the security issue is being overstated to justify the current situation. > >> I would say the program is broken if it doesn't check its input. > > So if gethostbyname() doesn't check it's input for "_", it's > broken? I would. I don't disagree with the check, just that I can't loosen it to meet the realities of the world and match what many comparable operating systems allow (Linux, Solaris). If this check was done on more operating systems, we probably wouldn't be discussing it. This problem arises from the fact that FreeBSD seems to be alone in this behavior. > 8-). > > > I think you are confusing "consumer" and "producer". > > A complying application would be strict in what it generates, > which means it would refuse to generate gethostbyname() > requests with "_" in them, for fear of breaking the programs > it's making requests to. > > It would accept "_" in gethostbyaddr() responses. I'm not > sure about that, though. Because the API boundary is an > interface, then gethostbyaddr() should be strict in the > responses it generates to the application making requests, > and also refuse to pass them up to the application. > > So either way, the protocol maxim works. As I said before its at what level you apply it. It works or breaks depending on your perspective. My perspective is just different from yours. > >> If many operating systems where doing this your argument would be >> much stronger. > > Sendmail is the majority mail server. And it allows underscore at least in my very limited testing. >> Secondly, we are talking about underscores in the middle of a hostname >> so your example is off. > > OK, consider my example to move the underscore to the middle > of the host name, instead. Its still a contrived example. >>> Mark is pointing out that this is not just a theoretical possibility, >>> it was in fact exploited against sendmail on the systems you are >>> holding up as examples (but it was *not* exploited on FreeBSD, >>> because FreeBSD complies with RFC-952). >> >> And I am not advocating removal of all the checks, just he addition of >> one very annoying character that cause grief to those that have to >> work in a mixed OS enviroment. > > Are these machine generated hostnames, or human generated hostnames, > and which particularly annoying environment? I have run into both. Today its human generated host names at a remote site. > It's reasonable to add a compatability flag (default off) to > support an annoying machine generated hostname, if there's no > way to turn it off in the generation algorithm. Of course its reasonable and sometimes request for changes to a vendor product actually happen. Not today though. > But I've already said this, and I claim it applies to more > than just "_". From my experience, this is not the case. The underscore character is just that thorn in some of our sides because windows likes it. In ten years of running the DNS systems, I have yet to have anyone complain about any other character. Yet they whine about the underscore. Thankfully, they don't ask anymore because they know my answer. >>>> Bypassing the resolver is also not an option that most >>>> users have available to them. >>> >>> All programmers have this option, if they have the option to >>> use the resolver in the first place. The API is well, if >>> obscurely, documented. >> >> Users != programmers so this statement is moot. Users that simply >> wish >> to hit a web site are the ones that bump into this issue. You really >> expect them to modify code? > > No. I expect browser vendors to modify code. I find this rather unreasonable and about as likely to happen as the underscore character being allowed through FreeBSD resolver. They also don't have to modify their code, it works on all the other operation systems. >>> Note that sendmail now wraps the calls itself, in case the host OS >>> is not conformant with RFC-952. You will not be able to send or >>> receive email from non-compliant systems on any system running a >>> corrected version of sendmail that does this enforcement. >> >> Just so you know, sendmail does not conform to RFC 952. It protects >> itself sure, >> but it allows host names to have an underscore in the host name if the >> underline >> resolver allows. I have not tested this beyond a couple of machines >> but this seems >> to be the case. > > What version is your sendmail? Sendmail 8.12.6/8.12.6 Sendmail 8.9.3/8.9.3 Postfix (don't know the version) works as well. >>> I have no objection, in principle, to such a patch, as long as >>> it's not enabled by the default configuration distributed with >>> the system. >>> >>> HOWEVER, this particular patch is not sufficient to put the >>> argument to rest. >>> >>> This should probably not be "allow_underscore" in the resolv.conf. >>> >>> Instead, you should probably have: >>> >>> allow_chars "_" >>> >>> You will also need an escape charachter, which is usually "\", >>> for specifying things like the escape character, special characters, >>> and quotation marks, e.g.: >>> >>> allow_chars "_\\\010\x17\"" >>> >>> Since the systems you are talking about are broken vs. RFC-952 for >>> more than just underscore. >>> >>> Otherwise, next week, we are going to have people asking us to >>> allow the next character not in RFC-952, and there will be a >>> proliferation of these options. >> >> I don't really agree that their will be proliferation of addition >> characters. > > Why not? See above. > If this is one jackass vendor machine-generating names with _ > in them for DHCP lease additions to the local DNS in order to > cause problems for UNIX systems, then they will certainly notice > the change, and make their own changes to *keep* things difficult > for UNIX vendors, won't they? Considering the other Un*x operating systems don't seem to mind the underscore character I don't see this as a likely reason. The systems that I have run into that underscore all come from the Windows world where the underscore is a commonly used in names. DaveD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8CA22BDE-606D-11D7-80C5-0003930B3DA4>