> On 20 Oct 2021, at 14:14, libor.peltan <libor.pel...@nic.cz> wrote: > > Hi all, > > although for me, as an implementer of an auth server, it's not too important, > I'd like to ask for clarification regarding the foreseen reporting domain(s) > setup in the (usual) case of many secondary auth servers. > > The draft says: "Each authoritative server SHOULD be configured with a unique > reporting agent domain." > > I see two possible error situations: > > 1) the zone itself is wrongly signed, so all secondaries share the same error > 2) some of the secondaries respond wrongly from correctly signed zone, so the > error is slave-specific > > IMHO the case (2) is far less common. And the case (1) doesn't require > per-secondary reporting domain, just per-zone. > > Is it really recommended (in capitals) that the zone operator prepares extra > reporting domain for each secondary around the world (it can be hundreds)?
The domain owner may have contracts with more than one operator. The operator may operate many authoritative servers, which not all serve the same set of zones. If the reporting agent domain is unique, the erroneous server can be pinpointed faster. If all auth servers for a domain have the same reporting agent domain, the reporting agent knows there is an error, just doesn’t know where. > If so, it can cause a disclosure about which secondary the answer is comming > from, dunno if some zone operators are not willing to conceal this. In that case, the zone operator doesn’t have to deploy EDE reporting, right? Roy > > Thanks! > > Libor > > Dne 27. 04. 21 v 16:47 internet-dra...@ietf.org napsal(a): >> 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-00.txt >> Pages : 12 >> Date : 2021-04-27 >> >> Abstract: >> DNS Error Reporting is a lightweight error reporting mechanism that >> provides the operator of an authoritative server with reports on DNS >> resource records that fail to resolve or validate, that a Domain >> Owner or DNS Hosting organization can use to improve domain hosting. >> The reports are based on Extended DNS Errors [RFC8914]. >> >> 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 an agent specified by the >> authoritative server. DNS Error Reporting uses the DNS to report >> errors. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dnsop-dns-error-reporting-00 >> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-00 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
