none
DHCP server doesn't support canonical wire format in DHCP Option 81

    General discussion

  • Originally posted to "Platform Networking" forum, but then realised this one is closer.

    It looks like Windows DHCP servers, at least on Windows 2003 and 2008, do not support canonical wire format in DHCP option 81 (client FQDN).

    RFC4702, which defines option 81, offers two formats for client name - plain ASCII and canonical wire format defined in RFC1035. The format used is defined by bit "E" in Flags field of Option 81. But it looks like MS DHCP servers ignore this bit, and always treat client name as if it was in plain ASCII.

    I'm trying to configure Cisco router to register VPN clients in DNS. Router allocates IP addresses for clients from Windows 2008 DHCP server, and sends DHCP option 81 containing client host name.

    In DHCPREQUEST, router puts option 81 with bit "E"=1, and prepends client name with length byte (it sends non-qualified name, what is permitted by RFC). But eventually this length byte becomes first byte of DNS name, what is absolutely incorrect. I also analyzed DNS update packets between DHCP and DNS servers, and it is obvious that length byte becomes part of DNS name which DHCP server registers.

    Tuesday, March 20, 2012 12:34 PM

All replies

  • It looks like Windows DHCP servers, at least on Windows 2003 and 2008, do not support canonical wire format in DHCP option 81 (client FQDN).

    RFC4702, which defines option 81, offers two formats for client name - plain ASCII and canonical wire format defined in RFC1035. The format used is defined by bit "E" in Flags field of Option 81. But it looks like MS DHCP servers ignore this bit, and always treat client name as if it was in plain ASCII.

    I'm trying to configure Cisco router to register VPN clients in DNS. Router allocates IP addresses for clients from Windows 2008 DHCP server, and sends DHCP option 81 containing client host name.

    In DHCPREQUEST, router puts option 81 with bit "E"=1, and prepends client name with length byte (it sends non-qualified name, what is permitted by RFC). But eventually this length byte becomes first byte of DNS name, what is absolutely incorrect. I also analyzed DNS update packets between DHCP and DNS servers, and it is obvious that length byte becomes part of DNS name which DHCP server registers.

    • Merged by Tiger Li Wednesday, March 21, 2012 2:07 AM
    Tuesday, March 20, 2012 12:30 PM
  • I believe that is one of the bits that WIndows DHCP clients do not support.

    For dynamic registration, Windows uses the "Primary DNS Suffix" (found by looking in Computer properties, name, or an ipconfig /all), to register into a DNS zone of the same exact zone name, which has been configured to allow updates. The Primary DNS Suffix must match the AD domain name the machine is joined to.

    That's why in Windows DHCP Option 081 (which is actually the DNS tab in Windows DHCP server properties), doesn't address the wired format.

    I have a Cisco ASA setup in two of my clients with an AD infrastructure, which I will changing shortly to Windows DHCP, as I have all of my other customers configured, to take advantage of API integration supporting DHCP Credentials configuration using Kerberos to authenticate the refgistration process (Secure Only updates), Name Protect, and preventing duplicate names registered into the zone.

    Just to point out, as long as Option 006 have specified the internal DNS server IPs, which I have setup as such with my customers, and the machine's PRimary DNS Suffix matches the zone name and updates are allowed in the zone, the Windows client will register anyway.

    Optionally, you can use Option 015 to configure additional interface specific Search Suffixes fro WIndows machines, but that name is not used for registration purposes, rather just for the resolver service.

    .

    FWIW, here's more info on the process on the Windows side:

    DHCP Service Configuration, Dynamic DNS Updates, Scavenging, Static Entries, Timestamps, DnsUpdateProxy Group, DHCP Credentials, prevent duplicate DNS records, DHCP has a "pen" icon, and more...
    Published by Ace Fekay, MCT, MVP DS on Aug 20, 2009 at 10:36 AM  3758  2 
    http://msmvps.com/blogs/acefekay/archive/2009/08/20/dhcp-dynamic-dns-updates-scavenging-static-entries-amp-timestamps-and-the-dnsproxyupdate-group.aspx  

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Tuesday, March 20, 2012 7:31 PM
  • I believe that is one of the bits that WIndows DHCP clients do not support.

    Clients are all right. Bad thing is, it is not supported by Windows DHCP _servers_.

    Tuesday, March 20, 2012 8:23 PM
  • My take on it is if the client's Primary DNS Suffix matches, and it gets the DNS address, then that's all you really have to do. And more importantly, the client owns the record, so it can update it when an IP change occurs preventing duplicates, otherwise, my feeling is that you will find dupes if you configure Cisco's DHCP to register it. Besides, as far as I know, you can't configure the DHCP service with credentials to own the record that it registers into the zone using a Cisco device.


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Tuesday, March 20, 2012 8:29 PM
  • For dynamic registration, Windows uses the "Primary DNS Suffix" (found by looking in Computer properties, name, or an ipconfig /all), to register into a DNS zone of the same exact zone name, which has been configured to allow updates. The Primary DNS Suffix must match the AD domain name the machine is joined to.

    That's why in Windows DHCP Option 081 (which is actually the DNS tab in Windows DHCP server properties), doesn't address the wired format.

    "That's why" - why? You can pass the same information in Option 81 using either format. Canonical wire format doesn't prevent client from sending Primary DNS Suffix as part of it's FQDN in Option 81. If Windows clients do not use canonical wired format, that's up to them, but servers must support it simply for being RFC-compliant.
    Tuesday, March 20, 2012 8:29 PM
  • For dynamic registration, Windows uses the "Primary DNS Suffix" (found by looking in Computer properties, name, or an ipconfig /all), to register into a DNS zone of the same exact zone name, which has been configured to allow updates. The Primary DNS Suffix must match the AD domain name the machine is joined to.

    That's why in Windows DHCP Option 081 (which is actually the DNS tab in Windows DHCP server properties), doesn't address the wired format.

    "That's why" - why? You can pass the same information in Option 81 using either format.

    Sorry I wasn't clear when I posted that. I meant if you look at the Windows DHCP server properties, click on the DNS tab, all that data under the DNS tab, IS actually Option 081. If you notice, there is no mention of suffixes, wire format, etc. That was what I meant.

    .

    Canonical wire format doesn't prevent client from sending Primary DNS Suffix as part of it's FQDN in Option 81. If Windows clients do not use canonical wired format, that's up to them, but servers must support it simply for being RFC-compliant.

    And just to point out, you can send a Search Suffix to a Windows client, but you can't send a Primary DNS Suffix to a Windows client. That must either be manually configured, or programmatically configured, such as using a PS or VB script.

    And unfortunately, there may be other RFCs that Windows may not support, too, such as on the top of my head, Option 119, interface specific Search Suffixes, but *nix machines do support it. You can create the option in Windows DHCP, if required.

    But for Option 081, in Windows DHCP, that's specifically dealing with Windows Dynamic registration, which is based on RFC 2136.

    Windows Dynamic Updates, Updated: January 21, 2005
    http://technet.microsoft.com/en-us/library/cc784052(v=ws.10).aspx 

    .

    I guess we would use the appropriate tool or service for the appropriate client, depending on a company's networking needs.

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Tuesday, March 20, 2012 8:44 PM
  • My take on it is if the client's Primary DNS Suffix matches, and it gets the DNS address, then that's all you really have to do. And more importantly, the client owns the record, so it can update it when an IP change occurs preventing duplicates, otherwise, my feeling is that you will find dupes if you configure Cisco's DHCP to register it. Besides, as far as I know, you can't configure the DHCP service with credentials to own the record that it registers into the zone using a Cisco device.

    For A record, that's fine if client registers it in DNS itself instead of asking DHCP server to do that. I completely agree this is more secure process, and it is good if client owns his A record. But for PTR records, it's almost opposite. If client registers his PTR record in DNS himself, then he also owns it, and if the client doesn't remove it from DNS (say, because he lost connection), then when this IP address whill be aquired by another client, PTR record update will  either fail, or you'll get multiple PTR records for the same IP.

    I think that's why Windows DHCP clients register A records in DNS themselves but ask DHCP server to register their PTR records. And I'm trying to achieve the same for VPN clients. From VPN client viewpoint, there is no DHCP - that's VPN server (Cisco router in my case) who acts as DHCP relay and requests IP addresses for clients. So only VPN server can ask DHCP server to register client PTR record. That almost works... except the fact that Windows DHCP server doesn't understand Option 81 generated by Cisco.

    As of your last statement - for DHCP server, it doesn't matter who is it's client - Windows machine, router or whatever. If DHCP server registers DNS record for some client, it will own the record irregardless of client platform.

    Tuesday, March 20, 2012 8:47 PM
  • My take on it is if the client's Primary DNS Suffix matches, and it gets the DNS address, then that's all you really have to do. And more importantly, the client owns the record, so it can update it when an IP change occurs preventing duplicates, otherwise, my feeling is that you will find dupes if you configure Cisco's DHCP to register it. Besides, as far as I know, you can't configure the DHCP service with credentials to own the record that it registers into the zone using a Cisco device.

    For A record, that's fine if client registers it in DNS itself instead of asking DHCP server to do that. I completely agree this is more secure process, and it is good if client owns his A record. But for PTR records, it's almost opposite. If client registers his PTR record in DNS himself, then he also owns it, and if the client doesn't remove it from DNS (say, because he lost connection), then when this IP address whill be aquired by another client, PTR record update will  either fail, or you'll get multiple PTR records for the same IP.

    I think that's why Windows DHCP clients register A records in DNS themselves but ask DHCP server to register their PTR records. And I'm trying to achieve the same for VPN clients. From VPN client viewpoint, there is no DHCP - that's VPN server (Cisco router in my case) who acts as DHCP relay and requests IP addresses for clients. So only VPN server can ask DHCP server to register client PTR record. That almost works... except the fact that Windows DHCP server doesn't understand Option 81 generated by Cisco.

    As of your last statement - for DHCP server, it doesn't matter who is it's client - Windows machine, router or whatever. If DHCP server registers DNS record for some client, it will own the record irregardless of client platform.

    Well, regarding the last paragraph, actually that's not entirely accurate. That's why dupes occur. Just an FYI, here's how it works (copied and pasted from my blog):

    • By default, a Windows 2000 and newer statically configured machines will register their A record (hostname) and PTR (reverse entry) into DNS.
    • If set to DHCP, a Windows 2000 or newer machine will request DHCP to allow the machine itself to register its own A record, but DHCP will register its PTR (reverse entry) record.
    • The entity that registers the record in DNS, owns the record. 

    .

    And since a Cisco DHCP server doesn't have an "account" in AD to configure it as such, unless I'm wrong that there is a feature to do this in Cisco, then it can't "own" the record (which you can look at the DNS record, properties, Security tab). You may find it as either SYSTEM or MACHINENAME$.

    So what happens with the PTR? If the zone is set to allow Unsecure updates, then Cisco DHCP will register it. However, there is no ownership, since there is no account that can be configured for CIsco DHCP to register that record under it, tehrefore SYSTEM becomes the owner. If the IP changes, Cisco DHCP can't update it, resulting in a dupe.

    That's why with Windows DHCP, we would like to configure it with credentials using a plain-Jane Domain User account, so that record is owned by that account, and DHCP can easily update it when changes occur, in the forward or reverse zones.

    As I said, I've outlined this, and the default functionality in my blog. I'm not entirely sure if this is possible to do with a Cisco DHCP daemon. Besides, what happens if you set the zone to Secure Only (preferred)? Cisco DHCP can't update it.

    .

    As for providing DHCP to the Cisco VPN clients, you can configure an IP Helper to a Windows DHCP, that's configured to use credentials, as well as forcing updates (under the DNS tab - hence Option 081 in Windows DHCP), so it forces all updates, and the credenitals owns the record.

    This is also used in split-scope scenarios, where we have two DHCPs, and they are both configured with the same credentials, so either DHCP can update the same record.

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Tuesday, March 20, 2012 8:58 PM
  • Well, regarding the last paragraph, actually that's not entirely accurate. That's why dupes occur. Just an FYI, here's how it works (copied and pasted from my blog):
    • By default, a Windows 2000 and newer statically configured machines will register their A record (hostname) and PTR (reverse entry) into DNS.
    • If set to DHCP, a Windows 2000 or newer machine will request DHCP to allow the machine itself to register its own A record, but DHCP will register its PTR (reverse entry) record.
    • The entity that registers the record in DNS, owns the record.

    And since a Cisco DHCP server doesn't have an "account" in AD to configure it as such, unless I'm wrong that there is a feature to do this in Cisco, then it can't "own" the record (which you can look at the DNS record, properties, Security tab). You may find it as either SYSTEM or MACHINENAME$.

    Sorry, may be I was not very clear. I wasn't talking about Cisco DHCP server or daemon - do not use it, do not plan. I was talking only about Windows DHCP server serving Cisco router as client.
    Tuesday, March 20, 2012 9:45 PM
  • As for providing DHCP to the Cisco VPN clients, you can configure an IP Helper to a Windows DHCP, that's configured to use credentials, as well as forcing updates (under the DNS tab - hence Option 081 in Windows DHCP), so it forces all updates, and the credenitals owns the record.

    This is also used in split-scope scenarios, where we have two DHCPs, and they are both configured with the same credentials, so either DHCP can update the same record.

    This is almost what I'm trying to do. IP Helper address is used when router acts as real DHCP relay agent: client sends DHCP request to relay agent which, in turn, sends DHCP request to DHCP server. But it doesn't work so for VPN clients. They do not perform DHCP, instead, they get their parameters, including IP address, in IKE protocol negotiations. There is DHCP only between router and DHCP server. So it is router who must generate option 81 for the DHCP server. And it does - but Windows DHCP server can't correctly parse it.
    Tuesday, March 20, 2012 9:51 PM
  • As for providing DHCP to the Cisco VPN clients, you can configure an IP Helper to a Windows DHCP, that's configured to use credentials, as well as forcing updates (under the DNS tab - hence Option 081 in Windows DHCP), so it forces all updates, and the credenitals owns the record.

    This is also used in split-scope scenarios, where we have two DHCPs, and they are both configured with the same credentials, so either DHCP can update the same record.

    This is almost what I'm trying to do. IP Helper address is used when router acts as real DHCP relay agent: client sends DHCP request to relay agent which, in turn, sends DHCP request to DHCP server. But it doesn't work so for VPN clients. They do not perform DHCP, instead, they get their parameters, including IP address, in IKE protocol negotiations. There is DHCP only between router and DHCP server. So it is router who must generate option 81 for the DHCP server. And it does - but Windows DHCP server can't correctly parse it.

    I see. So the IP Helper is not properly working? At least that's the way I'm translating it. As long as the IP subnet for the lease on the Windows DHCP matches the IP subnet for the VPN clients that you've configured in the device, it should provide an IP and the Options you've configured on the Windows DHCP side. If not, then something else is going on.

    And in this scenario, there's no need to configure anything on the Cisco side, other than the IP Helper. Windows DHCP will be handling the Options. I have it setup this way at one client. Everything's coming from the Windows DHCP. The ASA is literally just passing the IP and options from the DHCP server to the VPN client through the helper. Nothing else was configured on the ASA regarding this setup (no Option 081, etc).

    And note, I have DHCP to *force* register all clients (look at the screenshots for the settings), whether they can ask or not, into DNS, with credentials. Scavenging was configured as well.

    And if the VPN clients are not configured with a Primary DNS Suffix, they will show up in the lease with a single name.

    .

    If you're finding that the IP Helper is not working, albeit disregarding the Option 081 wire format (which IMHO is not needed), I would recommend contacting Cisco support for assistance.

    Ace


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Tuesday, March 20, 2012 10:15 PM
  • I see. So the IP Helper is not properly working? At least that's the way I'm translating it. As long as the IP subnet for the lease on the Windows DHCP matches the IP subnet for the VPN clients that you've configured in the device, it should provide an IP and the Options you've configured on the Windows DHCP side. If not, then something else is going on.

    And in this scenario, there's no need to configure anything on the Cisco side, other than the IP Helper. Windows DHCP will be handling the Options. I have it setup this way at one client. Everything's coming from the Windows DHCP. The ASA is literally just passing the IP and options from the DHCP server to the VPN client through the helper. Nothing else was configured on the ASA regarding this setup (no Option 081, etc).

    Speaking honestly, I completely misunderstand how you are doing that. How VPN client can use DHCP at all? I always thought DHCP is for networks with broadcasts - Ethernet segments, wireless 802.11 networks, etc. VPN clients which use IPsec get their IP addresses and other configuration assigned in IKE protocol negotiations. VPN clients which use some forms of PPP encapsulation like L2TP or PPTP are configured via IPCP PPP subprotocol. There is no place for DHCP on client side. So not that "IP Helper is not working" - I didn't even try it, as I do not see how it can work in the first place.

    If you say your VPN clients perform DHCP requests themselves, then I'm curious what software you are using for VPN client? At present, I'm using Cisco VPN Clinet which utilizes IPsec and IKE. Just made an experiment: explicitly switched VPN Client virtual network adapter on my notebook to use DHCP and established VPN connection. After the connection is made, I could see that settings are switched back to static, and "ipconfig /all" shows that DHCP is off on that interface. Just like expected.

    And note, I have DHCP to *force* register all clients (look at the screenshots for the settings)
    Sorry, where?
    Wednesday, March 21, 2012 8:56 AM
  • After writing last message, I've realised I don't know how SSL VPN clients aquire their IP addresses. May be they use DHCP?
    Wednesday, March 21, 2012 1:42 PM
  • Speaking honestly, I completely misunderstand how you are doing that. How VPN client can use DHCP at all? I always thought DHCP is for networks with broadcasts - Ethernet segments, wireless 802.11 networks, etc. VPN clients which use IPsec get their IP addresses and other configuration assigned in IKE protocol negotiations. VPN clients which use some forms of PPP encapsulation like L2TP or PPTP are configured via IPCP PPP subprotocol. There is no place for DHCP on client side. So not that "IP Helper is not working" - I didn't even try it, as I do not see how it can work in the first place.

    If you say your VPN clients perform DHCP requests themselves, then I'm curious what software you are using for VPN client? At present, I'm using Cisco VPN Clinet which utilizes IPsec and IKE. Just made an experiment: explicitly switched VPN Client virtual network adapter on my notebook to use DHCP and established VPN connection. After the connection is made, I could see that settings are switched back to static, and "ipconfig /all" shows that DHCP is off on that interface. Just like expected.

    No special software. Just an IP Helper on the ASA pointing to the Windows DHCP server. I actually had Cisco assist me with this.

    If you have a Cisco Gold 24/7, I suggest giving them a shout.

    .

    And note, I have DHCP to *force* register all clients (look at the screenshots for the settings)

    Sorry, where?

    In my blog. No problem if you didn't read it.

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBookTwitterLinkedIn


    Wednesday, March 21, 2012 3:06 PM
  • After writing last message, I've realised I don't know how SSL VPN clients aquire their IP addresses. May be they use DHCP?

    They need to get an IP from somewhere.

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Wednesday, March 21, 2012 3:07 PM
  • No special software. Just an IP Helper on the ASA pointing to the Windows DHCP server. I actually had Cisco assist me with this.
    Sorry, but what do you mean by "No special software"? Every VPN client has to run some kind of software. It can be Windows standard PPTP or L2TP/IPsec connection, Cisco software like Cisco VPN Client or AnyConnect, Nortel client, there are many others.
    Friday, March 23, 2012 8:25 AM
  • Sorry, but what do you mean by "No special software"? Every VPN client has to run some kind of software. It can be Windows standard PPTP or L2TP/IPsec connection, Cisco software like Cisco VPN Client or AnyConnect, Nortel client, there are many others.

    I meant on the Cisco to DHCP side - just using the built-tools and features. For the clients, they were using either the Legacy Client or SSLVPN Any Connect. Nothing else. The client software has nothing to do with getting an IP for the client. It's all done on the ASA side, as long as the IP Helper is configured to use the Windows DHCP server, and you've correctly conigured the Lease Scope and Options on the Windows DHCP server. That's pretty much it.

    .

    As I suggested, I honestly recommend you call Cisco Support to assist you in getting this configured for you. They'll be able to help on the ASA side, as well as the Windows side, if required.

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Friday, March 23, 2012 2:46 PM
  • In DHCPREQUEST, router puts option 81 with bit "E"=1, and prepends client name with length byte (it sends non-qualified name, what is permitted by RFC). But eventually this length byte becomes first byte of DNS name, what is absolutely incorrect. I also analyzed DNS update packets between DHCP and DNS servers, and it is obvious that length byte becomes part of DNS name which DHCP server registers.

    It´s a problem with Microsoft DHCP, as you wrote. We have same Problems with some HP Officejet: DNS Hostname is registered with first byte of lengh. So the dns name is unusable...

    Microsoft don´t change their dhcp to RFC conform... badly...

    Wednesday, August 07, 2013 5:32 AM