On 8/12/19 12:37 AM, Carlos E. R. wrote:
On 12/08/2019 06.41, Bruce Ferrell wrote:
On 8/11/19 1:19 PM, Carlos E. R. wrote:
On 11/08/2019 21.21, James Knott wrote:
On 2019-08-11 03:04 PM, Per Jessen wrote:
My solution - for something I need to connect to, I put it in the dhcpv6 config and add dynamic dns updates. In fact, every known device gets a dynamic dns update, visiting devices don't and are given a firewall restricted ipv6 range. I use SLAAC and configure the DNS server with the consistent (usually MAC based) address.
How do you configure the DNS if the prefix is changing every time the router reboots or the ISP sees fit?
Just a theoretical cuestion, you know I don't have an actual prefix.
Carlos, in the situation you've outlined, you *don't* configure DNS.
You simply rely on the DNS server provided by the DHCP server.... Where ever that happens to be ISP or locally administered. The DHCP is the router, obviously, and it does not provide local DNS service. It just ask the ISP for internet addresses like google.com.
DNS is name resolution... You send a name and get back an IP address. Maybe IPv4 or IPv6, maybe both depending I know.
IP addressing scheme has NOTHING to do with DNS except as a cross reference.
SOME DHCP clients send a DNS update, but this tends to only be effective on locally administered DNS servers; Almost never ISC BIND based ones and is usually on Windows AD Domain controller DNS servers. You CAN configure DNS updates on ISC BIND, but I don't.
What you're thinking of as "link local address name resolution" actually relies on a multi-cast service known on Linux systems as Avahi and on everything else as Bonjour.
Avahi/Bonjour listens for the multicast broadcasts (from a Avahi/Bonjour process) as interfaces come online, and using routines in glibc, present the information for name resolution to the rest of the system. On Linux systems, this behavior is configured via the file /etc/nsswitch. I have DNS created by me such that if I do:
it works, on IPv4, because the local addresses are fixed.
The issue is replicating the behaviour when IPv6 comes my way with dynamic prefixes. If/when it does, I'll have to concoct a script to do it.
Browsers don't support or not support link local resolution... The system name resolution mechanisms have to be configured for it. How exactly? :-?
The DNS has no problem giving "FE80::21E:BFF:FE08:4CCB" as an answer, but no GUI browser will accept any FE80:: address with the required interface name attached. The support has been intentionally removed, and there is a several year old bugzilla on that.
What can be done on DNS to change this? :-?
You must be talking of something different.
Carlos, you have to do AAA records in the DNS zone file to resolve IPv6 addresses. IPv4 uses A records. But in the mean time, let me google that for you: https://www.cisco.com/c/en/us/support/docs/ip/ip-version-6-ipv6/113328-ipv6-... Link-local addresses are not necessarily bound to the MAC address (configured in a EUI-64 format). Link-local addresses can also be manually configured in the FE80::/10 format These addresses refer only to a particular physical link and are used for addressing on a single link for purposes such as automatic address configuration and neighbor discovery protocol. Link-local addresses can be used to reach the neighboring nodes attached to the same link. The nodes do not need a globally unique address to communicate. Routers will not forward datagrams using link-local addresses. IPv6 routers must not forward packets that have link-local source or destination addresses to other links. All IPv6 enabled interfaces have a link-local unicast address. Notice that link local isn't "necessarily" bound to a MAC address, so there no certain way to determine what interface it's associated with on a LAN (like with arp/rarp) Also notice they are used for AUTOMATIC ADDRESS CONFIGURATION. Routers WILL NOT forward them, so why would you be trying to use them as a permanent host address in a browser? Just for giggles, I happen to have a small block of "real", static IPv6 addresses and I configured one to a host local to my LAN. It works fine in my browser. I'm suspecting that you're banging face first into a violation of the standard. Browser makers know and follow [unless they're MS ;) ] the rules and, I'm guessing, simply discard link locals. As to HOW your system/glibc is configured to to perform name resolution, have a look at the man page for the file /etc/nsswitch. There ARE some uncommon options. I've used MySQL tables and LDAP in there along with YP/NIS, but it can be a wee touch tricky sometimes (NIS used to have a broken slave setup... Not that the binaries had bugs, just the packaged slave setup was incorrect and didn't correctly replicate. I'm not sure if anyone ever fixed that; Few use NIS anymore). I also saw an issue once where someone had deleted the nsswitch file; When that happens you can't ping 127.0.0.1 or localhost. Lots of stuff breaks. I've been running Suse systems for a VERY long time... Long enough that Avahi wasn't even present, let alone enabled, so my few remaining Suse systems don't run it. I made the mistake of turning it on in conjunction with pulse once and had to figure what the sudden traffic storm was. Interesting that OS X doesn't do that.
OS X comes that way, install certain Apple products on a Windows system and you get the needed configs. Linux, you get to fiddle a bit.
Just for fun, fire up Avahi on your system and watch the multicast range... For real fun, turn on pulse audio audio streaming and see what your network does.
Avahi service is running by default on most opensuse machines since years ago.
Telcontar:~ # systemctl status avahi-daemon ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2019-08-08 12:39:39 CEST; 3 days ago Main PID: 1583 (avahi-daemon) Status: "Server startup complete. Host name is Telcontar.local. Local service cookie is 203941546." Tasks: 1 (limit: 4915) CGroup: /system.slice/avahi-daemon.service └─1583 avahi-daemon: running [Telcontar.local]
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. Telcontar:~ #
There is a reason most router discard multicast and why at one point in time they "invented" the mbone. Multicast can be a VERY not nice thing.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org