name resolution

[Xen]

Liam Proven schreef op 24-11-2017 19:12:
> I've picked this old message because it seems to me to be where Xen
> started going _way_ off-base in their replies.
> 
> On 24 November 2017 at 18:20, 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"?
> 
> It doesn't. Stop the paranoid ranting.

I said Apple doesn't decide. Someone else said it does. So who is 
paranoid?

Stop attributing things to me another person said.

> Apple is an early adopter of tech standards, and indeed, sometimes it
> sets them. All 3D composited desktops in the world today use a model
> Apple designed. Apple brough the ``sudo'' command to mainstream Unix,
> copied 4y later or so by Ubuntu.
> 
> Apple was the first company with a mass-market computer with only USB,
> and propelled USB onto the world stage.

I never heard of that. From my perspective USB just came about because 
it came about. I saw no anomaly in the pace with which it was introduced 
that would have anything to do with anything I could not see.

Apple was never big in Europe too. Much bigger in America. Not so much 
in Europe.

> It also was a major promoter
> of Firewire and named it -- Sony called it the less inspiring i.Link
> and officially it's IEEE1394.

Sure and it was never very popular except for Apple desktops.

I knew some people who used Firewire, but they were all Apple fanboys.

I once... explicitly bought a Firewire card and a firewire harddisk 
because I wanted to have options.

I never was able to use it for anything else. This was back in 2007.

> Apple makes easy-to-use computers. With AppleTalk, you plugged them in
> and it just worked. With TCP/IP, this wasn't possible. TCP/IP needs a
> unique address for every machine, a shared subnet mask, and some form
> of name resolution service. It can't ask every machine what its name
> is, as it doesn't know what other machines are out there. It can't ask
> the server or router because it hasn't got one.

You mean in a home without a router.

I really never heard anyone ever laud AppleTalk before.

It has also been discontinued and replaced by Bonjour, but apart from 
that, it never seems to have been an issue or lack of Windows computers.

Now of course I am only starting to talk from about 1995.

And Apple existed before that, I know that.

And even while AppleTalk apparently was the de facto standard, or some 
of it, during the 80s, ultimately TCP/IP took over completely and during 
my lifetime, or my conscious lifetime in that sense, has never been a 
factor of importance for anyone I knew.

I also dislike, as I have said "automatic configuration" and the article 
you linked as to why kids can't use computers plays into this 
completely.

So you currently laud it as beneficial but the article lauds it as 
detrimental.

Not having to configure stuff is not a good thing in the sense of also 
having no _control_ over it.

The TCP/IP issues never stopped the Internet from becoming popular, or 
home networking for that matter, for the Windows world.

Router appliances solved most of these issues for most people.

I mean all of those issues for most people.

SMB/CIFS solved the issue on the file share level completely.

Games used their own broadcasting system (or IPX) to find other players 
"in the same room".

So while you laud success here, AppleTalk has not had a huge impact 
directly during the 90s on my personal life as far as I knew.

Of course Apple is a pioneer. That doesn't make everything they do good.

Yes people did not have names for IP addresses if they wanted to do 
more.

Which was always annoying.

But non-tech people didn't want to anyway.

I have solved it with dnsmasq as many people have.

Routers could have done that a long time ago if there was a need for it.

They haven't.

So you name at least 2 things, USB and Firewire, that were either not 
really Apple's achievement or not very popular elsewhere.

AppleTalk was also never felt as a necessity and lost way to TCP/IP.

That didn't have those features yet was still superior.

If it was so important, why didn't the rest of the world adopt it?

You mention 3D compositing, sure, fair enough.

You mention sudo. I can find no history about it. It has existed since 
1980.

You mean the model of having no root password and only sudo. I get that.

Yes I get that this is an inspiration.



But all of the stuff you have mentioned thus far is not really 
impressive.

Windows users never felt a need for Bonjour.

CIFS printers, after all, were also automatically discovered.



> So in 2000, two Bills, Manning and Woodcock, defined a name service
> that would work for serverless networks

which don't exist.

> It is _needed_. Before this, different machines with self-assigned
> network addresses could not find each other by name.

Nonsense.

\\john\files

Is certainly by name.

> http://www.watersprings.org/pub/id/draft-manning-dnsext-mdns-00.txt

This draft does not mention .local.

> If you invent your own personal language, you won't be able to talk to
> anyone. But nobody's stopping you.

Should other people now take heed of my personal language and not use 
certain words I have reserved for myself?

And if I exclaim that I have decided this for the world...

