Subject: [renum] Dynamic DNS Update Deployment??

From: "Leo Liu(bing)" <[email-masked]>
Date: Mon, 15 Aug 2011 01:32:48 +0000

Hi, all

We used to have a brief discussion about dynamic DNS update in in IPv6 renum mail list([email-masked]<mailto:[email-masked]>), and it was considered as a mechanism to improve renumbering automation greatly.
As we discussed, although RFC3007(Secure DNS Dynamic Update) is reportedly widely implemented, widely available, and widely interoperable today but not widely deployed.
So I'm here to ask you DNS pro how about the rfc3007 and rfc2136(Dynamic Updates in DNS) deployment state in real networks? Do you think they are worth to be deployed in the name of improving renumbering?

---

From: "Leo Liu(bing)" <[email-masked]>
Date: Mon, 15 Aug 2011 08:26:21 +0000

Hi, Måns

Thanks for the info, that's quite helpful. So can we assume that Windows-based DNS systems have been widely deployed rfc3007?

B.R.
Bing

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> M?ns Nilsson
> Sent: Monday, August 15, 2011 2:33 PM
> To: Leo Liu(bing)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [DNSOP] Dynamic DNS Update Deployment??
> 
> Subject: [DNSOP] Dynamic DNS Update Deployment?? Date: Mon, Aug 15,
> 2011 at 01:32:48AM +0000 Quoting Leo Liu(bing) ([email-masked]):
> > Hi, all
> >
> > We used to have a brief discussion about dynamic DNS update in in IPv6
> renum mail list([email-masked]<mailto:[email-masked]>), and it was
> considered as a mechanism to improve renumbering automation greatly.
> > As we discussed, although RFC3007(Secure DNS Dynamic Update) is
> reportedly widely implemented, widely available, and widely interoperable
> today but not widely deployed.
> > So I'm here to ask you DNS pro how about the rfc3007 and rfc2136(Dynamic
> Updates in DNS) deployment state in real networks? Do you think they are
> worth to be deployed in the name of improving renumbering?
> 
> Since every Windows admin / consultant I've spoken to lately insists that
> Windows DNSes with AD integration be used  for anything related to name
> resolution, and cites dynamic updates as a reason for this, there is some
> anecdotal evidence that suggests the usage and importance of dynamic
> updates. Also, one must assume some deployment.
> 
> --
> Måns Nilsson     primary/secondary/besserwisser/machina
> MN-1334-RIPE                             +46 705 989668
> I just heard the SEVENTIES were over!!  And I was just getting in touch with
> my LEISURE SUIT!!

---

From: "Leo Liu(bing)" <[email-masked]>
Date: Mon, 15 Aug 2011 10:27:47 +0000

Thanks, Måns. Excuse my question closely:
Is authentication of dynamic update considered as "MUST" requirement in current networks? For the "insecure" methods, is there any other ones besides rfc2136 (Dynamic Updates in the Domain Name System) ?  

> From: Måns Nilsson [mailto:[email-masked]]
> Sent: Monday, August 15, 2011 5:18 PM
> To: Leo Liu(bing)
> Subject: RE: [DNSOP] Dynamic DNS Update Deployment?? Date: Mon, Aug 15,
> 2011 at 08:26:21AM +0000 Quoting Leo Liu(bing) ([email-masked]):
> > Hi, Måns
> >
> > Thanks for the info, that's quite helpful. So can we assume that
> Windows-based DNS systems have been widely deployed rfc3007?
> 
> No. They _do_ use dynamic updates, but they use GSS-TSIG (More or less
> according to rfc3645) to authenticate. My point was, perhaps less than well
> stated, that dynamic updates are frequently used.
> 
> As to the division between authentication methods, I'd _guess_ that GSS-TSIG
> leads, followed by http (dyndns.org et. al.) and the other methods in a long tail
> with "insecure updates" forming a serious bump in said tail.
> 
> --
> First, I'm going to give you all the ANSWERS to today's test ...  So just plug in
> your SONY WALKMANS and relax!!

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 15 Aug 2011 08:33:21 +0200

