odd 34 char(hex) in TXT records for DHCP IPs

I am seeing so many odd 34 character hex strings in TXT records for DHCP IPs
  assuming via DDNS aspect, and possibly just the newer Windows 11

This is for DNS-DHCP for OES 24.4

is anyone else seeing this?

I've tried looking for proof of it what they are for, but so far blank.

Given we are aiming to make some changes soon on our setup, knowing what will happen with IP reassignments and/or deletion of those TXT records would be a good thing up front.
   Also, would we need to add them for the Static IP Windows systems if it is a new Windows 11 thing?

________________________

Andy of KonecnyConsulting.ca in Toronto
Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0  

    DHCID RRDATA. See here...

    https://datatracker.ietf.org/doc/html/draft-ietf-dhc-dhcp-dns-12#section-4.3.1

    It's handled that way by DDNS since IIRC OES11 and is expected to appear even with phones.

  • 0   in reply to   

    That sounds about right, and I guess it just wasn't active for Windows clients until newer versions. I think Win7 era was the last time I really looked at DHCP traffic.  Clearly time for some more packet captures to see this in action.

    Looking at the zone export, I see it is the Droids as well as Veeam restores for files from OES getting those TXT records, all with 1 hour TTL as well as their A records matching that TTL, whereas the statics are 1 day, as well as a bunch of work station A records that I'm sure are ancient with the 1-day having been via DHCP in the past.    Very much some investigation now to happen.

    Pity it doesn't have an RFC # to make it easier to track and refer to.  But very much welcome this pointer, thank you

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0   in reply to   

    It's a server-side function and generally nice from the security aspect. Issues arise e.g. for clients / devices roaming between wired and wireless, for those with broken NICs which had to be replaced. And migrating from a non-ISC to and ISC system requires special care.

  • 0   in reply to   
    And migrating from a non-ISC to and ISC system requires special care.

    So a zone originally created on NetWare (or early OES), still being actively used, now needs an ugly clean-up, because there was never any reference of a need for managing this change that I wasn't aware of until now.   I clearly have one of these to now deal with, and have already cleared out some of the entries.

    An advantage found is that the old entries appear to have a different TTL than the new ones, but that could be due to our choosing the longer timeouts for regular A records a couple of decades ago.

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0   in reply to   

    Yes, that's my experience. DDNS would not update an existing record (created under let's say NetWare) without the hash.

  • 0   in reply to   

    I wonder if it has anything to do with not having ISC method of 'standard' available. none, ancient, and interim ,are the only ddns-update-style available.  Found it was off on one server, at least up to interim now (no DNS for IPs from the pool it services.)

    I am seeing evidence of even the new systems not updating IPs as they change (two locations, with some user bounce between them)

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0   in reply to   

    For DDNS to work in OES Linux it always had to be set to "interim". The code as such should support "standard" since OES2018 (4.3.x.x), but the option didn't even make it to the console (wonder what would happen if one would manually tweak the "dhcpStatements" attribute of the dhcp_server object).

    If you see txt records with MD5 hashes it's definitely "interim", "standard" would generate dhcid records with SHA2 values.

  • 0   in reply to   

    Clearly more like MD4 hashes, with a bonus pair of characters,  not better than that.

    Tweaking that is so tempting, but must resist doing so in production, so additional pressure for resurrecting/rebuilding the lab (animals?)

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.