And, further, NXDOMAIN isn't really an "error", it's a code indicating
2. Question: How could this be optimized or at least encouraged to be fixed? Is this really an operational problem? If you think so, I think you need to explain in more detail why this is so, because it's far from obvious. As has been asked by others, doesn't proper "aggressive negative caching using DNSSEC" as per RFC 8198 take care of the "optimization"? And ... a member wanting to see these stats for address space they "own", they can just get the corresponding zones delegated and inspect this themselves... Sure, this is the current way of operations. I see some potential to inform address space owners about rev-DNS interested area that could get attention after being visible in some statistics. Those are not available yet from the RIPE NCC servers and I trying to start looking at
Hello Harvard, thanks for your comments. Please let me comment on two items: that the queried-for name doesn't exist in the DNS. Fully agreed, but we could think about if a rev-DNS request to a non-allocated RIR_Address-space could receive a slightly different response than a non-delegated zone (due to whatsoever reason). (i.e. NXDOMAIN = does not exist vs. NXDELEG = is not delegated yet) the numbers which could be included in the LIR_Portal or other prominent service summaries (i.e. the monthly mailing to the LIR about the status of the LIR).
I'm with what others have said here: the proper venue for discussing this issue is the DNS WG.
True, I have moved the topic over to the other WG. Regards, Kurt