> So I'm here to ask you DNS pro how about the rfc3007 and rfc2136(Dynamic Updates in DNS) deployment state in real networks? Do you think they are worth to be deployed in the name of improving renum…

Since every Windows admin / consultant I've spoken to lately insists
that Windows DNSes with AD integration be used  for anything related
to name resolution, and cites dynamic updates as a reason for this,
there is some anecdotal evidence that suggests the usage and importance
of dynamic updates. Also, one must assume some deployment.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I just heard the SEVENTIES were over!!  And I was just getting in touch
with my LEISURE SUIT!!

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 15 Aug 2011 11:17:50 +0200

No. They _do_ use dynamic updates, but they use GSS-TSIG (More or less
according to rfc3645) to authenticate. My point was, perhaps less than
well stated, that dynamic updates are frequently used. 

As to the division between authentication methods, I'd _guess_ that
GSS-TSIG leads, followed by http (dyndns.org et. al.) and the other
methods in a long tail with "insecure updates" forming a serious bump
in said tail.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
First, I'm going to give you all the ANSWERS to today's test ...  So
just plug in your SONY WALKMANS and relax!!

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 15 Aug 2011 13:02:59 +0200

> Is authentication of dynamic update considered as "MUST" requirement in current networks? For the "insecure" methods, is there any other ones besides rfc2136 (Dynamic Updates in the Domain Name Sys…

	(This starts to sound like I'm doing someones homework. If it
	 is so, I probably know your teacher...)

Anyway, in _my_ book, authentication is required for any sensible
rollout[0]. I'd like to be able to use all methods, in parallel.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
hubub, hubub, HUBUB, hubub, hubub, hubub, HUBUB, hubub, hubub, hubub.

[0]	Possible exception being AS112 service, where we (as 
	someone suggested) should accept the updates, serve them out to
	others, and roast wild boar over the resulting fire.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Aug 2011 17:55:53 +0000

On Aug 15, 2011, at 1:26 AM, Leo Liu(bing) wrote:
Thanks for the info, that's quite helpful. So can we assume that Windows-based DNS systems have been widely deployed rfc3007?

This is kind of a bizarre conversation.   DDNS use is widespread in environments that support DHCPv4, although it is by no means pervasive.   It's not a Windows thing—it's generally done by DHCP servers, not DHCP clients.   DNS update by clients is somewhat rare, although it is supported by Windows.   Unfortunately Apple has chosen not to support it, but in practice it's not important because key distribution for DNS updates is such a big problem that it usually doesn't make sense to do it from end nodes—only from servers.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Aug 2011 08:19:21 +1200

> This is kind of a bizarre conversation.   DDNS use is widespread in environments that support DHCPv4, although it is by no means pervasive.   It's not a Windows thing—it's generally done by DHCP se…

In the context of the 6renum WG, that is a very important point.
We need to figure out the best way to automate the DNS
consequences of adding a new IPv6 prefix, or removing an old
one, in all or part of an enterprise network. So we need to
understand how it interacts with DHCPv6. Basically I think
you're saying that in real life we can't expect end hosts to be
responsible for their own DNS updates when renumbered, because
that requires an unreasonable key distribution mechanism.

    Brian

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 15 Aug 2011 22:34:53 +0200

> that requires an unreasonable key distribution mechanism.

Unless that's been taken care of -- the Active Directory model does
work. And, since the authority for forward and reverse may vary, forward updates
is better dealt with by the client (think mobile client that wants its
domain name with any IP address), while reverse is best performed by
the address authority, ie. DHCP(v6) server. The paper/how-to that came
out of a RIPE meeting workshop some years ago details this division of
work quite nicely.

http://www.ops.ietf.org/dns/dynupd/secure-ddns-howto.html

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Give them RADAR-GUIDED SKEE-BALL LANES and VELVEETA BURRITOS!!

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Aug 2011 20:48:53 +0000

On Aug 15, 2011, at 1:19 PM, Brian E Carpenter wrote:

End hosts that use Kerberos do have a key distribution model that works, and I _think_ there's an RFC that describes how to do that, but I may be mistaken—it's not really my department.   I'd like to see the key problem solved, but as it stands I think Active Directory is the only system that really has it solved.

---

From: Stephen Jacob <[email-masked]>
Date: Mon, 15 Aug 2011 14:09:00 -0700

On Mon, Aug 15, 2011 at 10:34:53PM +0200, M??ns Nilsson wrote:
> > > This is kind of a bizarre conversation.   DDNS use is widespread
> > > in environments that support DHCPv4, although it is by no means
> > > pervasive.   It's not a Windows thing???it's generally done by
> > > DHCP servers, not DHCP clients.   DNS update by clients is
> > > somewhat rare, although it is supported by Windows.
> > > Unfortunately Apple has chosen not to support it, but in practice
> > > it's not important because key distribution for DNS updates is
> > > such a big problem that it usually doesn't make sense to do it
> > > from end nodes???only from servers.
> > 
> work. And, since the authority for forward and reverse may vary,
> forward updates is better dealt with by the client (think mobile
> client that wants its domain name with any IP address), while reverse
> is best performed by the address authority, ie. DHCP(v6) server. The
> paper/how-to that came out of a RIPE meeting workshop some years ago
> details this division of work quite nicely.
> 

Other than for weirdos like some of us in this group, I think the
overwhelming majority of users do not in fact have administrative
control over the forward zone nor is there a good security model
for it nor way of distributing keys. For the overwhelming majority
of hosts, I believe their forward zone is likely to be
something.isp.com. This is why, as Ted alludes to, servers (DHCP,
whether v4 or v6) tend to do the updates.

Indeed, in spite of being a weirdo I don't try to do my own forward
zone dynamic DNS updates.

Regards,
Stephen
-- 
 Stephen Jacob | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 16 Aug 2011 02:12:25 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian E Carpenter
> Sent: Tuesday, August 16, 2011 4:19 AM
> To: Ted Lemon
> Cc: [email-masked]; Måns Nilsson; [email-masked]
> Subject: Re: [renum] [DNSOP] Dynamic DNS Update Deployment??
> 
> > This is kind of a bizarre conversation.   DDNS use is widespread in
> environments that support DHCPv4, although it is by no means pervasive.
> It's not a Windows thing—it's generally done by DHCP servers, not DHCP
> clients.   DNS update by clients is somewhat rare, although it is
> supported by Windows.   Unfortunately Apple has chosen not to support
> it, but in practice it's not important because key distribution for DNS
> updates is such a big problem that it usually doesn't make sense to do
> it from end nodes—only from servers.
> 

There is another mechanism can work out: in renumbering case, renumbered end-hosts need to registry (we are now defining this in DHC WG) their new addresses to registration server, which can be DHCPv6 server. After that, it is DHCPv6 server's work to update correspondent DNS records. This can be complete using the existing protocols.

Sheng
 
>     Brian
> 
> _______________________________________________
> renum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/renum

---

From: "Leo Liu(bing)" <[email-masked]>
Date: Tue, 16 Aug 2011 02:20:03 +0000

Thanks, Måns. Not homework, but contribution to the 6renum WG : )
DDNS is an important topic in renumbering.

