> > > B) Variant B: > - My domain "petrs.example" hosts a really nasty political satire, and > it gets censored a lot > - I don't care about reports of EDE "Censored" because there is nothing > I can do about them anyway > - I still _do_ care about technical issues. > > To make use of the same technique as in the previous example (wildcard), > we would have to switch order of elements in the reporting query to: > > _er.<qname>.<ede code>._er.<reporting agent domain> > > This structure allows to use the same trick on per-EDE code basis: > > $ORIGIN _er.agent.test. > * TXT "tell me!" > 16 TXT "silence" ; 16 = EDE Censored > > > I was actually wondering how this family of code (specifically 15, 16, and 17) would be handled given that they are "local" policies more than actual errors in regard to the authoritative name server. But as an extension, how a resolver would keep tab on what should or should not be reported. This is likely an effective way for auth operators to silence what they do not care about
The question is: Which variant is better? > > I don't remember from our previous discussions if the current ordering > in draft was a conscious choice or not, sorry if I forgot. > On a first read I thought this was trading effectively stubbing out EDE code but losing QNAME level solution, but assuming that non-terminal wildcard are widely supported (RFC4592 section 2.1.3. [0]), it seems that we could benefit from both world by silencing domain specific with: ``` $ORIGIN _er.agent.test. * TXT "tell me!" dnssec-failed.petrs.example.* TXT "silence this specific domain" 16 TXT "silence this specific code" ; 16 = EDE Censored ``` There is still the QTYPE to fit somewhere, but it seems the same logic could apply? Enjoy the weekend! Manu [0] https://datatracker.ietf.org/doc/html/rfc4592#section-2.1.3 > > Have a great weekend everyone! > > -- > Petr Špaček >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
