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

[Matthijs Mekking <[e-mail]>]

Hi,

On 26-10-2021 01:56, Roy Arends wrote:
> 
>> On 20 Oct 2021, at 14:14, libor.peltan <[e-mail]>
>> 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)?

If you have outsourced your secondaries to a company that has hundreds 
of secondaries I guess you can also set up a reporting agent domain like 
"company1.reporting-agent.example". and 
"company2.reporting-agent.example". It won't tell you exactly which 
server caused the problem, but at least it gives you some idea without 
having to set up hundreds of domains.

But I am also not convinced that the recommendation needs to be in capitals.


> 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?

The zone operator may still be interested in knowing about resolving 
issues. And DNS error reporting would still work if you have just a 
single reporting agent domain.


Matthijs



> Roy
> 
>> 
>> Thanks!
>> 
>> Libor
>> 
>> Dne 27. 04. 21 v 16:47 [e-mail] 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 [e-mail] https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> _______________________________________________ DNSOP mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________ DNSOP mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/dnsop
>