> Sent: Monday, August 15, 2011 7:03 PM
> To: Leo Liu(bing)
> 2011 at 10:27:47AM +0000 Quoting Leo Liu(bing) ([email-masked]):
> > Is authentication of dynamic update considered as "MUST" requirement in
> current networks? For the "insecure" methods, is there any other ones besides
> rfc2136 (Dynamic Updates in the Domain Name System) ?
> 
> Anyway, in _my_ book, authentication is required for any sensible rollout[0]. I'd
> like to be able to use all methods, in parallel.
> 
> --

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Aug 2011 13:36:35 +1000

In message <[email-masked]>, =?utf-8?B?TcOlbnM=?= Nils
son writes:
> Subject: Re: [renum] [DNSOP] Dynamic DNS Update Deployment?? Date: Tue, Aug=
>  16, 2011 at 08:19:21AM +1200 Quoting Brian E Carpenter (brian.e.carpenter@=
> gmail.com):
> > > Thanks for the info, that's quite helpful. So can we assume that Window=
> s-based DNS systems have been widely deployed rfc3007?
> > >=20
> > > This is kind of a bizarre conversation.   DDNS use is widespread in env=
> ironments that support DHCPv4, although it is by no means pervasive.   It's=
>  not a Windows thing=E2=80=94it's generally done by DHCP servers, not DHCP =
> clients.   DNS update by clients is somewhat rare, although it is supported=
>  by Windows.   Unfortunately Apple has chosen not to support it, but in pra=
> ctice it's not important because key distribution for DNS updates is such a=
>  big problem that it usually doesn't make sense to do it from end nodes=E2=
> =80=94only from servers.

