[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 5 Dec 2022 16:11:51 -0400
From: Kenny MacDermid <kenny@...dermid.ca>
To: musl@...ts.openwall.com
Subject: Re: lookup_name issue with search domains
On Mon, Dec 05, 2022 at 08:26:05AM -0500, Rich Felker wrote:
> As an analogy, you could imagine a DNS provider adding some sort of
> TXT records to every name in your zone. Nothing about DNS says they
> can't -- these are valid records that can exist anywhere -- but they'd
> be serving something different than what you asked them to.
>
> In this case, Cloudflare is effectively making *every possible* name
> under your zone exist, but with no RRs defined for it unless you
> provided some. This is contrary to your intent that names you didn't
> define simply not exist.
Thank you for all the information Rich. I'm in no way trying to be
argumentative here, and am not claiming to be a DNS expert. I'm just
trying to provide another view of the issue.
In providing a different perspective I think the analogy is a good place
to start. Let's say we take it a bit further and say it wasn't the DNS
provider changing things. Say I added an MX record to a domain.
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.
>From my understanding of what you're saying: if the query response
doesn't contain error flags , it's indicating the name exists. That's
fine, the name exists. That doesn't mean the host exists. The response
that comes back has zero 'Answer RRs'. If searching should now stop
because the host was found, what's it's address?
Reading a Linux man page on `resolv.conf` it says of the "Search list
for host-name lookup":
>> Resolver queries having fewer than ndots dots (default is 1) in them
>> will be attempted using each component of the search path in turn
>> until a match is found.
In the case where I have 3 search list entries, has a host match been
found because the second domain has an MX record? It doesn't seem like
it to me.
>From a glance for empty answers in RFC1034 I see section 6.2.4 has:
NAME=SRI-NIC.ARPA, QTYPE=NS
This query could return without any error but the RFC says:
>> The only difference between the response and the query is the AA and
>> RESPONSE bits in the header. The interpretation of this response is
>> that the server is authoritative for the name, and the name exists,
>> but no RRs of type NS are present there.
That sounds to me like what Cloudflare is doing. They're saying they're
the authority for the name, and no A records exist.
So I guess it comes down to the question: Does this match a host?
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.
