name resolution

[Xen]

Liam Proven schreef op 02-12-2017 13:47:

>> 1) .home is even more in use than .local
> 
> [[Citation needed]]

See Tom's post on root server stats.

>> 2) mDNS doesn't prevent .home or any of the others from leaking
> 
> It's not intended to. That's a totally different, unrelated problem.
> And not an important one -- I think I've seen one .home network ever,
> and it was mine and I had an internal DNS.

As I said there are more devices probing for .home than for .local.

Ask Tom (or look online).

>> 3) mDNS solves currently at most 20-30% of that part.
> 
> Give some evidence of this.

According to those root server stats .local covers about 20-30% of 
private domain leakage, after .home, and before .lan, .dhcp and so on.

That means that mDNS if used everywhere would solve "20-30%" of that 
problem.

As it currently exists.

>> 4) there is a burden on the root servers which seems to come down to 
>> about
>> 2x the capacity required if there was no leakage.
> 
> Again, unrelated problem. There are other tools for this.

So you consider it not mDNS' task to block leakage.

>> 5) this is a lot but in the end does not break the internet.
> 
> The whole point of the Internet's original design was fault-tolerance
> and graceful degradation after damage.

So that affirms that the leakage is not a world class problem.

>> 6) treating that as something vitally important is rather unpragmatic
> 
> No, you just don't understand how and why it works.

How and why what works?

You just said that the problem was not important, now you refute me when 
I say it is not important?

I would ask you to explain yourself here.

>> 7) sacrificing local functionality for this non-vital thing is also
>> unpragmatic
> 
> There is no such sacrifice.

mDNS as implemented by Linux and Apple claims the .local domain, as such 
to people wanting to use the .local domain this would be considered a 
sacrifice.

>> 8) you could call it an error in judging priorities
> 
> Yes. Yours.

You said the leakage was not a problem and/or not to be solved at the 
local level.

I am just saying that if people are going to claim otherwise, (a) that 
it's a huge problem, and (b) that it must be solved at the local level, 
and (c), if you would accept the "sacrifice" statement, that solving it 
locally at all costs could, would or should be considered a misjudgement 
of priorities.

>> 9) unless you "search" for both .local and whatever other domain you 
>> might
>> be using locally, you cannot have a unified view of your home network 
>> when
>> certain devices rely on mDNS and others don't.
> 
> You do not understand how it works and why it exists.

I do understand how it works. You evidence this clearly below.

But let me write what I did understand about it before you wrote 
anything.

As far as I know, mDNS "exists" (was created) to solve the problem of 
(a) knowing the names of other devices on the network (b) discovering 
whatever services they offer, and (c) potentially also negotiating a 
network address if this is also required.

In Linux for instance, the (c) part is covered by "autoipd" which gets 
triggered if no DHCP server responds.

As far as I know, mDNS on Linux consists of two parts:

1) the avahi daemon that provides the publication, resolution, and 
acquisition (I mean negotiation there) of these names and services

2) the resolver library that ensures the avahi daemon is used for .local 
queries.

There is also a third part, which is the /etc/nsswitch.conf 
configuration.

This is the part that ensures that .local queries (explicit ones) that 
are not resolved by the mdns library, are blocked from further 
resolution.

This feature is not part of either avahi or the resolver libraries 
themselves.

So what part did I not cover? I'd love to learn.

If I must add anything here, the system differs from "broadcast" in that

queries are by default sent to what is called a "multicast" address that 
all hosts listen to.

This multicast address is not the same as the typical broadcast address 
(e.g. 192.168.0.255) but these packets are explicitly targetted to that 
specific IP address that all hosts listen to.

There are also alternate methods, but this is the main one.

The system allows hosts to broadcast their self-assigned name, obtain 
the broadcasts of other devices on the network, and as such built a 
local map of existing computers and their names, which also includes any 
named services they might offer.

This is similar to the NetBIOS system in which printers are identified 
as being 'different' than hosts.

An extension to mDNS is the IP auto negotiation, which is also part of 
"zeroconf".



>> 10) the whole purpose of a local domain is this unified view
> 
> Not really, no.
> 
> The whole point of mDNS is _when there is no local configuration_.

I was not talking about mDNS. I was talking about local domains in 
general. (Private domains).

> This is a way for a TCP/IP network _which nobody has configured_ to
> function usefully.

I knew that. That is the whole stated goal of mDNS.

That is why I kept bringing up AppleTalk, which also has that feature.

But it has no relevance to local domains an sich, which was the topic of 
my question (you are being too narrow here in what you think I am 
talking about).

I know how mDNS works and what it's for.

> This is exactly what you were asking for when you
> compared it to NetBIOS

You mean that mDNS offers the same features as NetBIOS. I knew that.

> (a term you _keep_ misusing, because NetBIOS is
> an _API_ and you talk about it as if it were a _network protocol_.

And the protocols are called NetBIOS Frames (NBF) and NetBIOS over 
TCP/IP (NBT).

The entire API is meant to be used over a network. Colloquially, we call 
it NetBIOS.

> Do you know the difference?)

