[ncc-services-wg] Proposal: optimized rev-DNS operations

Hello Harvard,

thanks for your comments.

Please let me comment on two items:

> And, further, NXDOMAIN isn't really an "error", it's a code indicating
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)

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4052 bytes
Desc: S/MIME Cryptographic Signature
URL: </ripe/mail/archives/ncc-services-wg/attachments/20191028/65cdfe7e/attachment.p7s>