Apple supports TSIG updates.  It's just not on by default.

http://docs.info.apple.com/article.html?path=Mac/10.6/en/27452.html

It also doesn't work when hotels decide that they need to intercept
the DNS.

> work. And, since the authority for forward and reverse may vary, forward up=
> dates
> --=20
> M=C3=A5ns Nilsson     primary/secondary/besserwisser/machina
> --k+G3HLlWI7eRTl+h
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: Digital signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> 
> iEYEARECAAYFAk5Jgu0ACgkQ02/pMZDM1cXTXQCeM+JMkXrEc4K/sWOtv6vZ5OjR
> GlkAn1o3tE/FewNvGyWUQgTqwG2uvqyp
> =Olgz
> -----END PGP SIGNATURE-----
> 
> --k+G3HLlWI7eRTl+h--
> 
> --===============1894226356209510608==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> --===============1894226356209510608==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Aug 2011 04:00:32 +0000

On Aug 15, 2011, at 8:36 PM, Mark Andrews wrote:
Apple supports TSIG updates.  It's just not on by default.

That's okay—If you're in a hotel, you don't have a working Internet connection anyway, so the update isn't needed.   Thanks for the pointer—I went looking for the dialog that set this up, but couldn't find it under Networking, where I expected it… :}

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Aug 2011 16:27:07 +1200

> There is another mechanism can work out: in renumbering case, renumbered end-hosts need to registry (we are now defining this in DHC WG) their new addresses to registration server, which can be DHC…

As long as that process is at least as secure as DNSSEC, so that
DNSSEC is not compromised, that is certainly an alternative.
However, it makes DHCPv6 mandatory for automatic renumbering.
That may be a "political" decision as well as a technical one.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Aug 2011 14:46:45 +1000

In message <[email-masked]>, Ted Lemon writes
:
> --_000_9B496F112AF14733AE3D8A609FC2FEA5nominumcom_
> Content-Type: text/plain; charset="Windows-1252"
> Content-Transfer-Encoding: quoted-printable
> 
> http://docs.info.apple.com/article.html?path=3DMac/10.6/en/27452.html
> 
> That's okay=97If you're in a hotel, you don't have a working Internet conne=
> ction anyway, so the update isn't needed.   Thanks for the pointer=97I went=
>  looking for the dialog that set this up, but couldn't find it under Networ=
> king, where I expected it=85 :}
 
Actually it stinks as it breaks lots of things for no good reason.

For hotspots where you need to register a DHCP options would be infinitely
better than trying to intercept DNS/HTTP.  At least then you know that you
need to register.

	HOTSPOT <url>

	e.g.
		http://192.0.2.1/hotspot-registration.html
		http://[2001:DB8::1]/hotspot-registration.html

Note: no dependancy on DNS working until the registration is complete.

If the OS doesn't request HOTSPOT you leave the old methods still enabled
but if the DHCP request asks for HOTSPOT you stop attempting to intercept
DNS and HTTP queries.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Aug 2011 05:05:15 +0000

On Aug 15, 2011, at 9:27 PM, Brian E Carpenter wrote:

