[ncc-services-wg] Proposal: optimized rev-DNS operations
- Previous message (by thread): [ncc-services-wg] Proposal: optimized rev-DNS operations
- Next message (by thread): [ncc-services-wg] Proposal: optimized rev-DNS operations
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Kurt Kayser
kurt_kayser at gmx.de
Sun Oct 27 12:34:39 CET 2019
Hello Nick, It's not about "chasing down" from RIPE NCC towards their members. It's rather: how should the resources holders KNOW about rev-DNS requests targeted for their space? It would require FIRST a delegation and THEN see those requests coming in. But for - say internally used adresses - one might not want to delegate all address space. My hope with this proposal was to provide a service in order to (optionally) signal interested members what specific areas of rev-DNS areas there are, in order to know which reverse-delegation should make sense and considered for rev-delegation. Therefore I decided to get statistics first from the RIPE NCC DNS-Servers, but I am not fully aware how and where I could start this investigation. Hence I halt the proposal in the meantime, until I have solid figures and base it not just on assumptions. .kurt Am 25.10.19 um 15:21 schrieb Nick Hilliard (Network Ability Ltd): > Kurt Kayser wrote on 25/10/2019 13:39: >> Since the IPv6-blocks are quite large, one member might be interested >> towards areas that have active reverse requests coming in (but those are >> only visible up to the RIPE NCC servers, if they are not delegated for >> *all* IPv6 address space, which I doubt will ever happen. >> >> If they would have a means to know those top-areas they could >> (optionally) start analyzing and a delegation process and deliver >> answers for such addresses. > > but is it really the RIPE NCC's business to chase this down for > resource holders? If the resource holder wants to know, they can get > the dns delegated and investigate this themselves. If they don't want > to know, that's kinda their business. > > Nick -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4052 bytes Desc: S/MIME Cryptographic Signature URL: <https://lists.ripe.net/ripe/mail/archives/ncc-services-wg/attachments/20191027/b2267df7/attachment.p7s>
- Previous message (by thread): [ncc-services-wg] Proposal: optimized rev-DNS operations
- Next message (by thread): [ncc-services-wg] Proposal: optimized rev-DNS operations
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]