Apple never exclaimed that.

People here do.

Apple created a 'standard' or a certain way of doing things that has 
apparently become popular.

The draft above does not say that multicast should supersede unicast and 
explicitly says that multicast is a new thing for tcp/ip.

It basically warns against incompatibility.



>>> 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.
> 
> You are certainly acting like you don't.
> 
> It's an open standard. Apple adopted it and made it important before
> anyone else. The rest of the world followed. There's no need for 2 of
> them.

I am saying I don't want the Bonjour thing.

Apple by itself does not force anything upon me.

My issue is in the forcing, not the technology itself.

Technology does not just magically march into my home without being 
asked.

You are acting like you don't know the difference between free choice 
and compulsion.

Linux was always about choice.

It was not anymore.

It is not anymore.

They are taking my .local away from me, INSIDE MY OWN HOME.

For a technology I do not want to use, have no need for, etc.

>>>> So by all extents and purposes, you should put mDNS AFTER DNS, 
>>>> unless of
>>>> course
> 
> That's ludicrous. The machine should try to find a DNS server, ask it,
> wasting time and traffic, and *then* ask locally? That'a absurd.

In the ideal model this DNS server is on the local network.

There is no reason to be without a local DNS server (or proxy) because 
there is no reason to be without a router.

If you wanted a purely routerless network, yes then it starts to make 
sense,

but still not very much.

DHCP takes care of all of this in a much better way.

- you can control the number address something is given (you could never 
do so with multicast right).

- you can automatically process this number or include it in other 
services in a way that makes sense.

I do not want random numbers everywhere.

In the absence of routers or configured subnets, what numbers are going 
to be given???

If it is zero conf, it will have to gain a private IP number, but which 
one?

192.168.0? That is pretty pre-determined.

I am pretty certain that even under mDNS most hosts will normally still 
acquire DHCP, but then use multi-cast to announce themselves to each 
other, when the DHCP server could just as well do that.

I already have what is basically offered by mDNS, by way of dnsmasq.

Everyone could, if only manufacturers, I mean if only routers produced 
that.

Scratch manufacturers, routers just need to do that.

If this is a necessity.

So numbers are still assigned by DHCP.

So we don't have zeroconf.

We have pre-configured DHCP.

We could just as well have pre-configured DNS.

What's the big difference here? It's not.



>>> In your use-case, perhaps.
>>> 
>>> In the general use-case, all distributions have chosen the logical
>>> choice of querying mdns before dns.
> 
> Exactly.
> 
>> A choice is not a use case.
> 
> It is the sensible and pragmatic choice. The other way round would be
> much slower and generate tons of spurious redundant and unnecessary
> traffic. It _must_ be this way.

Then don't block DNS.

Here is a quite intelligent fellow:

http://avahi.freedesktop.narkive.com/XD3tWzYz/multicast-dns-and-the-unicast-local-domain

He suggested that Avahi turns itself off when a DNS server is found on 
the network that has .local configured.

Lennart said:

"Sounds like a good idea. Could you please bring this to the attention
of the Debian/Ubuntu folks who ship that .local detection script? (To
my knowledge the other distros still don't, though they should)

Lennart"

But was it implemented? No.



mDNS could EASILY shut itself off if .local already existed. It doesn't.

What's more, the default /etc/nsswitch.conf does not even allow the 
plugin to do this.

So there is no detection script.

No ability for mdns_minimal or mdns to take care of it either.






> Did that too.
> 
>> Or just don't say anything.
> 
> Me? Nah. :-D

I wasn't talking to you :p.

>> Calling it logical doesn't make it logical.
> 
> It is logical. If everyone else thinks so and you don't, then maybe
> you don't know what logical means, or don't understand the logic.
> 
> You are wrong on this one.

So explain to me why a detection script was not added, or is not 
delivered.

Explain to me why mdns needs to block .local from getting out.

I mean if it deferred to a local .local server, that would make it not 
so much an offensive system.

At that point it becomes a fallback.

Which means secondary.

But to go back, you say "much slower" and "tons of spurious traffic".

On normal internet DNS queries to the internet are not slow.

$ for q in shell.dds.nl www.youtube.com www.twitter.com 
www.volkstrant.nl www.nrc.nl www.philips.com; do time=$(cat /proc/uptime 
| awk '{print $1}' | sed "s/\.//"); host $q > /dev/null; time=$(( $(cat 
/proc/uptime | awk '{print $1}' | sed "s/\.//") - time )); echo $time; 
done
80
89
97
26
86
88

I am on wireless broadband. Normally it is not this slow. These are 
centiseconds.

How often do you address computers in the home by local DNS name?

You don't think all of these resolutions would get cached?

This is the time for nonexistent domains:

$ for q in i.dont exist.here iam.sure of.that i.think.at.least 
but.what.gives; do time=$(cat /proc/uptime | awk '{print $1}' | sed 
"s/\.//"); host $q > /dev/null; time=$(( $(cat /proc/uptime | awk 
'{print $1}' | sed "s/\.//") - time )); echo $time; done
27
29
31
28
30
45

So we are talking on average on a mobile broadband (3G) connection 30 
centiseconds.

Before it returns with not found.

Every computer can also run a caching nameserver by the way, unscd on 
Linux is a good one.

So you can't wait 30 centiseconds for a local resolution _for the first 
time_ ?

Yes and I know.... But I was going to say.

Whether something is important to "go first" depends not only on its 
basic premise of local vs global, but also on the uses it needs.

Most people request 1000x more internet domains than local domains.

The few times someone is going to request an uncached local domain is 
going to be severely limited.

So even though normally you can say that local should precede global

when we weigh actual uses, the answer is different.

That is just about speed.


If the reward (and in a certain sense it is even unnecessary, you can 
turn off mdns_minimal when you detect .local, which I guess hasn't been 
done yet...)

is for people not wanting to use .local exclusively for mdns, to be able 
to do that (freedom of choice)

and the only cost is that uncached queries for .local take 30 
centiseconds longer to me that is something worth considering.

1) you can put mdns first but prevent it from blocking dns, (.local), 
now you have solved the speed issue

2) you can put it last by default, now you have 30ms at most (30cs I 
mean) uncached queries

Both still leak to the internet.

But if it is really a problem, DNS servers on the internet can be 
configured to respond directly with empty records.

Or domain not found.

3) You add a dns_local resolver that will only query the configured 
nameserver for .local queries and only if previous attempts did not 
detect any server running that would return something sensible with a 
certain cache timeout,

you put mdns after that

and you put regular dns after that.

Now you have almost zero leakage.

"if host -t SOA local. > /dev/null 2> /dev/null ; then
# Hoho! There is a domain .local in unicast DNS! Let's disable Avahi!"

You only have to do this every 15 minutes.

Or every 10 minutes, what do I know.

Or when networking is started.

Or changed.

Now you have a dns_local.so library that will perform this function... 
no sorry.


This is the order:


hosts:  dns_local mdns_minimal dns

NOW mdns_minimal can block.


hosts:  dns_local mdns_minimal [NOTFOUND=return] dns

Or even if you like:

hosts:  mdns_minimal dns_local [NOTFOUND=return] dns

But this is way slower.



>>>> Politics.
> 
> Paranoid nonsense.

So why then not a solution that allows both sides to be happy?

Why does it have to be only one?

Why not the above solution?



Why not cater to both parties?


There is no physical, technological, I mean absolute need to take .local 
away from people.

I could probably write said plugin in a few days. (Getting it published 
is another matter).

It's that simple and then you have .local DNS continuing the work, while 
.local mDNS takes over if it is not found,

This only requires dnsmasq to be configured with --auth-zone=local


Now you have a solution that requires zero configuration on the client, 
will give a local unicast dns server configured for .local authority 
over mdns, will ignore it if it doesn't exist, will resolve all "not 
found" answers in mdns, will not leak anything to the internet.

And requires a single extra configuration on the dnsmasq server, and if 
you don't do that mdns will take precedence.

And it only requires writing a single module which is in fact trivial.

You can just copy the relevant code from the dns.so module and add a few 
bits for soa record checking.

Ideally there is a method to purge this cache.

But without it you can either set a negative TTL to 10minutes, or just 
force the client to restart networking.

There is only one requirement for this: .local must not become a 
top-level domain.



>> This always used to be the case.
>> 
>> It was called "netbios".
>> 
>> Netbios wasn't forced on anyone and didn't use DNS.
> 
> NetBIOS needs name resolution over TCP/IP v4

No it doesn't.

Or at least it doesn't require DNS if that is what you mean.

> and doesn't work at all
> on IPv6. Originally it used a WINS server, then later, MS embraced &
> extended DNS in its normal unpleasant way. If no name server is
> available, it sends broadcast requests, which is bandwidth-wasteful.

It doesn't deal with DNS at all.

And now suddenly broadcast requests are "bandwidth-wasteful" on a local 
network?

Come on Liam, don't make me laugh.