"As secure as DNSSEC" is not always the required level of security.   For instance, at my office, roaming laptops can provide a name which is used to update a DNS record in a well-known zone.   However, they cannot insert arbitrary records—just A and/or AAAA records.   And they cannot insert them into arbitrary zones.   So the security requirements here are substantially less stringent than they would be in the case that a client had a key that allowed it to do arbitrary updates to a zone.

As for the political layer, I don't really see the problem.   If people want DNS updates, there's going to be some kind of mechanism for it.   If they don't, it's not a problem.   Presumably in environments where autoconfig is the rule, either clients have keys with which to update the DNS, or else they do not need to update the DNS (e.g., they are using mdns or Bonjour, and do not need a globally-visible name).

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 16 Aug 2011 08:22:02 +0200

> DDNS is an important topic in renumbering.

Please accept my apologies! I'm happy if I can help.

Best regards, 
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
The Osmonds!  You are all Osmonds!!  Throwing up on a freeway at dawn!!!

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Aug 2011 21:58:05 +1000

In message <[email-masked]>, Tony F
inch writes:
> Mark Andrews <[email-masked]> wrote:
> >
> Requires a bit of extra setup on the server side since it needs wide-area
> Bonjour / DNS service discovery records in the zone. For example,
> http://www.dyndns.com/support/kb/apple_wide_area_bonjour_and_service_discover
> y_with_custom_dns.html

Wide area Bonjour is a seperate issue.  Note the second check box
on the dialog is for doing that.

Mac OS X will send the UPDATE to the nameservers for the zone if
there isn't a _dns-update._udp srv record.  DynDNS says to add the
srv record as they have a seperate update server.

> Tony.
> -- 
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
> Sole: Variable 3 or 4 becoming northeast 4 or 5, occasionally 6 later. Slight
> or moderate. Thundery rain at times. Good, occasionally poor.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Aug 2011 22:11:34 +1000

In message <[email-masked]>, Ted Lemon writes
:
> "As secure as DNSSEC" is not always the required level of security.   For i=
> nstance, at my office, roaming laptops can provide a name which is used to =
> update a DNS record in a well-known zone.   However, they cannot insert arb=
> itrary records=97just A and/or AAAA records.   And they cannot insert them =
> into arbitrary zones.   So the security requirements here are substantially=
>  less stringent than they would be in the case that a client had a key that=
>  allowed it to do arbitrary updates to a zone.

There is also two zones to update and different security requirement for
different types.  TCP is often sufficient authentication for PTR records
in the reverse zone, where as TSIG/SIG(0) is needed for AAAA/A updates in
the forward zone.
 
> As for the political layer, I don't really see the problem.   If people wan=
> t DNS updates, there's going to be some kind of mechanism for it.   If they=
>  don't, it's not a problem.   Presumably in environments where autoconfig i=
> s the rule, either clients have keys with which to update the DNS, or else =
> they do not need to update the DNS (e.g., they are using mdns or Bonjour, a=
> nd do not need a globally-visible name).

---

From: Fred Baker <[email-masked]>
Date: Tue, 16 Aug 2011 09:43:48 -0700

> This is kind of a bizarre conversation.   DDNS use is widespread in environments that support DHCPv4, although it is by no means pervasive.   It's not a Windows thing—it's generally done by DHCP se…

I would expect that this is different with 

http://www.ietf.org/rfc/rfc4862.txt
4862 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten,
     T. Jinmei. September 2007. (Format: TXT=72482 bytes) (Obsoletes
     RFC2462) (Status: DRAFT STANDARD)

http://www.ietf.org/rfc/rfc4941.txt
4941 Privacy Extensions for Stateless Address Autoconfiguration in
     IPv6. T. Narten, R. Draves, S. Krishnan. September 2007. (Format:
     TXT=56699 bytes) (Obsoletes RFC3041) (Status: DRAFT STANDARD)

In both cases, the addresses are concocted by the system using them. For RFC 4862, that means "when the system receives a new prefix in an RA". My understanding is that Windows privacy addresses are generated daily and held for a week; I would expect other implementations to do something akin to that. I wouldn't not expect DHCP servers to be doing updates in a world in which the end host calculates its own address.

Do we know about that at all?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Aug 2011 17:34:20 +0000

