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

["Windl, Ulrich" <[e-mail]>]

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]