Yes. And even though a Linux computer is technically not a Linux 
computer, because "computer" denotes hardware, and this hardware can 
also run Windows, we still talk about "Linux computers" even though 
"Linux" denotes software.

> There are 2 levels of it, AIUI.
> 
> [A] There is no local config at all. No DHCP, nothing. So machines
> assign themselves addresses, according to the standard mechanism; then
> they assign themselves a name; then they can find one another using
> these names.

Those names are usually always self-assigned and not negotiated in any 
way. But they are published and "discovered" along with their published 
services.

I mean that most devices will already have a hostname preconfigured.

> [B] There is minimal local config, i.e., each node has an IP address
> and a gateway. Then, they assign themselves names, and thus, with no
> name resolution configured, they can still find each other by name.

Of course. That's the whole point of the system.

In Linux, the "IP negotiation" part is triggered when no DHCP server can 
be found.

For example there is this file:

/etc/dhcp/dhclient-enter-hooks.d/avahi-autoipd

That covers the activation of autoipd on the client (there are only 
clients of course).

I still wonder what you think I don't understand.

> Without this the users would have to use IP addresses, and those can
> change, so are not a solid solution -- they break too easily

That seems pretty obvious and rather "duh".

And you really think I didn't know all of that?

>> 11) I wonder how you mDNS + local domain users do this?
> 
> It's very simple.
> 
> #1 Do not use domains called ".local". At all, ever. They are created
> _ad hoc_ when required. Stay out of their way.

The purpose of my question was based on the premise that .local would 
only be used for mDNS and that a person would have another domain 
configured as unicast DNS.

Therefore, you are just restating my premise. This is not what I asked.

> #2 If you have local DNS you don't need mDNS. If your domain is called
> ".local" then mDNS resolution disables itself.

This is not correct.

My network has a .local unicast DNS server configured.

Yet avahi-browse-domains -a works fine:

+ enp0s8 IPv4 nas                                   Web Site             
local
+ enp0s8 IPv4 nas [00:11:32:1c:fc:4e]               Workstation          
local

On Windows, this device would be listed as a "device" and if you double 
click on it, the above website is opened.

This "nas" I can resolve using:
a) mDNS
b) DNS

Another device (not shown) presents its mDNS hostname as 
"brand-macaddress.local" and I can resolve it using:

a) mDNS
b) ----

This means that "ping" works, but "nslookup" doesn't, "host" doesn't, 
and neither does my web browser.

Another device, a SqueezeboxTouch, I can only resolve using

a) ----
b) DNS

This is getting a little complicated, but I'm already basically giving 
my own answer now.



> Configure your local
> DNS properly so that all machines get the address(es) of the name
> server(s) when they get assigned an IP address.

Already done. This was the premise of my question.

> Assigning names to
> dynamically-addressed nodes is your own problem but you chose to run a
> local DNS server so you chose to do the work.

Already done. This was the premise of my question.

I understood everything already that you were explaining here.

But you did not even understand the question I was asking.

> Get on with it.

Everything you've said I have already understood and done.



This was the question:


- If mDNS devices acquire .local names and your other DNS system 
acquires, say, .home names,
   then how do you address these devices?

   - Are you going to use .local?
   - Are you going to use .home?
   - Are you going to use "search" parameters?

   I mean search parameters for both .local and .home?


> But I don't know why I'm bothering.

The fact is that you didn't understand my question, nor my knowledge, 
but I understood you perfectly.

> You'll only write an abusive
> response and persist in your ignorance, because you think you
> understand and are not willing to learn.

And you repeat basics that not only I had already covered regarding 
mDNS, you also even try to explain to me how to set up a DNS server that 
I already had running since long.

It's you who doesn't understand, LIAM.

You don't understand:

- what my problem is
- what I already know about the system
- the question I was asking here
- and so on and so on.

Since you don't actually "get" what my issue is.

You think I must be some dumb idiot who doesn't know 1+1.


mDNS is a system for automatic resolution, announcement and acquisition 
of names on the network including the broadcasting of services such as 
the above "Web Site" and "Workstation".

In addition to that it can also perform IP address auto-negotiation in 
lieu of a DHCP server.

My question was what will you do when one part of your network uses mDNS 
and the other part uses DNS?

What do you do when:

- your local NAS does both DNS and mDNS
- your local Music Player does only DNS
- your local IP camera allows you to change the DNS hostname but not the 
mDNS hostname that it also supports?

Are you really going to be addressing

axis-00408ced62c3.local every time you want to address it?

So now we add a different domain for DNS only.

We now have:

                     DNS                  mDNS

NAS            diskstation.home     diskstation.local
Music        SqueezeboxTouch.home         -
Camera            camera.home       axis-00408ced62c3.local
PC           xen-pc-linux.home      xen-pc-linux.local

How are you now going to address these devices?

Will you keep using mDNS or only for automatic tools?

Will you ever use the .local name explicitly?

Does it make sense to have these side by side?

> So you will keep claiming
> your broken understanding and broken method are better.

Yet you absolutely could not comprehend my:

a) state of knowledge
b) question
c) issue

Then you try to

a) give me a 101 on something I already understood far better than that
b) tell me how to run a DNS server when I've said numerous times that I 
already have this covered.