[Ntp] Re: [EXT] [EXT] Re: Server identifier ID Extension Field

[Danny Mayer <[e-mail]>]

I'm not providing anything except a unique ID so system information is 
the wrong term. Better terms are welcome.

Danny

On 7/21/26 4:19 AM, Windl, Ulrich wrote:
> Hi!
>
> Please don't name it "server ID": An ID has no semantic other than being unique and permanent.
> What you are talking about is "system information". That's a different thing.
>
> Kind regards,
> Ulrich Windl
>
>> -----Original Message-----
>> From: Giovane C. M. Moura <giovane.moura=[e-mail]>
>> Sent: Thursday, July 16, 2026 11:15 AM
>> To: Miroslav Lichvar <mlichvar=[e-mail]>; [e-mail]
>> Subject: [EXT] [EXT] [Ntp] Re: Server identifier ID Extension Field
>>
>> Sicherheits-Hinweis: Diese E-Mail wurde von einer Person außerhalb des UKR
>> gesendet. Seien Sie vorsichtig vor gefälschten Absendern, wenn Sie auf Links
>> klicken, Anhänge öffnen oder weitere Aktionen ausführen, bevor Sie die
>> Echtheit überprüft haben.
>>
>>
>>> The server ID proposed in this thread is not for loop detection. It's
>>> supposed to be a text string set by the admin, an optional feature.
>> See section 3.1 in RFC5001.
>>
>> 3.1.  The NSID Payload
>>
>>      The syntax and semantics of the content of the NSID option are
>>      deliberately left outside the scope of this specification.
>>
>>      Choosing the NSID content is a prerogative of the server
>>      administrator.  The server administrator might choose to encode the
>>      NSID content in such a way that the server operator (or clients
>>      authorized by the server operator) can decode the NSID content to
>>      obtain more information than other clients can.  Alternatively, the
>>      server operator might choose unencoded NSID content that is equally
>>      meaningful to any client.
>>
>>      This section describes some of the kinds of data that server
>>      administrators might choose to provide as the content of the NSID
>>      option, and explains the reasoning behind specifying a simple opaque
>>      byte string in Section 2.3.
>>
>>
>>
>> Austein                     Standards Track                     [Page 4]
>> RFC 5001                        DNS NSID                     August 2007
>>
>>
>>      There are several possibilities for the payload of the NSID option:
>>
>>      o  It could be the "real" name of the specific name server within the
>>         name server pool.
>>
>>      o  It could be the "real" IP address (IPv4 or IPv6) of the name
>>         server within the name server pool.
>>
>>      o  It could be some sort of pseudo-random number generated in a
>>         predictable fashion somehow using the server's IP address or name
>>         as a seed value.
>>
>>      o  It could be some sort of probabilistically unique identifier
>>         initially derived from some sort of random number generator then
>>         preserved across reboots of the name server.
>>
>>      o  It could be some sort of dynamically generated identifier so that
>>         only the name server operator could tell whether or not any two
>>         queries had been answered by the same server.
>>
>>      o  It could be a blob of signed data, with a corresponding key which
>>         might (or might not) be available via DNS lookups.
>>
>>      o  It could be a blob of encrypted data, the key for which could be
>>         restricted to parties with a need to know (in the opinion of the
>>         server operator).
>>
>>      o  It could be an arbitrary string of octets chosen at the discretion
>>         of the name server operator.
>>
>>      Each of these options has advantages and disadvantages:
>>
>>      o  Using the "real" name is simple, but the name server may not have
>>         a "real" name.
>>
>>      o  Using the "real" address is also simple, and the name server
>>         almost certainly does have at least one non-anycast IP address for
>>         maintenance operations, but the operator of the name server may
>>         not be willing to divulge its non-anycast address.
>>
>>      o  Given that one common reason for using anycast DNS techniques is
>>         an attempt to harden a critical name server against denial of
>>         service attacks, some name server operators are likely to want an
>>         identifier other than the "real" name or "real" address of the
>>         name server instance.
>>
>>      o  Using a hash or pseudo-random number can provide a fixed length
>>         value that the resolver can use to tell two name servers apart
>>
>>
>>
>> Austein                     Standards Track                     [Page 5]
>> RFC 5001                        DNS NSID                     August 2007
>>
>>
>>         without necessarily being able to tell where either one of them
>>         "really" is, but makes debugging more difficult if one happens to
>>         be in a friendly open environment.  Furthermore, hashing might not
>>         add much value, since a hash based on an IPv4 address still only
>>         involves a 32-bit search space, and DNS names used for servers
>>         that operators might have to debug at 4am tend not to be very
>>         random.
>>
>>      o  Probabilistically unique identifiers have properties similar to
>>         hashed identifiers, but (given a sufficiently good random number
>>         generator) are immune to the search space issues.  However, the
>>         strength of this approach is also its weakness: there is no
>>         algorithmic transformation by which even the server operator can
>>         associate name server instances with identifiers while debugging,
>>         which might be annoying.  This approach also requires the name
>>         server instance to preserve the probabilistically unique
>>         identifier across reboots, but this does not appear to be a
>>         serious restriction, since authoritative nameservers almost always
>>         have some form of non-volatile storage.  In the rare case of a
>>         name server that does not have any way to store such an
>>         identifier, nothing terrible will happen if the name server
>>         generates a new identifier every time it reboots.
>>
>>      o  Using an arbitrary octet string gives name server operators yet
>>         another setting to configure, or mis-configure, or forget to
>>         configure.  Having all the nodes in an anycast name server
>>         constellation identify themselves as "My Name Server" would not be
>>         particularly useful.
>>
>>      o  A signed blob is not particularly useful as an NSID payload unless
>>         the signed data is dynamic and includes some kind of replay
>>         protection, such as a timestamp or some kind of data identifying
>>         the requestor.  Signed blobs that meet these criteria could
>>         conceivably be useful in some situations but would require
>>         detailed security analysis beyond the scope of this document.
>>
>>      o  A static encrypted blob would not be particularly useful, as it
>>         would be subject to replay attacks and would, in effect, just be a
>>         random number to any party that does not possess the decryption
>>         key.  Dynamic encrypted blobs could conceivably be useful in some
>>         situations but, as with signed blobs, dynamic encrypted blobs
>>         would require detailed security analysis beyond the scope of this
>>         document.
>>
>>
>>
>> /giovane
>>
>> _______________________________________________
>> ntp mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> _______________________________________________
> ntp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]