[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20221206105703.2996d31f.quinq@fifth.space>
Date: Tue, 6 Dec 2022 10:57:03 +0100
From: Quentin Rameau <quinq@...th.space>
To: musl@...ts.openwall.com
Subject: Re: lookup_name issue with search domains
> The name exists, yes, but does the _host_ exist?
Yes it exists, that's what the authoritative DNS server answered.
The host exists because it was identified by its name.
The server, though, also told you that this host doesn't have a record
of the type you queried for, and that's final.
> > Searching ends there because the host was found by name,
> > and the server said it doesn't have an associated address.
>
> Except a host wasn't found, just the name. To put an example to it,
> please point to the host that is 'notahost.macdermid.ca'. There is a
> TXT record for that domain name, yet I don't see how that creates a host.
Yes, the host was found, otherwise the server would have answered with
an “NXDomain” meaning it doesn't know this name.
So what it tells you here, is that it is responsible for a host
with the name notahost.macdermid.ca. If there are no address records
associated with that name and you ask for some,
then the server will tell you there isn't any with “NoData”,
no error, but the data you asked for doesn't exist.
If you ask for that TXT record, it'll give the answer.
In both cases, it tells you that the host exists (no error).
> > > So I guess it comes down to the question: Does this match a host?
> >
> > This matches a host, with no configured AF_INET address.
>
> That would only be the case if we considered every domain name a host.
> I haven't found anything that specifies that particular limitation on
> DNS. If anything it seems MX records would be a counter-example. Also
> from RFC 1034:
>
> >>> We should be able to use names to retrieve host addresses, mailbox
> >>> data, and other as yet undetermined information. All data
> >>> associated with a name is tagged with a type, and queries can be
> >>> limited to a single type.
>
> Note it doesn't say 'data associated with a host'.
Indeed! All data of a host is associated with a (host) name.
So if you get a positive anwer to a host name, but there is no actual
data associated with it, then there is no such data.
> I hope you don't feel I'm just being pedantic here. I'm simply trying to
> explain how we see domains names differently, and why I don't understand
> this particular difference between libc implementations.
I kind of feel that's actually of the opposite.
It seems that you interpret “host” as an independant virtual concept.
In the context of DNS, a host is identified by a name.
If a server answers it's responsible for that host name,
then it exists.
If it also tells you there is no record of the type you queried for,
then it doesn't have any of those.
> To me I own a domain and can create records in that domain. If I happen
> to point some names at hosts using A/AAA records, great. If other names
> have TXT, MX, or some other record type, well I don't feel I've created
> a host-missing-an-A/AAAA.
But you actually did, that's the point.
> And maybe I'm wrong. Maybe other libc's should be following musl and for
> a name to exist automatically makes it a host (although in that case,
> would musl be being pedantic in not supporting cloudflare?). Either way
> hopefully you understand better why it's confusing to me, and why people
> are bitten by this decision.
Yes, again there is not host and names and addresses
existing independantly.
A host is identified by a name, it's a host name.
It can have addresses, it's called a host address.
It can have other properties, it'd be called a host property.
--
It seems that this whole discussion is not really about nxdata or
nxdomain, but what yourself expect from gethostbyname(3),
and the search directive of resolv.conf.
Note that the former is deprecated, and the later not standardized.
Regarding the API, it's pretty clear:
- [HOST_NOT_FOUND] No such host is known.
Meaning that this server isn't responsible for that host
(and you would ask another one if you're searching for it)
- [NO_DATA] The server recognized the request and the name, but no
address is available. Another type of request to the name server
for the domain might return an answer.
Meaning you found the correct server responsible for that host.
This host doesn't have an address associated with it, but it might
have another type associated with it, like an MX address.
Regarding the resolv.conf search directive, as it's not properly
agreed on nor well written (documentation-wise), it is up to
interpretation and one's own idea of what's correct and sane to do.
Should the resolver spam all servers of the directive until some
(most likely none) answers your actual request, even if the first one
told you it's responsible for it and your requested data doesn't
exist?
Or should it respect what the server tells you in the first place?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
