Hi everyone

RFC6891 says this:

>   Any OPTION-CODE values not understood by a responder or requestor
>   MUST be ignored.  Specifications of such options might wish to
>   include some kind of signaled acknowledgement.  For example, an
>   option specification might say that if a responder sees and supports
>   option XYZ, it MUST include option XYZ in its response.

There is no generic way for a client to know that an option was not
handled at the server side. This is sometimes a problem when introducing
new options - while option specifications typically implement some sort
of reply signalling, it's not always the case where the client can know
with a missing option if it was not included because of lack of support,
or due to some other cause.

Is it worth introducing a reply EDNS option whose OPTION-DATA contains a
list of all the 16-bit OPTION-CODEs that were ignored from the query
message, and make it a MUST requirement?

                Mukund

Attachment: pgpJv2CEg9JC6.pgp
Description: PGP signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to