On Aug 16, 2011, at 9:43 AM, Fred Baker wrote:
In both cases, the addresses are concocted by the system using them. For RFC 4862, that means "when the system receives a new prefix in an RA". My understanding is that Windows privacy addresses are generated daily and held for a week; I would expect other implementations to do something akin to that. I wouldn't not expect DHCP servers to be doing updates in a world in which the end host calculates its own address.

The DHC working group is working on a draft that leverages DHCPv6 to allow hosts to register SLAAC addresses, CGA addresses and other self-generated addresses with the network infrastructure.   Implementation would obviously be optional, but it's a good way to solve the problem—you can actually do it with DHCP already, but the mechanism hasn't been formally described or recommended.

I would expect client-side implementations to include a switch allowing the user to disable this functionality, but it is a useful way to do things like populate the reverse tree and populate/update AAAA records for clients that want or need this capability.

---

From: Fred Baker <[email-masked]>
Date: Tue, 16 Aug 2011 10:53:30 -0700

> I would expect client-side implementations to include a switch allowing the user to disable this functionality, but it is a useful way to do things like populate the reverse tree and populate/updat…

Seems reasonable. It has the same authenticity issues as DDNS; the fact that a system with an address announces a name doesn't make it so.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Aug 2011 18:06:40 +0000

On Aug 16, 2011, at 10:53 AM, Fred Baker wrote:
Seems reasonable. It has the same authenticity issues as DDNS; the fact that a system with an address announces a name doesn't make it so.

Yup.   Historically this hasn't been an issue: names are offered on a first-come, first-served basis, much like mdns.   Names that don't have DUID records can't be updated, so even if you update a common zone, there's no way for a client to get ftp.example.com<http://ftp.example.com>, for instance.   Typically names are deleted once the lifetime of the address has expired without renewal, so the system automatically cleans up stale name registrations.

---

From: Tony Finch <[email-masked]>
Date: Tue, 16 Aug 2011 12:06:09 +0100

Requires a bit of extra setup on the server side since it needs wide-area
Bonjour / DNS service discovery records in the zone. For example,
http://www.dyndns.com/support/kb/apple_wide_area_bonjour_and_service_discovery_with_custom_dns.html

Tony.

---

From: Tony Finch <[email-masked]>
Date: Tue, 16 Aug 2011 12:11:07 +0100

Ted Lemon <[email-masked]> wrote:
>
> "As secure as DNSSEC" is not always the required level of security.

Actually it's nonsense. DNSSEC secures the publication mechanism. The
security of the update mechanism is pretty much orthogonal. If your
updates are insecure your zone may be full of junk, but DNSSEC tells
people looking at the zone that it's authentic junk that was really
published by your dodgy master servers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin: Westerly or northwesterly 4 or 5, occasionally 6 at first,
becoming variable 3 in south. Moderate, occasionally rough until later.
Showers. Good.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Aug 2011 11:54:59 +1200

> published by your dodgy master servers.

And thus has no value to the user of the validated record.
That's my point: GIGO, so we have to prevent garbage-in. If you
don't classify that as a security requirement, fine, but it's an
operational requirement.

   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 17 Aug 2011 01:05:44 +0000

The draft Ted mentioned: http://tools.ietf.org/html/draft-jiang-dhc-addr-registration-03. It allows hosts to register their self-generated addresses through DHCPv6; then DHCPv6 server can update the new addresses to correspondent DNS. This draft would be called for DHC adoption soon. Further reviewing and comments are welcome, from any perspective.

Sheng

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Wednesday, August 17, 2011 1:34 AM
To: Fred Baker
Cc: [email-masked]; Måns Nilsson; [email-masked]
Subject: Re: [renum] [DNSOP] Dynamic DNS Update Deployment??

The DHC working group is working on a draft that leverages DHCPv6 to allow hosts to register SLAAC addresses, CGA addresses and other self-generated addresses with the network infrastructure.   Implementation would obviously be optional, but it's a good way to solve the problem-you can actually do it with DHCP already, but the mechanism hasn't been formally described or recommended.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Aug 2011 14:27:01 +1200

