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? And more to the point, where may I find the real, actual, and complete set of zone files? Are they hidden away behind some curtain, or in some secret room? Who do I have to know in order to be invited to view the real zonefiles that are actually being used for delegation?
On 05/11/2020 14:12, Ronald F. Guilmette via db-wg wrote: Hi Ronald,
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. You can query this zone's name servers directly if you want to see delegation information. There is nothing wrong, and nothing to fix.
And more to the point, where may I find the real, actual, and complete set of zone files? Are they hidden away behind some curtain, or in some secret room? Who do I have to know in order to be invited to view the real zonefiles that are actually being used for delegation?
dig 185.in-addr.arpa axfr @pri.authdns.ripe.net > 185.in-addr.arpa.zone Regards, Anand Buddhdev RIPE NCC
In message <afed0e34-a686-5d1d-6e8c-ea6e95adf0fc@ripe.net>, Anand Buddhdev <anandb@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.)
Ronald F. Guilmette via db-wg wrote on 05/11/2020 13:12:
And more to the point, where may I find the real, actual, and complete set of zone files? Are they hidden away behind some curtain, or in some secret room? Who do I have to know in order to be invited to view the real zonefiles that are actually being used for delegation?
There are a couple of ways of going about this. 1. join secret society, learn special handshakes, involve oneself in mysterious + private rituals, attend shady meetings in smoke-filled rooms with nefarious intent, climb invisible ladder of privilege, fly private jet around the world to attend invite-only meetings with kings and presidents, then finally after many years be granted access to what lies behind the curtain. 2. zone axfr from pri.authdns.ripe.net, as Anand suggests. 3. download + parse DB data from: ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.domain.gz I would advise option #1. The canapes and cigars are first class. Nick
1. join secret society, learn special handshakes, involve oneself in mysterious + private rituals, attend shady meetings in smoke-filled rooms with nefarious intent, climb invisible ladder of privilege, fly private jet around the world to attend invite-only meetings with kings and presidents, then finally after many years be granted access to what lies behind the curtain.
this is patently false. the rooms are no longer smoke filled. but this channel may be heading that way. randy
In message <d2e3be50-89d7-c152-f1a9-cf98eb5aaaa1@foobar.org>, Nick Hilliard <nick@foobar.org> wrote:
3. download + parse DB data from:
ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.domain.gz
Already been there and done that. Now I'd like to check to make sure that there is 100% consistancy between what is in WHOIS and what is in the zone files. This may perhaps not be entirely wasted effort. I have some basis to believe that for at least one RIR, the WHOIS and the zone files are *not* 100% consistant with one another. Regards, rfg P.S. I also don't think that it would have killed anyone if someone had just had the minimal courtesy to put a README file in the /pub/zones/ directory, explaining what Anand Buddhdev just explained about why some data is present there, while a whole lot of other data that one would naturally expect to see there is just mysteriously absent. No, none of this is either obvious or intutive.
On Thu, Nov 05, 2020 at 06:41:17AM -0800, Ronald F. Guilmette via db-wg wrote:
P.S. I also don't think that it would have killed anyone if someone had just had the minimal courtesy to put a README file in the /pub/zones/ directory, explaining what Anand Buddhdev just explained about why some data is present there, while a whole lot of other data that one would naturally expect to see there is just mysteriously absent.
$ lftp lftp :~> o ftp://ftp.ripe.net/ cd ok, cwd=/ lftp ftp.ripe.net:/> cd pub/ lftp ftp.ripe.net:/pub> ls drwxrwxr-x 7 ftp ftp 4096 Mar 1 2005 stats lrwxrwxrwx 1 ftp ftp 25 Sep 14 2015 zones -> ../ripe/reverse/zones/1.0 lftp ftp.ripe.net:/pub> cd ../ripe/reverse/zones/ lftp ftp.ripe.net:/ripe/reverse/zones> ls drwxr-xr-x 2 ftp ftp 69632 Nov 5 15:04 1.0 -rw-r--r-- 1 ftp ftp 9751 Aug 11 2011 inter-rir-zonelet-exchange-1.0.txt Is inter-rir-zonelet-exchange-1.0.txt helpful enough? Best, -- Piotr Strzyżewski
In message <20201105155236.GA25409@hydra.ck.polsl.pl>, Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> wrote:
On Thu, Nov 05, 2020 at 06:41:17AM -0800, Ronald F. Guilmette via db-wg wrote:
P.S. I also don't think that it would have killed anyone if someone had just had the minimal courtesy to put a README file in the /pub/zones/ directory, explaining what Anand Buddhdev just explained about why some data is present there, while a whole lot of other data that one would naturally expect to see there is just mysteriously absent. ... Is inter-rir-zonelet-exchange-1.0.txt helpful enough?
That file certainly is quite helpful and explanitory. Now, if someone could just move it out of the obscure little directory where it is sitting alone, put it into the same directory where the actually relevant zonelet files actually exist, and then rename it to "README", then it might actually provide useful information to people who are coming at this stuff cold, and who aren't already know-it-alls.
participants (5)
-
Anand Buddhdev -
Nick Hilliard -
Piotr Strzyzewski -
Randy Bush -
Ronald F. Guilmette