mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Kenny MacDermid <kenny@macdermid.ca>
To: musl@lists.openwall.com
Subject: Re: [musl] lookup_name issue with search domains
Date: Tue, 6 Dec 2022 01:19:39 -0400	[thread overview]
Message-ID: <20221206051939.hsse4vffoaeb3uqu@localhost> (raw)
In-Reply-To: <20221205232506.3d0c68df.quinq@fifth.space>

On Mon, Dec 05, 2022 at 11:25:06PM +0100, Quentin Rameau wrote:
> Hi Kenny,
> 
> > The API that's in question is called `gethostbyname*`. It's not
> > getTXT, or getMX or anything like that. When calling that I don't
> > care if a name exists, I care if a host exists. As such I expect the
> > API to only look at host records (and possibly dnssec that protect
> > them). I wouldn't really care if there was 10 odd new record types,
> > if there's no host records then there's no host at that name.
> 
> Indeed, and that's what you get there.
> The DNS server is telling you it's authoritative
> (you'll get no better different answer from somebody else),
> the name exists, but its without an (IPv4) address.

The name exists, yes, but does the _host_ exist?

> 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.

> > 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'.

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.

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.

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.

  reply	other threads:[~2022-12-06  5:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-04  4:02 Kenny MacDermid
2022-12-04  5:45 ` Markus Wichmann
2022-12-04 15:31   ` Rich Felker
2022-12-04 23:04     ` Kenny MacDermid
2022-12-05 13:26       ` Rich Felker
2022-12-05 20:11         ` Kenny MacDermid
2022-12-05 22:25           ` Quentin Rameau
2022-12-06  5:19             ` Kenny MacDermid [this message]
2022-12-06  9:57               ` Quentin Rameau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221206051939.hsse4vffoaeb3uqu@localhost \
    --to=kenny@macdermid.ca \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).