name resolution

[Tom H]

On Sat, Nov 25, 2017 at 4:49 AM, Xen <list at xenhideout.nl> wrote:
> Tom H schreef op 24-11-2017 19:13:
>> On Fri, Nov 24, 2017 at 12:20 PM, Xen <list at xenhideout.nl> wrote:
>>> Tom H schreef op 24-11-2017 10:03:


>>>> It started using Rendezvous for zero config networking in OS X 10.2,
>>>> renamed it Bonjour in OS X 10.5, and has been using it ever since.
>>>
>>>
>>> Where does that say "decide for the rest of the world"?
>>
>> Others found mdns/sd-dns useful and started using it. So it's become a
>> de facto standard and Apple decided for the world without even trying.
>
> But we have learned by now that it does not follow from the RFC.

In what way doesn't it follow the RFC?!


> My particular issue does not follow from the RFC.
>
> We know Apple likes to make choices that come down to vendor-lockin.
>
> You don't have to follow that.

Distributions do whatthey find is useful. "/run" wasn't officially
blessed until after it was implemented by all distributions.


>>>> Lennart re-implemented Bonjour, I've forgotten when, as a gpl-licensed
>>>> technology for use in Linux and BSD.
>>>
>>> You're still not saying anything relevant.
>>>
>>> We already knew that.
>>
>> Your knowledge of avahi doesn't really shine through your ranting in
>> this thread.
>
> I don't know much about Avahi, that's true.
>
> But you have also (not one of you) said anything relevant that I didn't
> already know.

If you knew what we've been telling you, you wouldn't be protesting
that you want to use ".local" as a unicast private domain.


>>>>> There is no reason whatsoever that mDNS has to precede DNS.
>>>>>
>>>>> The only "reason" for that is to prevent leakage onto the internet,
>>>>> which
>>>>> are queries to the root domain for .local, which returns NULL.
>>>>>
>>>>> At every stage, this can be blocked by DNS servers, and probably is.
>>>>>
>>>>> If you put mDNS AFTER dns, it will still work, and not frustrate
>>>>> operation of the DNS system.
>>>>>
>>>>> The delay in first accessing the global DNS system and only then mDNS
>>>>> is
>>>>> minimal.
>>>>>
>>>>> The reverse is not true; mDNS has a timeout of about 4 seconds or
>>>>> nearing
>>>>> that.
>>>>>
>>>>> So by all extents and purposes, you should put mDNS AFTER DNS, unless
>>>>> of
>>>>> course
>>>>
>>>> In your use-case, perhaps.
>>>>
>>>> In the general use-case, all distributions have chosen the logical
>>>> choice of querying mdns before dns.
>>>
>>> A choice is not a use case.
>>>
>>> Please compare apples with apples.
>>>
>>> What is the general use case that mandates that choice, and what makes it
>>> logical?
>>>
>>> I told you how it's not logical. Refute it please.
>>>
>>> Or just don't say anything.
>>>
>>> Calling it logical doesn't make it logical.
>>>
>>> Calling a bear a honey-bird doesn't make a bear a honey-bird.
>>>
>>> There is nothing logical about it, or you would have already said it by
>>> now.
>>
>> If you're not running a local unicast dns server that's authoritative
>> for ".local" with your nsswitch.conf setup, ".local" queries will be
>> done against the root servers.
>
> When I said "does have to precede dns" I was talking about a binary choice.
>
> In fact it is clear there is also a third option, namely letting local DNS
> precede local mDNS.

You've misunderstood what I said because I didn't write this:

If you have "hosts: files dns mdns", if you're not running a local
unicast dns server that's authoritative for ".local" with your
nsswitch.conf setup, ".local" queries will be done against the root
servers.

The root servers shouldn't have to deal with this nonsense.

You can see the number of per-second queries for invalid TLDs on

http://stats.dns.icann.org/hedgehog/

(choose "QTYPE for most popular Undelegated TLDs")

It's ridiculous that there are so many misconfigured "private"
domains. AS I said in a previous email, these quesries should go to
the blackhole servers. But we shouldn't green-light the
misconfiguration of lans simply because there's garbage collection on
the net.


> But you could also just configure DNS servers to not return anything for
> .local you know.
>
> The DNS guy said this was not possible; you cannot configure BIND to respond
> with NOTFOUND unless it has gone to the top first.
>
> Lennart considered this ludicrous.
>
> The DNS guy wanted to insert an empty SOA record at the edge of his network,
> so requests for .local would just return an empty domain.
>
> But not NOTFOUND.
>
> Well I just configured my network to do that :p.

What are you referring to? Who's the "dns guy?!" I don't see how you
can return an empty domain for a ".local" domain if you're using it as
you lan domain name.


> I don't see why global DNS servers cannot respond directly to .local
> requests with NOTFOUND.
>
> Why is there a need to let it pass on to the root servers?

That's what the blackhole dns servers do.


> Can global DNS servers not even cache queries?
>
> I mean what is this nonsense.
>
> You would now completely disrupt local networking in some way only because
> leakage to the DNS servers pass everything on to the root servers?
>
> So this does not makes sense to me.
>
> The easiest technical...
>
> I mean.
>
> Again, stop talking nonsense you know...
>
> It is perfectly clear that with any desire, those root servers can be
> shielded from this.
>
> That still leaves queries to the configured DNS servers...
>
> Does anyone...
>
> I mean.
>
> Even if you are not talking nonsense, it is nonsense that this problem would
> have to exist.
>
> That's what I mean actually, sorry.

The RFC 1918 addresses are blackholed and other can be blackholed too.

But this should be done because someone misconfigured a private
network by mistake rather than doing so purposefully.