So just because mDNS queries a unicast address it is now so superior 
that you should let it kill unicast dns?

I mean that you should let it kill dns?





> https://en.wikipedia.org/wiki/NetBIOS_over_TCP/IP
> 
>> And all the same, if "dns" precedes that, the above would still hold 
>> true in
>> mDNS.
> 
> Wrong. I don't think you know networking as well as you think you do.

I have to look this up later because I don't know what you are 
responding to.


>> Linux does not have a new filesharing system other than Samba/CIFS.
> 
> It supported NFS before Samba. It also does sshfs and multiple other
> protocols including 9P.

NFS is not useful for when you want to do account-based authentication, 
which is what most people want and why most Linux people would also 
normally use Samba for filesharing and not NFS.

I said "new".

NFS is typically hard to configure and only useful for exporting 
servers, including the entire ownership/group permission structure of a 
Unix fileserver.

I myself have never been able to get username-mapping to work.

It is complex and not user friendly at all.

So you mention the exact opposite of what Bonjour is.

>> There is nothing new here.
>> 
>> This existed in freaking Windows 95.
> 
> Windows 95 _did not install TCP/IP by default_.
> 
> From Wednesday:
> 
> https://twitter.com/Foone/status/933045088447430656

I must say I don't explicitly remember filesharing in Windows 95.

I am pretty sure though I have done it often enough in Windows 98.

But that does not negate anything, that is a three year difference.

And Windows 98 is almost 20 years ago.

So what are you arguing?


> You really do not understand this subject but you are arguing with
> people who do. And, I might point out, were implementing it in
> 1993-1994 on systems carrying US$600 million in trades per day.

So what have you said that makes things different?

You go on trying to brag about your knowledge but you have mentioned 
only 4 Apple things that are not impressive.

iPhone is impressive. iPod is impressive. The other stuff isn't.

iBook is impressive.

Hardware.

I am not impressed by Apple.

I was impressed by Jobs, certainly.

I have also read his biography, if I need to brag here (or at least a 
biography).

And then you say that it is more logical to do local before global.

Which makes sense, of course.

What doesn't make sense is:

- claiming that mdns queries are so important that they don't warrant a 
30cs or less global lookup on a computer that happens to be connected to 
broadband internet

Uncached, I have to add

- claiming that in view of this lacking technological solution, it is a 
fair tradeoff to kill .local domains using unicast dns entirely, when (I 
know you haven't claimed this) a fair technical solution absolutely 
exists.

What exactly warrants killing off .local domains?

You call it paranoia but it's already done.

And I have demonstrated that a fair technical solution easily exists.

A solution that lets two systems live side by side and that was proposed 
by a DNS server engineer.


> Don't try to tell me my business unless you know it better than I do,
> there's a good chap.

Being older and 'wiser' doesn't mean you are always going to be right.

It can also mean that you are set in your ways.

>> That's the meaning of "zero conf", you know, that you could go to 
>> Network
>> and see all the computers in the workgroup, which was always the same.
> 
> Go on then. Explain how this worked over NetBEUI and IPX/SPX and what
> the important differences were. Tell us how you'd configure such a
> system removing those protocols and replacing both with TCP/IP.

Install Windows 98.
Install Windows 98 on another computer.
Configure a share on the first.
Configure a computer name on the first.
Type \\name on the second.

Done.

What don't you understand?

Am I missing something here?

You call the Microsoft approach embrace and extend, but this is not 
embrace and extend?

> Don't
> forget that it was an optional extra in Windows for Workgroups so you
> should mention its special status and explain what implementations
> were available and the main considerations in choosing one of them.

Yes you are living in the ancient past.

> Were you?

I was gaming and doing filesharing with zero configuration in a system 
that did not use, nor did it intrude upon DNS, as far as I can tell.

> I'm guessing not, because nothing you've said implies you know how to 
> do it.

Install Windows 98.
Install Windows 98 on another computer.
Configure a share on the first.
Configure a computer name on the first.
Type \\name on the second.


>> I went to LAN parties and saw dozens upon dozens of computers I could
>> access.
>> 
>> Zero configuration you know, in case you need the definition of that.
> 
> It means _you_ did zero configuration. Someone  else did it for you.

No.

Who?

Filesharing in Windows did not require configuration.



> Now, if you were arguing that TCP/IP was more difficult than NetBEUI,
> I'd agree. But, as I'm sure a network expert such as yourself knows
> (!), NetBEUI is not routable, so you could not build the Internet with
> it.

.local is not meant for internet routing.