Hi guys, Firstly, sorry if this may sound too newbie for the list. Reading the discussion about dhcpv6 vs RAs, this question just popped in my mind. It seems that most of IPv6 addressing for hosts will be choosed using EUI-64 method. Considering that no one (specially endusers) will bother to memorize an IPv6 prefix plus a mac address, integration between DNS servers and routers/dhcpv6 servers will be crucial. For dhcp there is already a mechanism for updating names in the DNS server for dynamically assigned IPs. I suppose it will be used (use some modifications) for IPv6. However, I never heard of anything similar for routers (in the case of autoconfigured addresses). Are there any dns servers that support updates from routers ?
On Sat, Jun 11, 2011 at 10:30:26PM -0300, Fabio Mendes wrote:
Firstly, sorry if this may sound too newbie for the list. Reading the discussion about dhcpv6 vs RAs, this question just popped in my mind.
It seems that most of IPv6 addressing for hosts will be choosed using EUI-64 method. Considering that no one (specially endusers) will bother to memorize an IPv6 prefix plus a mac address, integration between DNS servers and routers/dhcpv6 servers will be crucial.
For dhcp there is already a mechanism for updating names in the DNS server for dynamically assigned IPs. I suppose it will be used (use some modifications) for IPv6.
However, I never heard of anything similar for routers (in the case of autoconfigured addresses).
Are there any dns servers that support updates from routers ?
The router isn't assigning an address, it's merely telling everyone on the segment what the local prefix and default route is. As such, there's no reason why the router should try to register a DNS entry. On the other hand, the host could (and should) register it's address with whatever DNS server handles it's name. The protocol for such is already standardised and should be independent of IPv4/IPv6. - Matt
The router isn't assigning an address, it's merely telling everyone on the segment what the local prefix and default route is. As such, there's no reason why the router should try to register a DNS entry.
1) configure the router without knowing the address? Kind regards, Ingo Flaschberger
2011/6/11 Matthew Palmer <mpalmer@hezmatt.org>
The router isn't assigning an address, it's merely telling everyone on the segment what the local prefix and default route is. As such, there's no reason why the router should try to register a DNS entry.
On the other hand, the host could (and should) register it's address with whatever DNS server handles it's name. The protocol for such is already standardised and should be independent of IPv4/IPv6.
- Matt
Thanks Matt. I was thinking about something like this, it looks the natural way to go, but isn't too dangerous allow hosts to update entries (even if it's their own) in an DNS server ? I preferred to believe that a router would do this because routers are considered to be more reliable than a hosts. In the other hand, I also recognize that this could put a lot of weight in routers' CPU processing. Do you mind to point me out where can I find infos about this protocol that is being standardised ? Fábio
On 12 Jun 2011, at 09:38, Fabio Mendes wrote:
2011/6/11 Matthew Palmer <mpalmer@hezmatt.org>
The router isn't assigning an address, it's merely telling everyone on the segment what the local prefix and default route is. As such, there's no reason why the router should try to register a DNS entry.
On the other hand, the host could (and should) register it's address with whatever DNS server handles it's name. The protocol for such is already standardised and should be independent of IPv4/IPv6.
- Matt
Thanks Matt.
I was thinking about something like this, it looks the natural way to go, but isn't too dangerous allow hosts to update entries (even if it's their own) in an DNS server ?
I preferred to believe that a router would do this because routers are considered to be more reliable than a hosts. In the other hand, I also recognize that this could put a lot of weight in routers' CPU processing.
Routers route packets, otherwise they would be called registrars or something like that. -as
dynamic dns update has been done by hosts for some time... http://www.ietf.org/rfc/rfc2136.txt On Jun 12, 2011, at 5:38 AM, Fabio Mendes wrote:
2011/6/11 Matthew Palmer <mpalmer@hezmatt.org>
The router isn't assigning an address, it's merely telling everyone on the segment what the local prefix and default route is. As such, there's no reason why the router should try to register a DNS entry.
On the other hand, the host could (and should) register it's address with whatever DNS server handles it's name. The protocol for such is already standardised and should be independent of IPv4/IPv6.
- Matt
Thanks Matt.
I was thinking about something like this, it looks the natural way to go, but isn't too dangerous allow hosts to update entries (even if it's their own) in an DNS server ?
I preferred to believe that a router would do this because routers are considered to be more reliable than a hosts. In the other hand, I also recognize that this could put a lot of weight in routers' CPU processing.
Do you mind to point me out where can I find infos about this protocol that is being standardised ?
Fábio
On Sun, Jun 12, 2011 at 09:38:32AM -0300, Fabio Mendes wrote:
2011/6/11 Matthew Palmer <mpalmer@hezmatt.org>
The router isn't assigning an address, it's merely telling everyone on the segment what the local prefix and default route is. As such, there's no reason why the router should try to register a DNS entry.
On the other hand, the host could (and should) register it's address with whatever DNS server handles it's name. The protocol for such is already standardised and should be independent of IPv4/IPv6.
I was thinking about something like this, it looks the natural way to go, but isn't too dangerous allow hosts to update entries (even if it's their own) in an DNS server ?
What are the hazards and risks?
I preferred to believe that a router would do this because routers are considered to be more reliable than a hosts.
Reliable, or trusted?
Do you mind to point me out where can I find infos about this protocol that is being standardised ?
RFC2136. - Matt
On Sat, Jun 11, 2011 at 9:04 PM, Matthew Palmer <mpalmer@hezmatt.org> wrote:
On Sat, Jun 11, 2011 at 10:30:26PM -0300, Fabio Mendes wrote:
The router isn't assigning an address, it's merely telling everyone on the segment what the local prefix and default route is. As such, there's no reason why the router should try to register a DNS entry.
However, it would be logical to extend the DHCPv6 protocol to allow for registration of the workstation address in DNS by the DHCPv6 management server to be requested (similar to DHCPv4). The DHCPv6 management server needs to become aware of new IP addresses already to send ordinary unicast responses, and a DHCPv6 server is a central server that can be entrusted with the capability to update DNS records, with no need for overtrusting each individual client, or requiring a complicated authentication scheme on DNS servers, for clients to update DNS records corresponding to their own hostname, without each client's credentials being capable of updating any other machine's DNS entry. -- -JH
On Sun, Jun 12, 2011 at 08:59:50AM -0500, Jimmy Hess wrote:
On Sat, Jun 11, 2011 at 9:04 PM, Matthew Palmer <mpalmer@hezmatt.org> wrote:
The router isn't assigning an address, it's merely telling everyone on the segment what the local prefix and default route is. As such, there's no reason why the router should try to register a DNS entry.
However, it would be logical to extend the DHCPv6 protocol to allow for registration of the workstation address in DNS by the DHCPv6 management server to be requested (similar to DHCPv4).
I don't believe we were talking about DHCPv6, we were talking about SLAAC. And I *still* think it's a better idea for the client to be registering itself in DNS; the host knows what domain(s) it should be part of, and hence which names refer to itself and should be updated with it's new address. - Matt
On 6/12/2011 11:44 AM, Matthew Palmer wrote:
I don't believe we were talking about DHCPv6, we were talking about SLAAC. And I *still* think it's a better idea for the client to be registering itself in DNS; the host knows what domain(s) it should be part of, and hence which names refer to itself and should be updated with it's new address.
Register with "what/which" DNS? If no DHCPv6 no DNS information has been acquired, so you're doing the magical anycast/multicast. Not a fan of self-registration, in IPv4 we have DHCP register the DDNS update; after all, it just handed out an address for a zone/domain that *it* knows for certain. The host "knows what domains it should be part of" ?? Perhaps a server or a fixed desktop, but otherwise (unless you're a big fan of ActiveDirectory anywhere) the domain is relative to the environment you just inherited. Letting any host register itself in my domain from any address/location is scary as heck :) Jeff
On Jun 12, 2011, at 1:46 20PM, Jeff Kell wrote:
On 6/12/2011 11:44 AM, Matthew Palmer wrote:
I don't believe we were talking about DHCPv6, we were talking about SLAAC. And I *still* think it's a better idea for the client to be registering itself in DNS; the host knows what domain(s) it should be part of, and hence which names refer to itself and should be updated with it's new address.
Register with "what/which" DNS? If no DHCPv6 no DNS information has been acquired, so you're doing the magical anycast/multicast.
Not a fan of self-registration, in IPv4 we have DHCP register the DDNS update; after all, it just handed out an address for a zone/domain that *it* knows for certain.
The host "knows what domains it should be part of" ?? Perhaps a server or a fixed desktop, but otherwise (unless you're a big fan of ActiveDirectory anywhere) the domain is relative to the environment you just inherited.
Letting any host register itself in my domain from any address/location is scary as heck :)
Not any host -- hosts you authorize to register in your zone, and give the proper authentication credentials. I want my hosts to register in my domain, even if they're getting credentials from a random hotel or hotspot DHCP server. There are two different models here. A DHCP server should have the sole right to register in its affiliated DNS servers (including especially the inverse map). A host should have the right -- not necessarily the sole right -- to register in a forward tree. --Steve Bellovin, https://www.cs.columbia.edu/~smb
On Sun, Jun 12, 2011 at 01:46:20PM -0400, Jeff Kell wrote:
On 6/12/2011 11:44 AM, Matthew Palmer wrote:
I don't believe we were talking about DHCPv6, we were talking about SLAAC. And I *still* think it's a better idea for the client to be registering itself in DNS; the host knows what domain(s) it should be part of, and hence which names refer to itself and should be updated with it's new address.
Register with "what/which" DNS? If no DHCPv6 no DNS information has been acquired, so you're doing the magical anycast/multicast.
RFC6106, or local recursive resolver. Also, recursive resolution is not the same as DDNS registration with an authoritative server.
Not a fan of self-registration, in IPv4 we have DHCP register the DDNS update; after all, it just handed out an address for a zone/domain that *it* knows for certain.
No, it handed out *an* *address*. Assuming that everything that wants an address also wants the whole shebang is a whole other issue.
The host "knows what domains it should be part of" ?? Perhaps a server or a fixed desktop, but otherwise (unless you're a big fan of ActiveDirectory anywhere) the domain is relative to the environment you just inherited.
No it isn't. If I want someone to talk to my laptop, and I happen to be roadwarrioring at a client site, do I want to say "hey, just hit floozy.hezmatt.org", or do I want to have to ask someone "what domain will my laptop be registered as?" and then work it out from there?
Letting any host register itself in my domain from any address/location is scary as heck :)
So don't do that, then. Only let hosts that you want to have in your domain register whatever their current address is. - Matt -- A polar bear is a rectangular bear after a coordinate transform.
On Mon, 2011-06-13 at 01:44 +1000, Matthew Palmer wrote:
And I *still* think it's a better idea for the client to be registering itself in DNS; the host knows what domain(s) it should be part of, and hence which names refer to itself and should be updated with it's new address.
Having tried that, we ended up doing it via DHCP (v4 at the time). We only had probably 15-20K hosts trying to register their names, but the results were sobering. At a rough estimate, one in a hundred was properly configured. We saw obscenities, random strings, thousand-byte names, empty names, invalid names, names with a hundred labels, "my name is Andrew" - you name it, it came and tried to register itself. And then there were the clients. Clients that tried as fast as they could to register their name dozens of times per second, clients that tried to register many names, clients that registered and then immediately deregistered their names, clients that never deregistered their names at all, clients that tried to register important names like "www.ourdomain", clients that had completely broken protocol support... Our logs were filling at thousands of lines per second. So we moved the job to the DHCP server, and most of the problems went away. The server got the desired name from the client, could check it for some level of sanity and could register it properly. The server could also deregister the names when the clients went away, or at least at the end of the lease period. Most hosts *did* speak the DHCP protocol adequately well. Instead of having to allow open slather, we could allow just two hosts to make TSIG-protected updates. The logs became useful again. So although YMMV, I can highly recommend letting your DHCP servers do DDNS instead of letting the clients do it themselves. No doubt it depends on a multitude of factors, not least being whether you actually use DHCP, but in general, it worked a LOT better for us. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
On Mon, Jun 13, 2011 at 09:56:59AM +1000, Karl Auer wrote:
On Mon, 2011-06-13 at 01:44 +1000, Matthew Palmer wrote:
And I *still* think it's a better idea for the client to be registering itself in DNS; the host knows what domain(s) it should be part of, and hence which names refer to itself and should be updated with it's new address.
Having tried that, we ended up doing it via DHCP (v4 at the time).
We only had probably 15-20K hosts trying to register their names, but the results were sobering. At a rough estimate, one in a hundred was properly configured. We saw obscenities, random strings, thousand-byte names, empty names, invalid names, names with a hundred labels, "my name is Andrew" - you name it, it came and tried to register itself.
Why were you letting such ill-configured clients register themselves in your DNS?
And then there were the clients. Clients that tried as fast as they could to register their name dozens of times per second, clients that tried to register many names, clients that registered and then immediately deregistered their names, clients that never deregistered their names at all, clients that tried to register important names like "www.ourdomain", clients that had completely broken protocol support...
Ibid.
So we moved the job to the DHCP server, and most of the problems went away. The server got the desired name from the client, could check it for some level of sanity and could register it properly. The server could also deregister the names when the clients went away, or at least at the end of the lease period. Most hosts *did* speak the DHCP protocol adequately well. Instead of having to allow open slather, we could allow just two hosts to make TSIG-protected updates. The logs became useful again.
But if I come to roadwarrior in your network, I'd have to allow updates from your DHCP server, and your DHCP server would have to be sending those updates. Similarly, if your clients go roadwarrioring elsewhere, the same (or, rather, inverse) configuration would have to be done there.
So although YMMV, I can highly recommend letting your DHCP servers do DDNS instead of letting the clients do it themselves. No doubt it depends on a multitude of factors, not least being whether you actually use DHCP, but in general, it worked a LOT better for us.
If you've just got a single-location, never-goes-anywhere network and client list, sure you can just get the DHCP server to do the registration. But if you've got that setup, DDNS isn't needed at all -- your set of hosts, addresses, and names is fixed sufficiently that you can just statically allocate everything. - Matt
On Mon, 2011-06-13 at 11:16 +1000, Matthew Palmer wrote:
Why were you letting such ill-configured clients register themselves in your DNS?
Some environments have a lot of control over individual hosts, and perhaps for such an environment, allowing hosts to register themselves would not be a problem. In our environment, we had little control over individual hosts, so centralising their registration through DHCP servers was a much more effective way to do things, for all the reasons I gave.
And then there were the clients. [...] Ibid.
Matthew, did you read my message? This was the *point*. We had lots of poorly configured hosts, over which we could exercise little control. Faced with that situation, and seeing how poorly the hosts performed when allowed to (attempt to) register themselves in the DNS, we decided instead to allow DDNS only from our DHCP servers. That worked very well for us - especially as the vast majority of the hosts connected to our network didn't really need DNS names anyway. When a poorly configured host that did need a name failed to register itself, the owner/administrator of that host would eventually come to us, so the problem was sort of self-correcting.
But if I come to roadwarrior in your network, I'd have to allow updates from your DHCP server, and your DHCP server would have to be sending those updates. Similarly, if your clients go roadwarrioring elsewhere, the same (or, rather, inverse) configuration would have to be done there.
Yes, that would be true for any roadwarrior needing/wanting a DNS entry. But in our environment, we didn't have roadwarriors (at least none that needed DNS entries), so it wasn't a problem. If faced with that (and depending on the scale of the problem) I'd probably set up some sort of TSIG key distribution system and let the roadwarriors self-register... dunno. Not a problem I've personally had to solve.
If you've just got a single-location, never-goes-anywhere network and client list, sure you can just get the DHCP server to do the registration. But if you've got that setup, DDNS isn't needed at all -- your set of hosts, addresses, and names is fixed sufficiently that you can just statically allocate everything.
Noooooo! Statically allocating everything in a network where there are 200-1000 DHCP and DNS-related changes every day? No way! While we had a negligible number of "road warriors" - people outside their enterprise networks getting address service from us or our people outside our enterprise network getting address service from others - we had PLENTY of churn inside our enterprise. People moving laptops from subnet to subnet, or moving labs or departments or other groupings around. There were still huge benefits to be had from an automated system. DHCP with DDNS is a great system. Of course it has limitations; I just wanted to point out its strengths. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
participants (9)
-
Arturo Servin -
Fabio Mendes -
Ingo Flaschberger -
Jeff Kell -
Jimmy Hess -
Joel Jaeggli -
Karl Auer -
Matthew Palmer -
Steven Bellovin