This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] missing data
- Previous message (by thread): [db-wg] missing data
- Next message (by thread): [db-wg] missing data
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ronald F. Guilmette
rfg at tristatelogic.com
Thu Nov 5 15:33:44 CET 2020
In message <afed0e34-a686-5d1d-6e8c-ea6e95adf0fc at ripe.net>, Anand Buddhdev <anandb at ripe.net> wrote: >On 05/11/2020 14:12, Ronald F. Guilmette via db-wg wrote: >> Can someone (anyone) please explain to me why the following file does not >> exist? >> >> ftp://ftp.ripe.net/pub/zones/185.in-addr.arpa-RIPE >> >> Who is responsible for generating the files in this directory? What is the >> process by which they are generated? What went wrong and who is going to >> fix it? > >The files in https://ftp.ripe.net/pub/zones/ are generated by the RIPE >NCC's reverse DNS provisioning system. The files published there are >"zonelet" files. They are meant to contain reverse DNS delegation >information for address space registered in the RIPE Database, but whose >parent zone operator is another RIR. For example, 192.in-addr.arpa is >operated by ARIN, but there are various address ranges in 192/8 >registered in the RIPE Database. So we publish the DNS information in >the "192.in-addr.arpa-RIPE" file. ARIN fetches this file periodically to >import the data in it into 192.in-addr.arpa. > >In contrast, 185/8 has been assigned to RIPE NCC by the IANA. So RIPE >NCC operates 185.in-addr.arpa. We have no reason to publish a zone file >for it on our FTP/HTTPS server. I submit to you that it would be more convenient and more consistant if you did do so anyway. >You can query this zone's name servers >directly if you want to see delegation information. >... >dig 185.in-addr.arpa axfr @pri.authdns.ripe.net > 185.in-addr.arpa.zone So let me see if understand this... In order for me to fetch a full set of -all- RIPE-generated reverse DNS delegation information, I must use some combination of dig/axfr -and- also and separately, FTP to fetch your "zonelets", yes? Do I need to explain why this is more complicated and entirely less convenient to script than just doing one or the other? Sigh. So I guess I now have to work out for myself, by a process of deduction, which /8 blocks are -not- represented by zonelet files on your FTP server so that I can then know which ones I have to do dig/axfr on. (I wonder eternally why life has to be so complicated. Today is no different.)
- Previous message (by thread): [db-wg] missing data
- Next message (by thread): [db-wg] missing data
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]