IPv6 and DNS

Mailman List Mirror (Read Only)
1

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 ?

2

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

3

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

4

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

5

Routers route packets, otherwise they would be called registrars or something like that.

-as

6

dynamic dns update has been done by hosts for some time...

http://www.ietf.org/rfc/rfc2136.txt

7

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.

8

> 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

9

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

10

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 :slight_smile:

Jeff

11

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

12

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.

13

> 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 :slight_smile:

So don't do that, then. Only let hosts that you want to have in your domain
register whatever their current address is.

- Matt

14

> 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

15

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.