[dhcwg] RE: Client FQDN

["Bernie Volz" <[e-mail]>]

Why?

The DHCP server will return the fully qualified domain name for each address
to the client (if appropriate). With this and if you know the how to reach a
DNS server, you can find out where the zone cut is. Ask for NS RRs with the
fully qualified domain name; if that doesn't return any, remove the first
component (ie, for a.b.test.com, remove a) and try the resulting domain ...
Keep going until you find the NS records or you run out of domain names. If
you find NS records, try the updates to the one or more servers.

Nothing more needed.

Now, agreed, that if the DHCP server doesn't return the Client FQDN option
for a address, then the DHCP client will need something for it to use. And,
lacking anything else, using the DNS search list probably isn't that bad an
idea.

- Bernie

> -----Original Message-----
> From: CTO YAN Renxiang [mailto:[e-mail]] 
> Sent: Tuesday, July 13, 2004 11:01 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: 
> 
> 
> Hi, Bernie,
> 
> I don't think domain name search list option defined in 
> RFC3646 can transfer the DNS zone suffix which is used by 
> host to update the FQDN without any modification.
> 
> In section4 of RFC3646, it states:
> "The Domain Search List option specifies the domain search 
> list the client is to use when resolving hostnames with DNS."
> 
> The initial purpose of domain search list option is hostname 
> resolving, not domain name update. Furthermore, the domain 
> name listed in the Domain Search List option can be different 
> from the DNS zone suffix the client needed to update its domain name.
> 
> Even if Domain Search List option can be used in domain name 
> update, we have to define a mechanism to choose a correct 
> domain name from domain search list.
> 
> To sum up, two choices exist to make it possible for IPv6 
> client to dynamically update its domain name: 1. define 
> another option to transfer DNS zone suffix to client, which 
> enables the client generates its FQDN, as defined in 
> http://www.ietf.org/internet-drafts/draft-yan-dhc-dhcpv6-opt-d
> nszone-00.txt.
> 2. define a mechanism to choose a domain name as DNS zone 
> suffix from domain search list, and use it to generate and 
> update client's FQDN
> 
> -Renxiang
> 
> P.S. In order to foster a discussion on this topic, I am 
> CCing  this mail to DHC list, I would be appreciated any 
> value comments from experts in the list.
> 
> 
> -----原始邮件-----
> 发件人: Bernie Volz [mailto:[e-mail]]
> 发送时间: 2004年7月13日 10:38
> 收件人: CTO YAN Renxiang
> 主题: RE: about your draft
> 
> 
> The Client FQDN option sends the fully qualified domain name. 
> There is no indication of which is the host portion and which 
> is the domain name. In general, this really isn't that useful.
> 
> In DHCPv6, we already have the domain name search list option 
> (see http://www.ietf.org/rfc/rfc3646.txt). This is generally 
> much more useful than just the "domain name" and, in DHCPv4 
> it is generally the domain name that is used as the default 
> domain search list.
> 
> So, if a client receives the Client FQDN option with a fully 
> qualified domain name, it can figure out the host name 
> portion by using the domain search list, if it really cares. 
> Or, it can do DNS lookups.
> 
> - Bernie
> 
> > -----Original Message-----
> > From: CTO YAN Renxiang [mailto:[e-mail]]
> > Sent: Monday, July 12, 2004 8:38 PM
> > To: Bernie Volz
> > Subject: re: about your draft
> >
> >
> > Hi, Bernie,
> >
> > In DHCPv4, the domain name is tranferred using option 15 
> (domain name) 
> > defined in 2132. However, DHCPv6 does not defined such an 
> option. How 
> > does your draft implement? could you explain in a bit detail?
> >
> > regards,
> > -renxiang
> >
> > -----原始邮件-----
> > 发件人: Bernie Volz [mailto:[e-mail]]
> > 发送时间: 2004年7月12日 21:28
> > 收件人: CTO YAN Renxiang
> > 主题: RE: about your draft
> >
> >
> > Hi:
> >
> > The draft should appear at the IETF web site shortly. Sometimes the 
> > announcement preceeds the upload to the web/ftp site(s), so 
> give it a 
> > day or two and it should appear.
> >
> > The option is modeled after the DHCPv4 Client FQDN option.
> >
> > - Bernie
> >
> > > -----Original Message-----
> > > From: CTO YAN Renxiang [mailto:[e-mail]]
> > > Sent: Sunday, July 11, 2004 11:35 PM
> > > To: [e-mail]
> > > Subject: about your draft
> > >
> > >
> > > Hi Bernie,
> > >
> > > I found you will make presentation on 60th IETF meeting about the 
> > > DHCP FQDN option. I can't find the draft "The DHCPv6 Client FQDN 
> > > Option" on website. Could you send me the link?
> > >
> > > I wrote a draft  "DNS zone suffix option for DHCPv6" to 
> allow DHCPv6 
> > > server transfer the DNS zone suffix to DHCPv6 client. I 
> wonder there 
> > > will be close relationship between our drafts, so could 
> you tell me 
> > > how to tranfer the DNS suffix in your draft?
> > >
> > > Thank you!
> > >
> > > regards,
> > > -Renxiang
> > >
> > cn
> 


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