Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-04.txt

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-drafts@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