> As for the political layer, I don't really see the problem.   If people want DNS updates, there's going to be some kind of mechanism for it.   If they don't, it's not a problem.   Presumably in env…

Ted, all I meant by "political" is that it has been quite
controversial in IPv6-land whether DHCPv6 becomes a de facto
mandatory option, or whether sites can opt to use nothing but
SLAAC for some or all hosts. If the conclusion for 6renum is
that DHCPv6 is required, so be it, but the discussion might get
noisy.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Aug 2011 04:10:30 +0000

On Aug 16, 2011, at 4:54 PM, Brian E Carpenter wrote:
And thus has no value to the user of the validated record.
That's my point: GIGO, so we have to prevent garbage-in. If you
don't classify that as a security requirement, fine, but it's an
operational requirement.

DNSSEC ensures that what's in the zone was delivered from the authoritative name server to the validating resolver intact.   It doesn't promise that what's in the zone has any particular ontological status.   What's in the zone is in the zone on the basis of the local administrative policy for that zone.

I'm sure you can come up with a use case in which the fact that the name being inserted into the zone isn't validated to the same degree of security that DNSSEC provides.   So why don't you begin your argument there, rather than stating your conclusion as if it were both self-evidently true, and also true for all possible use cases.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Aug 2011 13:26:25 +0000

On Aug 16, 2011, at 7:27 PM, Brian E Carpenter wrote:

Hm.   Okay, this helps me to see where you were coming from with your other point about garbage in, garbage out.   If the problem you are trying to solve is that AAAA records of servers follow the server when you are renumbering, then you need secure DNS updates from the server that's being renumbered.   But that seems to be an unlikely use case to me: typically I would expect servers to have manually-assigned addresses, or else CGAs, but not SLAAC addresses.   Or perhaps addresses that are algorithmically assigned based on the prefix--prefix::1, as opposed to prefix::SLAAC.   In any case, you do not need DHCPv6 to solve this problem, and so if that is the use case you are talking about, DHCPv6 is definitely not required.

The case where you'd want to use DHCP is the case where non-server hosts are being renumbered.   In this case, the name the host claims to have is a convenience, and arguably of limited value anyway.   And so in that case I would argue that DHCPv6 is not _required_ either, although it may be convenient, depending on site policy.   I wouldn't expect it to be used at a public hotspot, for instance, but could easily imagine it being used on a non-guest corporate network.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Aug 2011 08:59:40 +0900

Leo Liu(bing) wrote:

> Not homework, but contribution to the 6renum WG : )

A problem is that IPv6 is unimportant mostly because of lack of
proper multihoming support which could have limited routing table
growth, which was why renumbering was necessary. But, it's too
late.

Ted Lemon wrote:

 > Okay, this helps me to see where you were coming from with
 > your other point about garbage in, garbage out.

In short, the garbage is SLAAC, which is not even stateless.

 > The case where you'd want to use DHCP is the case where
 > non-server hosts are being renumbered.

Automatic renumbering is most useful for site-wide renumbering
with provider changes.

Of course, the most difficult part is renumbering of glue,
which is solvable but ignored in this thread.

						Masataka Ohta

---

From: "Leo Liu(bing)" <[email-masked]>
Date: Thu, 18 Aug 2011 09:06:20 +0000

Hi, Masataka. Thanks for your comments, inline.

> Sent: Thursday, August 18, 2011 8:00 AM
> To: Leo Liu(bing)

Yes, there have been some people even argued " No multihoming, no IPv6". But the driven force of IPv6 deployment will strengthen more and more. If it is already late, then we couldn't wait anymore to do the necessary work :)

> Automatic renumbering is most useful for site-wide renumbering

Provider change is just a typical renumbering scenario. Any other scenarios such as new added uplink, internal network re-organization .etc, which cause large amount of hosts to change the address configurations would benefit very much from automatic renumbering process. 

> which is solvable but ignored in this thread.

Yes. How to systematically manage and update things like manually configured or deeply embedded addresses is a big challenge.