name resolution

Xen list at xenhideout.nl
Sat Nov 25 09:49:43 UTC 2017


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.

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.

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

So who's to talk right.

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

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.


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?

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.




More information about the ubuntu-users mailing list