Subject: Fw: [dhcwg] DNS Registration for IATA address.

From: RamaSubramanian KrishnaMurthi <[email-masked]>
Date: Mon, 13 Aug 2007 10:06:30 -0700 (PDT)

Thanks for the reply. This means the DHCPClient should not send the FQDN options in the DHCP Packet for its non-Gobal Unicast addresses or temporary addresses and also client should not trigger DNS the update from the client end. am I right ?
If some client still sends the FQDN option in the packet, should the server do DNS update for the client ?

Thanks & Regards
-RamaSubbu SK 

----- Original Message ----
From: Shane Kerr <[email-masked]>
To: RamaSubramanian KrishnaMurthi <[email-masked]>
Cc: [email-masked]
Sent: Monday, August 13, 2007 9:00:09 PM
Subject: Re: [dhcwg] DNS Registration for IATA address.

RamaSubramanian KrishnaMurthi wrote:
> Hi all, 
> I have basic question on DNS Registration  + DHCPv6.
> For IATA whether the DHCPClient should register its ipv6 address to the DNS Server ?
> For IATA whether the DHCPServer should register the client's ipv 6address to the DNS Server [FQDN ]?
> 
> RFC 4704 doesn't talk about IANA & IATA. Correct/help me in this regards.

Good question!

There is some text about IA_TA:

   A client SHOULD NOT perform DNS updates to AAAA RRs for its non-
   Global Unicast addresses [7] or temporary addresses [6].

In general I would say that temporary addresses should not have their reverse
DNS updated. Other opinions?

You are correct that it is not explicit in the specification. :(

- --
Shane

____________________________________________________________________________________
Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz

____________________________________________________________________________________
Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 13 Aug 2007 11:20:24 -0500

> Thanks for the reply. This means the DHCPClient should not send the FQDN options in the DHCP Packet for its non-Gobal Unicast addresses or temporary addresses and also client should not trigger DNS…

Since the FQDN option is sent in the "root" options space, it may not
be obvious for which IA_* the FQDN is expected to apply.

Since the client may not know what kind of address it's going to get
from the server, it's hard to ask the client not to send the option.

> If some client still sends the FQDN option in the packet, should the server do DNS update for the client ?

Probably the client may want an IA_NA but the server is only configured
to deliver IA_TA or IA_PD.

I would say it is probably enough to restrict DDNS processing to IA_NA
processing.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 13 Aug 2007 14:31:50 -0400

>I would say it is probably enough to restrict DDNS processing to IA_NA

This is true today ... Though in the future there might be other IA_*
types to which it could apply.

- Bernie

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Monday, August 13, 2007 12:20 PM
To: [email-masked]
Subject: Re: Fw: [dhcwg] DNS Registration for IATA address.

On Mon, Aug 13, 2007 at 10:06:30AM -0700, RamaSubramanian KrishnaMurthi
wrote:
> Thanks for the reply. This means the DHCPClient should not send the
FQDN options in the DHCP Packet for its non-Gobal Unicast addresses or
temporary addresses and also client should not trigger DNS the update
from the client end. am I right ?

---

From: Shane Kerr <[email-masked]>
Date: Tue, 14 Aug 2007 09:32:12 +0200

> types to which it could apply.

Actually, IA_PD seems like exactly the kind of thing you might want to process
automatically to delegate the DNS for reverse around the same time as the prefix.

I don't think this is possible with the current FQDN stuff, is it?

- --
Shane

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 14 Aug 2007 06:49:44 -0400

I think for IA_PD, there is
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsdomain-
04.txt. Though this deals with the forward zone.

- Bernie 

-----Original Message-----
From: Shane Kerr [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2007 3:32 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: Fw: [dhcwg] DNS Registration for IATA address.

> types to which it could apply.

Actually, IA_PD seems like exactly the kind of thing you might want to
process
automatically to delegate the DNS for reverse around the same time as
the prefix.

- --
Shane

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 14 Aug 2007 10:35:54 -0700

> 04.txt. Though this deals with the forward zone.

A convention based upon the forward domain name (ns1.dnsdomain-option
etc) is likely to create lame delegations (clients that don't provide
addresses for the names of servers the prefix was delegated to).

A convention similar to the way CIDR delegations are sometimes made
today in IPv4 reverse dns (individual CNAMEs into a 'forward domain'
under the customer's control) is totally unworkable in IPv6.

So the most obvious thing is to allow the client to delegate reverse
dns for a prefix to a nameserver of its choosing (possibly itself,
possibly a "friendly server" which may not be nearby).  The most
flexible way to do that would be to allow the client to supply the
NS record(s) it wants (eg the server fqdn's).

I think we can't supply glue.  We'd have to create a way to transfer
either A or AAAA records, sure, and that's easy.  The problem is;

If the client wants the prefix delegated to itself.

And If the client is also being addressed (IA_NA) via DHCPv6.

Then the client cannot predict what its address will be at the time
of Request since the server can elect to change addresses without
error (Solicit, Advertise address A, Request address A, a prefix, and
to delegate reverse dns with glue for address A, Ack with address
B...).

Using the FQDN option for this is probably problematic, because you
can never be certain that the ddns update has completed (or even will
complete at some time in the future).  To place a delegation to the
client's dynamic name by default, for example, would be another way
to invite lame delegations.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 15 Aug 2007 12:17:20 +0200

>> 04.txt. Though this deals with the forward zone.

<snip/>

> NS record(s) it wants (eg the server fqdn's).

Another possibility is to let the client (or other devices in the prefix
delegated by IA_PD) update the reverse using dynamic DNS.

The DNS server might be willing to use an IP-based ACL (meaning, "let
1:2:3:4:5:6:7:8 update the reverse for itself"), or there may be a need to
transfer a secret to the client (like a TSIG key).

- --
Shane

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 15 Aug 2007 09:26:52 -0700

> transfer a secret to the client (like a TSIG key).

Sure, letting devices update their own PTR is done on some IPv4
networks even.

With some DHCPv6 extensions, we could provide an encrypted space to
carry something like a TSIG key.

But, where the client that's getting a prefix wants to operate as its
own DHCP (or router solicitation) server, it seems to make the most
symmetry to just operate their own DNS servers.

You're basically 'running your own mini network' at that point.

Meaning, if you wanted to keep the delegation on the prefix owner's
servers, you could just as easily use the prefix owner's DHCP servers
for the delegated prefix (the client becomes a relay), and let them
take care of DNS.

Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/