DNS glibc functions confused by trailing slash in host name

My company uses a very simple http browser implemenation written in
gnu C++ to asynchronously post data to customers. We use
gethostbyname_r to convert FQDN to IP address, then set up a socket,
set the headers, send the data, etc.

One of our customers has a host name with a trailing slash, i.e their
FQDN is like

foo-.bar.com

The various glibc library DNS lookup functions fail when looking up
this FQDN. I tried gethostbyname_r and getaddrinfo. gethostbyname_r
returns NO_RECOVERY. getaddrinfo returns EAI_NONAME. I've tried this
on RH 6.2, and on RHEL 3 and 4.

nslookup, host, and dig all find this name with no problem.

AFAIKT from looking at IETF specs, the trailing slash is illegal. But
I don't want to have to tell my customer to change his host name.

What are the nslookup, host, and dig commands doing differently to
lookup the name than what is done in the glibc functions?

Thanks for the help!

Hello,

(E-Mail Removed) a écrit :
>
> One of our customers has a host name with a trailing slash, i.e their
> FQDN is like
>
> foo-.bar.com

I do not see a slash ("/") in this name.

> What are the nslookup, host, and dig commands doing differently to
> lookup the name than what is done in the glibc functions?

They are DNS tools, i.e. they query nameservers directly instead of
calling the system resolver.

Whoops I meant hypen. I reposted with the correct question. Please
ignore this thread.

Sorry for the confusion...

On May 18, 12:15*pm, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org>
wrote:
> I do not see a slash ("/") in this name.

On May 18, 12:15*pm, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org>
wrote:

> They are DNS tools, i.e. they query nameservers directly instead of
> calling the system resolver.

Precisely. The problem with functions that use the system resolver is
that they have no way to know that they should use DNS to resolve this
hostname. However, if you call the DNS functions directly, they will
handle it correctly.

Think about it -- since this is not a legal DNS name, why would the
system resolver pass it to the DNS functions?

DS

David Schwartz a écrit :
>
> Precisely. The problem with functions that use the system resolver is
> that they have no way to know that they should use DNS to resolve this
> hostname. However, if you call the DNS functions directly, they will
> handle it correctly.
>
> Think about it -- since this is not a legal DNS name, why would the
> system resolver pass it to the DNS functions?

However if a name is not a legal DNS name, why would the DNS functions
serve it ?

On May 20, 2:35*am, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org>
wrote:

> However if a name is not a legal DNS name, why would the DNS functions
> serve it ?

Because there's really nothing else they can do.

DS

Pascal Hambourg <boite-a-(E-Mail Removed)> wrote:
> However if a name is not a legal DNS name, why would the DNS functions
> serve it ?

(Much) Older DNS servers might serve it, or DNS servers tweaked to
still serve such names. However, this customer with the illegal
character in the name is basically sitting on a ticking time bomb and
(perhaps deliberately) limiting the ability of other hosts on the
internet to reach it.

rick jones

not sure what internationalized DNS does to this whole thing...

--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On Tue, 20 May 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <g0vjaq$h3o$(E-Mail Removed)>, Rick Jones wrote:

>Pascal Hambourg <boite-a-(E-Mail Removed)> wrote:

>> However if a name is not a legal DNS name, why would the DNS functions
>> serve it ?
>
>(Much) Older DNS servers might serve it, or DNS servers tweaked to
>still serve such names.

Older, as in before bind-4.9.4 (mid-1996). According to the second
edition of the 'cricket' book ("DNS and BIND", Albitz/Liu, O'Reilly
and Assoc, ISBN 1-56592-236-0, 1997), there were boot file directives
that would turn off the hostname checking in 4.9.4, but I'm not sure if
the option (check-names) still works the same way in "current" versions.

>However, this customer with the illegal character in the name is
>basically sitting on a ticking time bomb and (perhaps deliberately)
>limiting the ability of other hosts on the internet to reach it.

There certainly was a lot of heat over the issue in 1996 (see RFC1912)
and all of the documentation relating to hostnames since then _should_
have made everyone aware of the concept, but...

>not sure what internationalized DNS does to this whole thing...

Nothing. RFC3467, 4185 and 4343 don't address it, and RFC3490 doesn't
allow a lead/trail hyphen (section 4.1 step 3(b)).

Old guy