The authors took a stab at text explaining mitigations which seem to have not
met the WG's needs.
Removing HTTP would allow the document to move forward. If someone finds a
suitable way to weaken (or even prevent) malicious use of http in the Contact
field by the DoH/DoT operator (with an
Thanks! I think this is an improvement. Ideally this would use an existing
schema language instead of inventing a new one, but your approach here seems
reasonable.
I think the draft should probably add Mnemonic and Data Type columns to the
EDNS OPT registry, to make sure that future opcodes
Hi Ben, DNSOP,
thank you so much for your reading and comments. We considered both of
your suggestions useful, and substantially updated the document to
reflect them:
- for each EDNS option, abstract name, type and value are defined, and
both presentation and JSON formats are derived from
This draft originally proposed returning a webpage. After reviews from the
working group raising concern about allowing the DNS server to inject a
webpage, it was changed to provide a contact URI instead ... but it then lists
"https:" as an example of a suitable contact URI scheme. This
Reviewer: Yaron Sheffer
Review result: Ready
My comments from the previous review have been fully addressed. Thank you!
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
I would like to clarify that the purpose of the "c" (contact) field is not
to display an error page but to provide contact details of the IT/InfoSec
team for reporting misclassified DNS filtering. Its function is to report
legitimate domain names that have been incorrectly blocked due to
