Hi all,

Maybe I missed some earlier discussions or decisions, then just ignore my comment.


I was thinking if more meta data in the report query. If only one of the authoritative servers for the domain test. is out of sync it may help with some extra data to pinpoint the faulty server.

In unicast the IP address of the faulty authoritative server may help. With an anycast setup maybe NSID is better but then the resolver has to include "+NSID" in all queries to auth servers.

RFC8914 also has error codes for network error related problems. Would it be helpful to be able to signal what protocol that was used, like UDP53, TCP53, DOT, DOH, DOQ, etc? I understand that this type of error reporting may generate a lot of "false negatives" if the protocols are not supported by the auth servers. But on the other hand it may signal some unknown filtering in the path.


Some possible examples:

_ip4.192.168.47.11._ip4

_ip6.2001-DB8-F00=53._ip6
(in this example : eq - and :: eq =, maybe not the best)

_nsid.server.iata._nsid

_proto.doh._proto


Regards,
// mem



Den 2023-02-03 kl. 18:34, skrev internet-dra...@ietf.org:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

         Title           : DNS Error Reporting
         Authors         : Roy Arends
                           Matt Larson
   Filename        : draft-ietf-dnsop-dns-error-reporting-04.txt
   Pages           : 10
   Date            : 2023-02-03

Abstract:
    DNS error reporting is a lightweight reporting mechanism that
    provides the operator of an authoritative server with reports on DNS
    resource records that fail to resolve or validate.  A domain owner or
    DNS hosting organization can use these reports to improve domain
    hosting.  The reports are based on extended DNS errors as described
    in RFC 8914.

    When a domain name fails to resolve or validate due to a
    misconfiguration or an attack, the operator of the authoritative
    server may be unaware of this.  To mitigate this lack of feedback,
    this document describes a method for a validating recursive resolver
    to automatically signal an error to a monitoring agent specified by
    the authoritative server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-04

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-dns-error-reporting-04


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

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

Reply via email to