Hi Tirumal
On Thu, Mar 19, 2026 at 10:26:59AM +0530, tirumal reddy wrote:
> Unlike a webpage served over HTTPS which has transport security and server
> authentication, a DNS response carrying arbitrary free-form text does not
> have the same guarantees, making structured and validated content
> essential. For instance, a free-form EXTRA-TEXT string containing URLs or
> contact information can be manipulated by an on-path attacker to redirect
> end-users to malicious sites, which is precisely the attack the draft
> addresses.
On-path attackers may modify the JSON too unless transport security is
used. I am aware this draft requires transport security, but the
alternative can also be as simple as requiring transport security if a
browser wished to display RFC 8914 extra-text to a user.
> Another example could be, RFC8914 EXTRA-TEXT has no language tag,
> determining the language of a short string is challenging, making
> translation or locale-appropriate handling unreliable; this draft solves
> this by tagging the error response with the language, enabling clients to
> handle it appropriately.
>
> WGLC is intended to identify technical issues with the current
> specification, not re-open the question of whether the work should exist,
> the WG already reached consensus on that at adoption.
>
> This draft has a history of several years where the need for it was
> discussed and agreed upon at adoption, and it has continuously evolved to
> address various issues including, threats and deployability. If you are
> still not convinced of the need for this draft, I suggest reviewing the
> history of this draft and the extensive discussions on the mailing list.
By this, you're saying it's not necessary to discuss the basis for this
draft anymore or ask to have it explained clearly in the introduction.
It's not my intention to derail your work. I was one of the early
reviewers of this draft and I pointed out some of these concerns early
on. My previous emails dated 2023-06-27 and 2025-10-31 on the topic of
the sub-error registry did not get responses.
If what this offers over RFC 8914 is a contact field and a requirement
of transport security, a 8914 bis section requiring transport security
for browsers, and an EDNS option just for contact information that
complemented RFC 8914 would have been simpler.
My conclusion in the email dated 2023-06-27 is similar to the email I
wrote yesterday.
You could improve this work by describing in the introduction what the
benefits of this draft are over RFC 8914, i.e., what is it that can be
done with this draft that cannot be done with RFC 8914. For example Lars
mentioned in a different email in this thread that the information is
shown in a separate security context where EXTRA-TEXT cannot be
used. You mention earlier in your email that this contact information
cannot be manipulated (due to transport security). Mention that this
draft exists for these reasons in the introduction.
Mukund
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
