Is mDNS supposed to coexist with DNS?
I have a proper DNS server but if I just try to ping an FQDN it tries mDNS UDP 5353 which fails.
OTOH I just installed my printer and I'm guessing mDNS helped with that so maybe mDNS is something I need?
I have no experience with mDNS but I am assuming that I will need to just disable it to get DNS to work correctly.
Mike
On 11/4/2016 13:03, Michael B Allen wrote:
Is mDNS supposed to coexist with DNS?
I have a proper DNS server but if I just try to ping an FQDN it tries mDNS UDP 5353 which fails.
OTOH I just installed my printer and I'm guessing mDNS helped with that so maybe mDNS is something I need?
I have no experience with mDNS but I am assuming that I will need to just disable it to get DNS to work correctly.
Mike _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
My understanding is mDNS is meant to be used when there is no local name server. If you have a DNS server it would probably be best to disable mDNS so you're not adding unneeded complexity. I dont know specifically how it's meant to fail over to DNS if mDNS fails to resolve a name. I imagine the host you're trying to reach would just ignore the mDNS packet, causing a failure, then your computer should reach out to the DNS server that is configured on the device. It is supposed to be able to coexist with traditional DNS but that defeats the purpose of mDNS to be honest.
Regards, Bryon
Hi mDNS manages only the .local domain (or its replacement if you configure mDNS differently), nothing else. mDNS is called via a special IP address in 224.0.0.xxx and therefore cannot face out the original DNS.
suomi
On 11/4/2016 13:03, Michael B Allen wrote:
Is mDNS supposed to coexist with DNS?
I have a proper DNS server but if I just try to ping an FQDN it tries mDNS UDP 5353 which fails.
OTOH I just installed my printer and I'm guessing mDNS helped with that so maybe mDNS is something I need?
I have no experience with mDNS but I am assuming that I will need to just disable it to get DNS to work correctly.
Mike _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
My understanding is mDNS is meant to be used when there is no local name server. If you have a DNS server it would probably be best to disable mDNS so you're not adding unneeded complexity. I dont know specifically how it's meant to fail over to DNS if mDNS fails to resolve a name. I imagine the host you're trying to reach would just ignore the mDNS packet, causing a failure, then your computer should reach out to the DNS server that is configured on the device. It is supposed to be able to coexist with traditional DNS but that defeats the purpose of mDNS to be honest.
Regards, Bryon _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On Fri, 4 Nov 2016 13:03:41 -0400 Michael B Allen wrote:
Is mDNS supposed to coexist with DNS?
I have no idea what is "supposed" to work, but I know I always have to get rid of the mdns [notfound=return] crap that is in my /etc/nsswitch.conf file by default in order to get "normal" dns lookups to work.
On 11/04/2016 11:09 AM, Tom Horsley wrote:
On Fri, 4 Nov 2016 13:03:41 -0400 Michael B Allen wrote:
Is mDNS supposed to coexist with DNS?
I have no idea what is "supposed" to work, but I know I always have to get rid of the mdns [notfound=return] crap that is in my /etc/nsswitch.conf file by default in order to get "normal" dns lookups to work.
Yeah, I've never figured out why they do that. The default action for notfound is "continue". Why they abort further lookups by using "return" is silly and (IMHO) broken. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - "Hello. My PID is Inigo Montoya. You `kill -9'-ed my parent - - process. Prepare to vi." - ----------------------------------------------------------------------
On Fri, Nov 4, 2016 at 2:36 PM, Rick Stevens ricks@alldigital.com wrote:
On 11/04/2016 11:09 AM, Tom Horsley wrote:
On Fri, 4 Nov 2016 13:03:41 -0400 Michael B Allen wrote:
Is mDNS supposed to coexist with DNS?
I have no idea what is "supposed" to work, but I know I always have to get rid of the mdns [notfound=return] crap that is in my /etc/nsswitch.conf file by default in order to get "normal" dns lookups to work.
Yeah, I've never figured out why they do that. The default action for notfound is "continue". Why they abort further lookups by using "return" is silly and (IMHO) broken.
Ok, so this nails it. If I remove [notfound=return] then there is a 3 second delay for mdns to return but it does fallback to DNS. I have to completely remove mdns4_minimal [notfound=return] to just use DNS.
Of course my local network is a .local domain so it seems at least in my case mdns cannot really be used effectively.
I never understood these logical meta languages. Pam is another example. It's basically just an obscure way of writing code so it's not obvious to me why this isn't just scripted so that someone has the option of making them work together (call both mDNS and DNS async and then return first to respond).
Mike
On Fri, Nov 4, 2016 at 4:24 PM, Samuel Sieb samuel@sieb.net wrote:
On 11/04/2016 12:58 PM, Michael B Allen wrote:
Of course my local network is a .local domain so it seems at least in my case mdns cannot really be used effectively.
Well, that right there is your problem. Don't do that...
Why? I thought Intranet networks were supposed to use .local.
Mike
On 11/04/2016 01:38 PM, Michael B Allen wrote:
On Fri, Nov 4, 2016 at 4:24 PM, Samuel Sieb samuel@sieb.net wrote:
On 11/04/2016 12:58 PM, Michael B Allen wrote:
Of course my local network is a .local domain so it seems at least in my case mdns cannot really be used effectively.
Well, that right there is your problem. Don't do that...
Why? I thought Intranet networks were supposed to use .local.
https://en.wikipedia.org/wiki/.local https://tools.ietf.org/html/rfc6762
Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB).
On Fri, Nov 4, 2016 at 10:38 PM, Michael B Allen ioplex@gmail.com wrote:
On Fri, Nov 4, 2016 at 4:24 PM, Samuel Sieb samuel@sieb.net wrote:
On 11/04/2016 12:58 PM, Michael B Allen wrote:
Of course my local network is a .local domain so it seems at least in my case mdns cannot really be used effectively.
Well, that right there is your problem. Don't do that...
Why? I thought Intranet networks were supposed to use .local.
In the MS world (in the past?).
On Fri, Nov 4, 2016 at 5:13 PM, Tom H tomh0665@gmail.com wrote:
On Fri, Nov 4, 2016 at 10:38 PM, Michael B Allen ioplex@gmail.com wrote:
On Fri, Nov 4, 2016 at 4:24 PM, Samuel Sieb samuel@sieb.net wrote:
On 11/04/2016 12:58 PM, Michael B Allen wrote:
Of course my local network is a .local domain so it seems at least in my case mdns cannot really be used effectively.
Well, that right there is your problem. Don't do that...
Why? I thought Intranet networks were supposed to use .local.
In the MS world (in the past?).
I don't think this was a MS thing. I recall .local being used a loooong time ago. It used to be that .local was absolutely the recommended method for small private networks. From googling around it seems there is a lot of nonsense about using .local versus using a subdomain. The only decent reason I can think of for not using .local is if you want to get SSL certs for intranet hosts in which case using .local would not be appropriate and it seems recently CAs will no longer issue certs for made-up TLDs. Otherwise, it looks like Apple just highjacked .local for mDNS.
Mike
On Fri, Nov 4, 2016 at 11:40 PM, Michael B Allen ioplex@gmail.com wrote:
On Fri, Nov 4, 2016 at 5:13 PM, Tom H tomh0665@gmail.com wrote:
On Fri, Nov 4, 2016 at 10:38 PM, Michael B Allen ioplex@gmail.com wrote:
On Fri, Nov 4, 2016 at 4:24 PM, Samuel Sieb samuel@sieb.net wrote:
On 11/04/2016 12:58 PM, Michael B Allen wrote:
Of course my local network is a .local domain so it seems at least in my case mdns cannot really be used effectively.
Well, that right there is your problem. Don't do that...
Why? I thought Intranet networks were supposed to use .local.
In the MS world (in the past?).
I don't think this was a MS thing. I recall .local being used a loooong time ago.
".local" may or may not have been used a long time ago.
I can't remember ever using it on Solaris or Linux in the 90s but I definitely used it on MS; and it was recommended by MS during the NT4 and IIRC the 2k eras.
On 11/04/2016 02:40 PM, Michael B Allen wrote:
I don't think this was a MS thing. I recall .local being used a loooong time ago. It used to be that .local was absolutely the recommended method for small private networks. From googling around it seems there is a lot of nonsense about using .local versus using a subdomain. The only decent reason I can think of for not using .local is if you want to get SSL certs for intranet hosts in which case using .local would not be appropriate and it seems recently CAs will no longer issue certs for made-up TLDs. Otherwise, it looks like Apple just highjacked .local for mDNS.
That's a pretty strong statement. That's like saying IETF highjacked port 22 for ssh because I always used that port to run my own application. .local was never a registered TLD, so there was just some common usage of it. And yes, MS did apparently recommend it at one time. But until this email thread, I didn't know of anyone still using it.
On Fri, Nov 4, 2016 at 5:53 PM, Samuel Sieb samuel@sieb.net wrote:
On 11/04/2016 02:40 PM, Michael B Allen wrote:
I don't think this was a MS thing. I recall .local being used a loooong time ago. It used to be that .local was absolutely the recommended method for small private networks. From googling around it seems there is a lot of nonsense about using .local versus using a subdomain. The only decent reason I can think of for not using .local is if you want to get SSL certs for intranet hosts in which case using .local would not be appropriate and it seems recently CAs will no longer issue certs for made-up TLDs. Otherwise, it looks like Apple just highjacked .local for mDNS.
That's a pretty strong statement. That's like saying IETF highjacked port 22 for ssh because I always used that port to run my own application. .local was never a registered TLD, so there was just some common usage of it. And yes, MS did apparently recommend it at one time. But until this email thread, I didn't know of anyone still using it.
Do you know for sure if mDNS predated .local or visa versa??
Disclaimer - this is all wild speculation. But think about it - why did Apple need mDNS? They needed mDNS so that OSX (and later iPhones and iPads) could find your home printer over the wireless router even if the printer IP changed. The wireless routers use .local. I know for a fact the Verizon ones do and have for a long time. So *maybe* Apple just hardcoded .local into their code to handle 99% of the Apple user-base and didn't think about the small private networks using real DNS and .local.
If I had to *guess*, I would say that mDNS was introduced with OSX which was maybe 2001? Did wireless routers use .local before that? Did the old WRT54G use .local? That was maybe 2002.
Mike
On Fri, Nov 4, 2016 at 8:54 PM, Michael B Allen ioplex@gmail.com wrote:
The wireless routers use .local. I know for a fact the Verizon ones do and have for a long time.
Actually I have to retract this. I'm not sure routers use .local. Mine is configure for .local but I may have just changed that so long ago I don't recall what it was originally. I see some routers use made up TLDs like .belkin for example.
Mike
On Sat, Nov 5, 2016 at 2:54 AM, Michael B Allen ioplex@gmail.com wrote:
Disclaimer - this is all wild speculation. But think about it - why did Apple need mDNS? They needed mDNS so that OSX (and later iPhones and iPads) could find your home printer over the wireless router even if the printer IP changed.
Not just wireless routers. And not just printers. File servers too.
I've forgotten the exact invocations but you can browse for all sorts of "services," like ssh or http, with "avahi-browse" on Linux and "dns-sd -B" on macOS.
If I had to *guess*, I would say that mDNS was introduced with OSX which was maybe 2001? Did wireless routers use .local before that? Did the old WRT54G use .local? That was maybe 2002.
Apple introduced Bonjour as RendezVous in 2002. It was renamed later because of a lawsuit.
On 11/04/2016 12:58 PM, Michael B Allen wrote:
On Fri, Nov 4, 2016 at 2:36 PM, Rick Stevens ricks@alldigital.com wrote:
On 11/04/2016 11:09 AM, Tom Horsley wrote:
On Fri, 4 Nov 2016 13:03:41 -0400 Michael B Allen wrote:
Is mDNS supposed to coexist with DNS?
I have no idea what is "supposed" to work, but I know I always have to get rid of the mdns [notfound=return] crap that is in my /etc/nsswitch.conf file by default in order to get "normal" dns lookups to work.
Yeah, I've never figured out why they do that. The default action for notfound is "continue". Why they abort further lookups by using "return" is silly and (IMHO) broken.
Ok, so this nails it. If I remove [notfound=return] then there is a 3 second delay for mdns to return but it does fallback to DNS. I have to completely remove mdns4_minimal [notfound=return] to just use DNS.
Of course my local network is a .local domain so it seems at least in my case mdns cannot really be used effectively.
By removing [notfound=return], things are behaving as I'd expect. If you're not using Avahi (or Bonjours), there really isn't any valid reason to use mDNS.
I never understood these logical meta languages. Pam is another example. It's basically just an obscure way of writing code so it's not obvious to me why this isn't just scripted so that someone has the option of making them work together (call both mDNS and DNS async and then return first to respond).
Historically, host resolution has never been a multithreaded process so it's never been done async (the API has no non-blocking versions of the function calls). Even without mDNS, the resolver library tries the first nameserver configured. If there's no answer to the query at all (e.g. server is down), it tries the second, then the third (if configured). The first answer received is used. If none of the servers respond at all or if all of the queries come back "not found", then the host isn't resolved. Note that you ARE talking over the Internet to get resolutions so you're stuck with the TCP/IP protocol timeouts along with the timeouts defined for the DNS service itself (60 seconds IIRC). You can shorten those (the original timeouts were chosen to handle slow links like dialup lines and such). Those are fairly rare now, but the timeouts remain.
mDNS provides the Avahi protocol, which is the open source version of Apple's Bonjours, which, in turn, is Apple's attempt at something like Microslop's NetBIOS. The whole ".local" suffix is an attempt to wrap non-Internet related things into Internet-appearing parlance so the same libraries can be used. A good example of pushing a paradigm too far, if you ask me (which you aren't, but....)
Where both mDNS and real DNS are active, if you parallelize the queries as you suggesting and get different answers, which answer gets credence? mDNS will almost always answer first since it's local to your machine so DNS would never be consulted and you'd just get "not found" out the wazoo. You could try setting
publish-resolv-conf-dns-servers=yes
in /etc/avahi/avahi-daemon.conf to have DNS results published and this may do what you want. We don't use mDNS here at the office, so my experience with it is limited and I haven't played with a lot of the various options. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - To err is human. To forgive, a large sum of money is needed. - ----------------------------------------------------------------------
On Fri, Nov 4, 2016 at 5:02 PM, Rick Stevens ricks@alldigital.com wrote:
On 11/04/2016 12:58 PM, Michael B Allen wrote:
I never understood these logical meta languages. Pam is another example. It's basically just an obscure way of writing code so it's not obvious to me why this isn't just scripted so that someone has the option of making them work together (call both mDNS and DNS async and then return first to respond).
Historically, host resolution has never been a multithreaded process so it's never been done async (the API has no non-blocking versions of the function calls).
You don't need multithreading to do async. The resolver calls would take a parameter that indicates that the call should return right away vs timeout. So in this case it could call the mDNS routine which would return right away, then call the DNS routine which would also return right away and then call mDNS again with a 1s timeout and loop on that 3 times as necessary until you get a reasonable answer.
I would be surprised if the resolver code doesn't do async like this already. I write networking code for a living BTW.
Where both mDNS and real DNS are active, if you parallelize the queries as you suggesting and get different answers, which answer gets credence?
Whichever looks better. This is why it should be scripted instead of using nsswitch which tries to parameterize everything.
mDNS will almost always answer first since it's local to your machine so DNS would never be consulted and you'd just get "not found" out the wazoo.
If it's a negative response (as opposed to no response) then you keep going until you get a reasonable answer or times out.
Mike
On Fri, Nov 4, 2016 at 9:58 PM, Michael B Allen ioplex@gmail.com wrote:
Of course my local network is a .local domain so it seems at least in my case mdns cannot really be used effectively.
That's the problem. ".local" is the default mdns domain.
You can change it by setting "domain-name=something_else" in "/etc/avahi/avahi-daemon.conf".
On 11/04/2016 02:12 PM, Tom H wrote:
On Fri, Nov 4, 2016 at 9:58 PM, Michael B Allen ioplex@gmail.com wrote:
Of course my local network is a .local domain so it seems at least in my case mdns cannot really be used effectively.
That's the problem. ".local" is the default mdns domain.
You can change it by setting "domain-name=something_else" in "/etc/avahi/avahi-daemon.conf".
Although that would immediately make you incompatible with all the devices you're probably wanting to talk to. :-)
On Fri, Nov 4, 2016 at 11:26 PM, Samuel Sieb samuel@sieb.net wrote:
On 11/04/2016 02:12 PM, Tom H wrote:
On Fri, Nov 4, 2016 at 9:58 PM, Michael B Allen ioplex@gmail.com wrote:
Of course my local network is a .local domain so it seems at least in my case mdns cannot really be used effectively.
That's the problem. ".local" is the default mdns domain.
You can change it by setting "domain-name=something_else" in "/etc/avahi/avahi-daemon.conf".
Although that would immediately make you incompatible with all the devices you're probably wanting to talk to. :-)
If the ".local" devices that you're connecting to are served by regular dns, it's not a problem.
On 11/04/2016 02:47 PM, Tom H wrote:
On Fri, Nov 4, 2016 at 11:26 PM, Samuel Sieb samuel@sieb.net wrote:
On 11/04/2016 02:12 PM, Tom H wrote:
On Fri, Nov 4, 2016 at 9:58 PM, Michael B Allen ioplex@gmail.com wrote:
Of course my local network is a .local domain so it seems at least in my case mdns cannot really be used effectively.
That's the problem. ".local" is the default mdns domain.
You can change it by setting "domain-name=something_else" in "/etc/avahi/avahi-daemon.conf".
Although that would immediately make you incompatible with all the devices you're probably wanting to talk to. :-)
If the ".local" devices that you're connecting to are served by regular dns, it's not a problem.
Of course, but in that case you don't need mDNS at all, so just remove it.
On Fri, Nov 4, 2016 at 11:49 PM, Samuel Sieb samuel@sieb.net wrote:
On 11/04/2016 02:47 PM, Tom H wrote:
On Fri, Nov 4, 2016 at 11:26 PM, Samuel Sieb samuel@sieb.net wrote:
On 11/04/2016 02:12 PM, Tom H wrote:
On Fri, Nov 4, 2016 at 9:58 PM, Michael B Allen ioplex@gmail.com wrote:
Of course my local network is a .local domain so it seems at least in my case mdns cannot really be used effectively.
That's the problem. ".local" is the default mdns domain.
You can change it by setting "domain-name=something_else" in "/etc/avahi/avahi-daemon.conf".
Although that would immediately make you incompatible with all the devices you're probably wanting to talk to. :-)
If the ".local" devices that you're connecting to are served by regular dns, it's not a problem.
Of course, but in that case you don't need mDNS at all, so just remove it.
Not really. You might want to use ".local" with dns and ".mdns" with mdns.
Of course, the more that you deviate from default setups and settings, the more work you create for yourself.
On 11/04/2016 09:05 PM, Tom H wrote:
On Fri, Nov 4, 2016 at 11:49 PM, Samuel Sieb samuel@sieb.net wrote:
On 11/04/2016 02:47 PM, Tom H wrote:
If the ".local" devices that you're connecting to are served by regular dns, it's not a problem.
Of course, but in that case you don't need mDNS at all, so just remove it.
Not really. You might want to use ".local" with dns and ".mdns" with mdns.
Of course, the more that you deviate from default setups and settings, the more work you create for yourself.
But what is going to use mdns in that case? If you change the mdns domain on your computer, you would have to change all the devices as well (if that's even possible). By that time you've lost the whole point of mdns which is plug and play. :-)
On Sat, Nov 5, 2016 at 7:02 AM, Samuel Sieb samuel@sieb.net wrote:
On 11/04/2016 09:05 PM, Tom H wrote:
On Fri, Nov 4, 2016 at 11:49 PM, Samuel Sieb samuel@sieb.net wrote:
On 11/04/2016 02:47 PM, Tom H wrote:
If the ".local" devices that you're connecting to are served by regular dns, it's not a problem.
Of course, but in that case you don't need mDNS at all, so just remove it.
Not really. You might want to use ".local" with dns and ".mdns" with mdns.
Of course, the more that you deviate from default setups and settings, the more work you create for yourself.
But what is going to use mdns in that case? If you change the mdns domain on your computer, you would have to change all the devices as well (if that's even possible). By that time you've lost the whole point of mdns which is plug and play. :-)
I agree that it's silly but it can be done, with a lot of work changing the settings of every device.
On Fri, 2016-11-04 at 23:47 +0200, Tom H wrote:
On Fri, Nov 4, 2016 at 11:26 PM, Samuel Sieb samuel@sieb.net wrote:
On 11/04/2016 02:12 PM, Tom H wrote:
On Fri, Nov 4, 2016 at 9:58 PM, Michael B Allen <ioplex@gmail.com
wrote:
Of course my local network is a .local domain so it seems at least in my case mdns cannot really be used effectively.
That's the problem. ".local" is the default mdns domain.
You can change it by setting "domain-name=something_else" in "/etc/avahi/avahi-daemon.conf".
Although that would immediately make you incompatible with all the devices you're probably wanting to talk to. :-)
If the ".local" devices that you're connecting to are served by regular dns, it's not a problem.
this is only partly true. You loose the service discovery features of mDNS. The OP noticed that mDNS helped setting up the printer (using mDNS discovery). mDNS is nice for discovery of devices and the services they offer.
It is a best practice to leave .local for mDNS. Even Microsoft recommends now against using .local https://en.wikipedia.org/wiki/.loca l offers some good information on the subject.
And for DNS-domains you better use only officially registered domains, do not invent your own domain names. Somebody may register the TLD you invented. Or the IETF might define it for some special purpose.
I heard of a DSL-modem vendor that used .box for local names. And guess what: somebody registered .box as an official top level domain....
Let the OP register an own domainname somewhere (or use a subdomain under a dynamic DNS name), so that the domain is somewhat formally owned. the disadvantage of the latter option is that it gives you a pretty long domain name <my-server>.<user name>.ddnsprovider.org Louis
On Sat, Nov 5, 2016 at 7:11 AM, Louis Lagendijk louis@fazant.net wrote:
It is a best practice to leave .local for mDNS. Even Microsoft recommends now against using .local https://en.wikipedia.org/wiki/.loca l offers some good information on the subject.
And for DNS-domains you better use only officially registered domains, do not invent your own domain names. Somebody may register the TLD you invented. Or the IETF might define it for some special purpose.
I heard of a DSL-modem vendor that used .box for local names. And guess what: somebody registered .box as an official top level domain....
Let the OP register an own domainname somewhere (or use a subdomain under a dynamic DNS name), so that the domain is somewhat formally owned. the disadvantage of the latter option is that it gives you a pretty long domain name <my-server>.<user name>.ddnsprovider.org Louis
I think there should be a TLD that ICANN specifically excludeds from registration or use on the Internet but specifically allows private use.
There are many scenarios were you might want to create a private network but not register or use an Internet domain name because it will never be exposed to other networks. This includes test domains, networks that are isolated for security reasons [1] and for personal home networks.
Mike
[1] DNS does not provide security but using a separate namespace may be required to completely isolate a network (eg if subdomain used, HTTP clients may submit cookies)
On 11/05/2016 09:49 AM, Michael B Allen wrote:
I think there should be a TLD that ICANN specifically excludeds from registration or use on the Internet but specifically allows private use.
The RFC 6761 reserves the DNS TLDs ".example", ".invalid", ".localhost", and ".test" so that they may not be installed into the root zone of the Domain Name System.
In addition, RFC 6762 reserves the use of .local for link-local host names that can be resolved via the Multicast DNS name resolution protocol.
On Sat, Nov 5, 2016 at 1:11 PM, Louis Lagendijk louis@fazant.net wrote:
On Fri, 2016-11-04 at 23:47 +0200, Tom H wrote:
On Fri, Nov 4, 2016 at 11:26 PM, Samuel Sieb samuel@sieb.net wrote:
On 11/04/2016 02:12 PM, Tom H wrote:
On Fri, Nov 4, 2016 at 9:58 PM, Michael B Allen <ioplex@gmail.com
wrote:
Of course my local network is a .local domain so it seems at least in my case mdns cannot really be used effectively.
That's the problem. ".local" is the default mdns domain.
You can change it by setting "domain-name=something_else" in "/etc/avahi/avahi-daemon.conf".
Although that would immediately make you incompatible with all the devices you're probably wanting to talk to. :-)
If the ".local" devices that you're connecting to are served by regular dns, it's not a problem.
this is only partly true. You loose the service discovery features of mDNS. The OP noticed that mDNS helped setting up the printer (using mDNS discovery). mDNS is nice for discovery of devices and the services they offer.
Not if you change every one of our devices.
It is a best practice to leave .local for mDNS. Even Microsoft recommends now against using .local https://en.wikipedia.org/wiki/.loca l offers some good information on the subject.
And for DNS-domains you better use only officially registered domains, do not invent your own domain names. Somebody may register the TLD you invented. Or the IETF might define it for some special purpose.
I heard of a DSL-modem vendor that used .box for local names. And guess what: somebody registered .box as an official top level domain....
IIRC, Lennart mentioned on fedora-devel@ ".box" as the local domain used by the most popular brand of wifi modems in Germany. It's not that big a deal unless, for example, I have a system on my lan called tom.box and I or someone else has a tom.box on the net. Maybe they're switch to ".fritzbox".
Tom H:
You can change it by setting "domain-name=something_else" in "/etc/avahi/avahi-daemon.conf".
Samuel Sieb:
Although that would immediately make you incompatible with all the devices you're probably wanting to talk to. :-)
On Fri, 2016-11-04 at 23:47 +0200, Tom H wrote:
If the ".local" devices that you're connecting to are served by regular dns, it's not a problem.
Recently I tried adding a Pixma MG7760 printer to my LAN, and there was no end of trouble. Sometimes the Windows and Mac computers found it, sometimes they didn't, I've only briefly played with Linux drivers for it (well, select a PPD file that you can download from Canon, and it prints nicely, but haven't tried the scanner).
It's one of those printers with USB, LAN, WLAN, NFC interfaces. Most of that use automatic settings, though there's a plethora of options that you can change. And to make things more awkward, it only wants to use one of those connection types, it doesn't want to be available on your ethernet LAN and wireless, simultaneously.
It uses some mixture of normal TCP/IP networking and Bonjour, and it doesn't seem to use both independently. For example, my DHCP server automatically gives everything else a name and IP, and puts them into the local DNS server, as well. But that doesn't work with this printer (I have to manually set in a hostname, on my DHCP server). It gets assigned an IP, but that's all that happens. The installable (Mac and PC) printer software seems to want to use Bonjour to find the printer, and usually fails (more directly about that next paragraph). For what it's worth, it often fails to find the printer when connected via the USB cable, too.
My understanding, though, of the .local issues is that such devices will have to be using the 169.254.x.y IP addresses (which they can do, as devices can have more than one IP, but it's not doing that). And, for your other network devices to also have to have a 169.254.x.y addresses (same conditions as before - they can have those addresses as well as regular LAN addresses, but they don't). None of the computers, do though, because as soon as they get assigned a regular IP, they don't bother with self-assigning themselves a random link-local address, as well. And the equipment won't talk with 169.254.x.y addresses that are outside of their 192.168.x.y subnets, normally. So, Bonjour seems to get left out of the equation.
So, from my point of view, .local isn't automatic, doesn't work, can't work.
I'd take the printer back, but I needed something that can print onto DVDs, for work purposes, and it's the only printer I can locally buy that will do that. Thanks to all the networking shenanigans, and awkward Linux compatibility, I did that by creating a picture I want to print on the disc, copying that to a SD memory card, and printing directly from that card plugged into the printer.
Gawd but I hate half-baked, and proprietary, consumer equipment.
On Fri, Nov 4, 2016 at 8:36 PM, Rick Stevens ricks@alldigital.com wrote:
On 11/04/2016 11:09 AM, Tom Horsley wrote:
On Fri, 4 Nov 2016 13:03:41 -0400 Michael B Allen wrote:
Is mDNS supposed to coexist with DNS?
I have no idea what is "supposed" to work, but I know I always have to get rid of the mdns [notfound=return] crap that is in my /etc/nsswitch.conf file by default in order to get "normal" dns lookups to work.
Yeah, I've never figured out why they do that. The default action for notfound is "continue". Why they abort further lookups by using "return" is silly and (IMHO) broken.
It only aborts if it's looking up a host with a domain of ".local" or an ip address of 169.254.x.x.
On 11/04/2016 10:03 AM, Michael B Allen wrote:
Is mDNS supposed to coexist with DNS?
I have a proper DNS server but if I just try to ping an FQDN it tries mDNS UDP 5353 which fails.
OTOH I just installed my printer and I'm guessing mDNS helped with that so maybe mDNS is something I need?
I have no experience with mDNS but I am assuming that I will need to just disable it to get DNS to work correctly.
I have no problem using mDNS in a network with regular DNS. It would really be quite useless if they couldn't coexist as mDNS is only for resolving local (.local) names.