[dns-wg] RIPE NCC DNSSEC trust anchors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear colleagues, Most of the zones that the RIPE NCC signs with DNSSEC have trust anchors in their parent zones, with the exception of these three zones: 151.76.62.in-addr.arpa ripe.int ripen.cc We have been publishing trust anchors for these three zones on our website, as well as in the ISC DLV trust anchor repository (TAR): https://dlv.isc.org On Tuesday, 11 November 2014, we rolled our DNSSEC Key Signing Keys and added the new trust anchors for these three zones to the ISC DLV TAR. Because we believe manual configuration of trust anchors is very rare these days, we are taking this opportunity to stop publishing trust anchors for these three zones on our website. The trust anchors remain available via the ISC DLV TAR. Of course, as soon as we are able to publish DS records for these zones in their parents, we will do so and withdraw them from the ISC DLV TAR, as we have done for all our other zones. If you have any questions or concerns, please send email to d...@ripe.net. Regards, Anand Buddhdev Senior Engineer RIPE NCC -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlRkxj4ACgkQi+U8Q0SwlCvWtQCgiCxJt53Ala7tTYXzzXW6787w GPcAn0a/u+aRB8BlpTT5cp5QomFo/LSB =ZAsP -END PGP SIGNATURE-
Re: [dns-wg] ripe.net axfr
On 13/12/14 09:24, Antonio Prado wrote: > why pri.authdns.ripe.net should allow AXFR ripe.net zone? > just asking Hi Antonio, The ripe.net zone has always been open for AXFR. There is little point in blocking AXFR, because the zone is signed with NSEC, and can be easily enumerated. Regards, Anand Buddhdev RIPE NCC
[dns-wg] Improvements to the RIPE NCC DNS provisioning infrastructure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear colleagues, The RIPE NCC is improving the resiliency of our DNS infrastructure by introducing multiple provisioning and distribution servers. One of the services we provide is secondary DNS for large reverse DNS zones. LIRs request this by adding "ns.ripe.net" to the "nserver:" attribute of their domain objects. Our provisioning system then automatically configures the server ns.ripe.net as a secondary for the reverse zone in that domain object. However, ns.ripe.net is not a single physical server. It provides DNS service from several servers using BGP anycast. For this reason, we have separate hidden distribution servers. If you are using this service, you will need to update your configuration. You will need to change your DNS server access control lists, notify settings and firewall settings. Please allow the following two new name servers to transfer your reverse DNS zone(s): 193.0.19.190 / 2001:67c:2e8:11::c100:13be 93.175.159.250 / 2001:67c:2d7c:66::53 Additionally, if you would like ns.ripe.net to update promptly, then please send notify messages to the above four addresses. Note that any notify messages sent directly to the addresses of ns.ripe.net will not be seen. Also, we do NOT support any non-standard configurations (such as port numbers other than 53, TSIG keys and so on). Please update your configuration by 31 July 2015. This is the date when we’ll retire the old server. If you have any questions, please send an email to Regards, Anand Buddhdev RIPE NCC -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVbaqyAAoJEBXgoyUMySoFkcwP/iFoS32eGZYdmTkyGoKvFZgS 6bdIVZcUNZzE3KEbLj9mtLG4pZIdDrCtAkEgg+ZRGwElCjzzrxTXybQxziAOz/JJ Xy+FUpXyf2HpgQ0b6Zbu+Dx8lYbt++hVHD6NYSUrZgKZDVw4/nNE1b32XW63WUK3 Du4nou3JF8m5bOBG4qkLU4jPoQDuSr4pduOZ6LX7/Vilxfj4r12wgTED2hTCgaD/ +8vBmHVcxQPkYy+r8/ZG63raHIpTn8glEjb/ecAZJ9XGAgHGgS3nZkARKy0V80Yg HtBmEx6U3BksBYKq2iFiNZK1jYwD4yO9Jq66wgSpbH3Oqw9ocgiI4Q8VfqrevZC+ 98smPv60sKJAGj22yziscSWJESk3jWYYOrY1J+vVtqi777JbXw6vgIQUgki9+Udi V6qHNV0nRfjrPgyE9F9xdufZjrWMiNmiKffPa+LOSc15nTGFeY5A5FFW4fo+Up37 7qMvOpMML6tBJTbKVkG0uOPkQ/hzEoRgLnvvGiSvwG4uRie13MVk1nEVlnad1SKs c1UwsdhkVZ1qf4b7jlquB0rBkRn3KIZkuCE6TLSSI9BKZg4krX2A2CuvaC7cm+jn XIm/Kh4nyVg5wpqRP9eLkwneDD7aPmWKUDZ79GEdcRejg32Cmii22bGgcxa3gw1W JmMzYQFsa/UuDQI8nbJT =btiT -END PGP SIGNATURE-
[dns-wg] RIPE NCC secondary DNS configuration changes complete
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear colleagues, We announced some changes to the RIPE NCC's DNS provisioning infrastructure in June: https://www.ripe.net/ripe/mail/archives/dns-wg/2015-June/003095.html We have now completed this configuration change. The new servers are functioning as the hidden masters for ns.ripe.net, and the old server (193.0.0.198) is no longer performing this function. If you have any questions, please reply to Regards, Anand Buddhdev RIPE NCC -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVv0GcAAoJEBXgoyUMySoFXeQP/2R5fp28whuZxVWIncpk8wKg 00pZ07BDbPChyaxhF2f6NHMmTfJV3yp1xXI6tIoQbzmo602lTMnBvywH2ic4P8fO vOsSlBHqSkR5SCsNJ+AoMVbqpUygH7Sr9Om3H7hRFWzfS3PWfLd2YSdRRrV9LR9r 8A5B6sqy5dKWGcT1FfBJvmNHXBnLLDaFA6PpibNA8dN+9mteARyPuBPwF/u+tfCC dD4neRw5eI2M7C7B5313W33R4l57oCvHX7eeuKsfRQzWCOMHqlVQoWP/+/JfVZRG iMBtEUKpfXTMNOIDh1ikRHV7Ra6yWY57g8uWqs9umW6PfY3zSGAL1U+U7ExARvyU /6Ags0/71FWQUM26nNnvYuhpWP2IHoNuOHt1IFZ4UqNgGxRH+IGL8Nagm60DeHnT cOltmiygMs2MWs+ej560URsze82pAPFCauqIv1r0HArUhSPQEX90PbsPzyESL4PL G6rJfw5k1PtEApeos9ezlI4HRuMfWHMEO5HgQ5Eb6dSDv7XHfZMbKKxTgup1jPUk sjfSTPidbWj4pFsMkI+a3er8IPk1vEe2Z53BQR+ateMDK6Oa5aUoqz5sZBrklI5z 4EqRsn2Z44bQFVHMv71wiG55r4s9MP+MrBmyS4JIcK1OJmOYt86YBwtT37o+evsT FRu9FqzOQ3L9+wj7S/6h =07hR -END PGP SIGNATURE-
[dns-wg] Algorithm Upgrade for RIPE NCC DNS Zones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear colleagues, All the zones maintained by the RIPE NCC are signed with the RSA/SHA1 algorithm. At the RIPE 70 meeting we committed to upgrade the algorithm of all our zones. We required an updated version of our signer software that could sign a zone with two different algorithms at the same time. We then needed to test it, to ensure that we could switch algorithms without causing major validation errors. We published a RIPE Labs article about our experiences here: https://labs.ripe.net/Members/anandb/dnssec-algorithm-roll-over We are happy to announce that we are now ready to roll the keys of all our zones and sign them with the RSA/SHA256 algorithm. We will follow the process described in the RIPE Labs article. We plan to begin the roll-over on Monday, 30 November 2015. We would still like to exercise caution, so we will not roll the keys of all zones at the same time. We will do this in batches, starting with a small number of reverse DNS zones of the RIPE Meeting address space. If you have any questions, please send an email to . Regards, Anand Buddhdev RIPE NCC -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWVuZ8AAoJEBXgoyUMySoFoHYP+weE0kP6hkbeRJLDO610v612 ZyE81BkNQs6LE/lufAyMLkA36b3J9mVvDcmc2ciuRWdFLef3Z4XD2X+BG0mAAJgM cy4nD7Hx+6m9h3nGGT62CJTneXXNMyqzozcQIDdEyau8qUVM91/SgDFgBJWmnMML JC34hXWb5au5S+Bus/Vaq4iMtROQAq3F6xXR4xiEQoU+XwbOLkWU6WjqwCaJfYZ5 UBaQtpdcqNOjKXyVlDoF6LJnxgxW3kXMi98FEQ8Ye0oYri/h98gdt6BWYfhf5kTY aU7RTAJ2V0ksOVmipSQIT5KkrmV3mwOiuAWjVJYaVJWxmYoHdyMlhtHpUJT4LV1P KvN/XXSZdjBawCNib8zjFFXb79cFRBZ8PMm55W5pcwYNipAK71mlmhEIop8PX3ee oYwU1MzxNoREP3zYWWgolJhhzJsGpZP1ceRJwI4pKQpz4xFju0tJHBQAHICI8Z1R yinf2H0rYPKKyaBNt9aYB/LsTGdh+ccIl4o4/Ep4sc102cemT11mf4QYCeYUIjZW wULcgf4L7d8m3NCa33i5zX44TlQ7xTjdW4m60auSdaRjlUsLTewYkAkrhC5G+aZP oA4RYJVwi0dSbw62S03+MN2senWgSfZe85jqgMX24u/W7XNp59va9wA8nPVJVPl/ XbAQ69qXXKbldMdI4CI2 =/Pwl -END PGP SIGNATURE-
Re: [dns-wg] Algorithm Upgrade for RIPE NCC DNS Zones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear colleagues, I am happy to report that we have completed the roll-over of the keys of all our zones, and upgraded the signatures to RSA/SHA256. Regards, Anand Buddhdev RIPE NCC On 26/11/15 12:01, Anand Buddhdev wrote: > Dear colleagues, > > All the zones maintained by the RIPE NCC are signed with the > RSA/SHA1 algorithm. At the RIPE 70 meeting we committed to upgrade > the algorithm of all our zones. > > We required an updated version of our signer software that could > sign a zone with two different algorithms at the same time. We then > needed to test it, to ensure that we could switch algorithms > without causing major validation errors. We published a RIPE Labs > article about our experiences here: > > https://labs.ripe.net/Members/anandb/dnssec-algorithm-roll-over > > We are happy to announce that we are now ready to roll the keys of > all our zones and sign them with the RSA/SHA256 algorithm. We will > follow the process described in the RIPE Labs article. We plan to > begin the roll-over on Monday, 30 November 2015. We would still > like to exercise caution, so we will not roll the keys of all zones > at the same time. We will do this in batches, starting with a small > number of reverse DNS zones of the RIPE Meeting address space. > > If you have any questions, please send an email to . > > Regards, > > Anand Buddhdev RIPE NCC > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWd/XRAAoJEBXgoyUMySoFt+IP+QERNpy8jPqLkIVe51/55yga XxgUFHkFUiZ2FsVf7OIWvU3bCK4thKSjidGb3cYwkwG/i5xEzXkEn6jhj6m++ZJD lyg65TnQRTJ6eZZ8TfoXrfSC8QMQlFh1RB0zZhLbfeaUkFBksj2DuiwLbYLtSrU1 Iiadh2rOeMO0xTG6JecCn8QCjQQhfG1c/tnKF21gfTo0azd3lT0y8WeQ2b1anir0 UiewFpsi19yEUKaUCYrif9QU61UPR1oKa+LhQuvGMAc7jZ0E5Jqnu3AwyHOlbR20 gobLtkbvdOnwc3sTzPABEs9R6Q2pjKsdAfqVxNiUfNoHPXhYyy3FHdjPclW0ztmx q839jk+aXY7t8oc2EqRkVtT5vk4gAVPesrMJBQZbXlXj8HVs8+G0ytrmTzpok8QD qULAuxRHEgD5LLzHxzutK33UPTPSxgRau8xPMAUwhmmiLudKREOyP29Tx6JFR99B c8lIeXgJu2Hj5dAzP/D1lmiKdwuyHb0nnd8q2+m97gTA9ljExozLDHoGnxmb2rAh 3EOizejloRDBrCS3/ugInAVyKRKyOUZyLNOjYoI3IsVGL3Gxys/5Bk4VcGnOKd6i poexaZokM8l3WTugtbhkmwOS3qi3llZIXrFDsvsKpKMkLDaB/nXsImPRGpwDGjyo ltLT3p91fWYusjKJU/IK =KJMr -END PGP SIGNATURE-
Re: [dns-wg] Algorithm Upgrade for RIPE NCC DNS Zones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/12/15 13:57, Jim Reid wrote: > Well done! Congratulations to you and your colleagues Anand for > the successful completion of this task. Thanks Jim! > Are there any experiences or lessons learned during this rollover > that are worth sharing with the WG? Yes. We actually tested algorithm roll-over, and wrote about our experiences in a RIPE Labs article before starting the process. Here's the link again, as a reminder: https://labs.ripe.net/Members/anandb/dnssec-algorithm-roll-over In this article, we talk about one issue we faced, and how we overcame it. When rolling the algorithm of our zones, we followed the procedure we had developed, taking care of this issue, and as a result, there were no validation failures during the roll-over. Regards, Anand Buddhdev RIPE NCC -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWd/q4AAoJEBXgoyUMySoFiSYP/2jf7B9xFRGqhaOapKk4N8U8 4qIMBadEjeibSaK+JJONImHsHRvlEkNboLTLNGH/NCPJFjQqNfDAwVyrNbfdvq9j 87LCLdaCXNBo5YeW/tXCQPjvw16Acc6qSGMEvfIkSQLKTkpJIg6Jz/8WPutjVCCo DCw/xwlm6g/n1J+eV65YZ+QFAH65hjdoHHHGOfBSbDeF/mz8qDo7Fq0llmHrmo/o Gx8ho/8kwVZfiRZHW+V+BuKk4e316HgQKjxIJHtefymfGGFDU0Jlsvu9NVW9a9ON dzUvGZ84qikD+D8aGBADM0Cf/2p2+wZD08b1b8bjYXuJj5gmwsKM8NWV2jf/nxhw zLhn0R3sPnzzfZTCv+MG2RaF9ymgyehiOCdlcdnHcj9M0ioeEqdRksh2fb+/9cs6 MnPhXxkU0uJHUZvjk15gRsq6fcwP9cP7h4VHvgBczjKTirJD+Qo2DWIqLyakfcdd waJzmuBt8MsX2m2yArGgqW1m8wRceSWEdlR+1kE5dm5X0EkHn3FWPaSyPzYs4FoY KEQa7EBUGz/KLs16UGRqlYGvDDHW6hjCRkMdx3XMzhsAB3f0xz7lg6BQVPs8zt6l 1CBH14AcTMC/s+RDjaV3Lhrdr7XgfgFe9aCSJ3xMFQE2BD1mRTSgfKnDLf3Zi7YK h93J79PMTWIIQ54VsEAI =aSva -END PGP SIGNATURE-
[dns-wg] Service outage at two K-root nodes
Dear colleagues, We have been upgrading the operating system and name server software on all K-root servers. The process has mostly gone quite well, but we have had an unfortunate incident. Two of the newly upgraded nodes had been accidentally announcing the K-root prefixes even though the name server software on them was not running. This means that queries sent to these two servers between 12 and 19 January were not answered. The affected nodes are in Belgrade and Reykjavik. We estimate the percentage of queries lost to be 0.3%. Normally, failure of the name server would result in automatic withdrawal of the prefix announcements. However, this failure was caused by a flaw in the deployment process, which did not activate the correct software components in the right sequence. We have identified this issue and fixed it, so that this failure cannot happen with any future installations or upgrades. We apologise for any inconvenience caused. If you have any specific questions please send email to . Regards, Anand Buddhdev RIPE NCC signature.asc Description: OpenPGP digital signature
[dns-wg] Reverse DNS issue for some delegations in the RIPE NCC service region
Dear colleagues, Between 17:00 UTC yesterday and 10:00 UTC today, we had an issue that affected some reverse DNS delegations. The delegations in the RIPE Database where the parent zone is operated by ARIN were affected. RIPE NCC publishes zonelet files containing these delegations, and these are picked up by ARIN's DNS provisioning system periodically. At the end of these zonelet files is a summary of the counts of various types of DNS records. A bug in our code accidentally published these summaries with zero counts, and as a result, the ARIN DNS provisioning system appears to have removed the delegations. We have corrected this bug, and the zonelet files now contain the correct counts. They have been published on the RIPE NCC FTP server, and ARIN's DNS provisioning system has picked them up and reintroduced the delegations. We apologise for any inconvenience caused by this. This is the first time that such an issue has occurred with delegations that are exchanged by the zonelet mechanism, and we will try to engineer monitoring to prevent such an outage in the future. RIPE NCC's delegations in the following ARIN-operated zones were affected. The majority of the other delegations in these zones come from ARIN and the other registries, and were not affected. 104.in-addr.arpa. 107.in-addr.arpa. 128.in-addr.arpa. 129.in-addr.arpa. 130.in-addr.arpa. 131.in-addr.arpa. 132.in-addr.arpa. 134.in-addr.arpa. 135.in-addr.arpa. 136.in-addr.arpa. 137.in-addr.arpa. 138.in-addr.arpa. 139.in-addr.arpa. 13.in-addr.arpa. 140.in-addr.arpa. 143.in-addr.arpa. 144.in-addr.arpa. 146.in-addr.arpa. 147.in-addr.arpa. 148.in-addr.arpa. 149.in-addr.arpa. 152.in-addr.arpa. 156.in-addr.arpa. 157.in-addr.arpa. 158.in-addr.arpa. 159.in-addr.arpa. 160.in-addr.arpa. 161.in-addr.arpa. 164.in-addr.arpa. 165.in-addr.arpa. 166.in-addr.arpa. 168.in-addr.arpa. 169.in-addr.arpa. 170.in-addr.arpa. 173.in-addr.arpa. 198.in-addr.arpa. 199.in-addr.arpa. 206.in-addr.arpa. 209.in-addr.arpa. 216.in-addr.arpa. 23.in-addr.arpa. 24.in-addr.arpa. 45.in-addr.arpa. 52.in-addr.arpa. 65.in-addr.arpa. 66.in-addr.arpa. Regards, Anand Buddhdev RIPE NCC signature.asc Description: OpenPGP digital signature
Re: [dns-wg] Reverse DNS issue for some delegations in the RIPE NCC service region
Hello Heike, Thank you for reporting this. We're looking at it now. My analysis shows that two out of 4 APNIC-operated zones are affected as well: 153.in-addr.arpa 163.in-addr.arpa We are attempting to resolve this as soon as possible. Regards, Anand Buddhdev RIPE NCC On 17/03/2017 13:15, Heike Schwingel-Horner wrote: > our 153.in.addr.arpa does not work correctly, could you please check. > Tanks, Heike > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
[dns-wg] Additional information about the RIPE NCC reverse DNS issue
Dear colleagues, This is a follow-up to our message of Friday about issues with some reverse delegations. After doing a thorough analysis, and with the help of ARIN staff, we found more issues with our zonelet generation code, and this showed that we had indeed published some empty zonelet files. From ARIN's point of view these were valid zonelets, with no content, and that is why the delegations were removed. Similarly, three zonelets that APNIC picks up also had empty content. We fixed these issues late on Friday afternoon, and by Friday evening, both registries had re-imported the correct zonelets and were again publishing the missing delegations. We will evaluate our code review and testing to prevent this from happening again, and add some monitoring to alert us to such a situation earlier. We are also discussing this with the other RIRs to find ways to improve the zonelet exchange process. Regards, Anand Buddhdev RIPE NCC signature.asc Description: OpenPGP digital signature
Re: [dns-wg] [dns-operations] Additional information about the RIPE NCC reverse DNS issue
Dear DNS working group, Shane's explanation of the zonelet exchange system is correct. This system was adopted by the RIRs in the early days of resource transfers. The RIR with the majority of address space in a given IPv4 XXX/8 of address space is responsible for running the corresponding XXX.in-addr.arpa zone. If any of this address space is registered in another RIR, then the majority RIR needs to get delegation information from that RIR, and this is done by importing "zonelets", which are similar to zone files, and contain NS and DS records, and perhaps glue records for in-bailiwick name server names. The original code for this at the RIPE NCC was indeed written in perl. However, that code is not in use any more. It has since been replaced with newer code, for a variety of reasons. However, it still produces and consumes zonelets for exchanging delegation information with other RIRs. The zonelet system is quite simple in many ways, and I can appreciate why it was chosen back in the day. However, it is pull-based, and so delegation information takes time to propagate. In the event of an error, it similarly takes a while before correct information can be republished. Shane mentioned the use of DNAME records, but I don't think it's the right solution for this case. DNAME records alias a name and everything below it to another name. But here, we don't quite want aliases. We just want the NS and DS records of delegations from another RIRs merged into the parent zone we operate. We are working with the other RIRs to look at the system, to see if we can make it more robust, and perhaps faster, so that delegation information can be exchanged more quickly, and in the event of errors, also corrected more quickly. Regards, Anand Buddhdev RIPE NCC signature.asc Description: OpenPGP digital signature
[dns-wg] APNIC and RIPE NCC Joint Research Programme
Dear all, The RIPE NCC and APNIC will be carrying out research into the DNS root server system later this month. We’ve published an article on RIPE Labs providing a brief outline of the next step in the research programme. https://labs.ripe.net/Members/alun_davies/apnic-labs-research-on-dns-root-server-system Best regards, Anand Buddhdev Senior Engineer, RIPE NCC
[dns-wg] Changes to RIPE NCC's zonelet repository
Dear colleagues, The RIPE NCC publishes DNS zonelets at the following URL: ftp://ftp.ripe.net/pub/zones The other RIRs fetch these zonelets to merge their content into the zones they operate. All zonelet files are published with canonical filenames, eg. 1.in-addr.arpa-RIPE. Additionally, for the IPv4 reverse DNS zones, we have been publishing symbolic links with legacy names (eg. 001-RIPE) that point to the canonical names, because old provisioning software at all the RIRs relied on the legacy names. However, this is no longer necessary. Therefore, on August 22 2017, we will stop publishing these legacy files, and all the zonelets will be published only with their canonical names. Regards, Anand Buddhdev RIPE NCC
Re: [dns-wg] Changes to RIPE NCC's zonelet repository
Dear colleagues, At the request of one of the RIRs, we have postponed this work to 5 September 2017. Regards, Anand Buddhdev RIPE NCC On 15/08/2017 14:44, Anand Buddhdev wrote: > Dear colleagues, > > The RIPE NCC publishes DNS zonelets at the following URL: > > ftp://ftp.ripe.net/pub/zones > > The other RIRs fetch these zonelets to merge their content into the > zones they operate. All zonelet files are published with canonical > filenames, eg. 1.in-addr.arpa-RIPE. Additionally, for the IPv4 reverse > DNS zones, we have been publishing symbolic links with legacy names (eg. > 001-RIPE) that point to the canonical names, because old provisioning > software at all the RIRs relied on the legacy names. However, this is no > longer necessary. Therefore, on August 22 2017, we will stop publishing > these legacy files, and all the zonelets will be published only with > their canonical names. > > Regards, > Anand Buddhdev > RIPE NCC > >
Re: [dns-wg] Changes to RIPE NCC's zonelet repository
On 15/08/2017 14:44, Anand Buddhdev wrote: Dear colleagues, This work is complete, and we're no longer publishing zonelets with legacy file names. Regards, Anand Buddhdev RIPE NCC > Dear colleagues, > > The RIPE NCC publishes DNS zonelets at the following URL: > > ftp://ftp.ripe.net/pub/zones > > The other RIRs fetch these zonelets to merge their content into the > zones they operate. All zonelet files are published with canonical > filenames, eg. 1.in-addr.arpa-RIPE. Additionally, for the IPv4 reverse > DNS zones, we have been publishing symbolic links with legacy names (eg. > 001-RIPE) that point to the canonical names, because old provisioning > software at all the RIRs relied on the legacy names. However, this is no > longer necessary. Therefore, on August 22 2017, we will stop publishing > these legacy files, and all the zonelets will be published only with > their canonical names. > > Regards, > Anand Buddhdev > RIPE NCC > >
[dns-wg] Call For Presentations - DNS-OARC Workshop 28, San Juan, Puerto Rico, 8th/9th March 2018
Call For Presentations The 28th DNS-OARC Workshop will be hosted by ICANN in San Juan, Puerto Rico, and will take place on March 8th and 9th immediately before ICANN61 (March 10th - 15th) [*] The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. The first day of the workshop will start with a Members-only session which will include reports on DNS-OARC's activities. If you are an OARC member and have a sensitive topic that you wish to present during that session those can be accommodated. A timeslot will also be available for lightning talks (5-10 minutes) on day two of the workshop for which submissions will be accepted on the first day of the workshop, until 4pm. Workshop Milestones: 19 Jan 2018 - Deadline for submission 23 Jan 2018 - Initial contribution list published 16 Feb 2018 - Full agenda published 02 Mar 2018 - Deadline for slideset submission Details for presentation submission will be published here: https://indico.dns-oarc.net/event/28/call-for-abstracts/ The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via Anand Buddhdev, for the OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) [*] <https://www.icann.org/news/blog/icann61-still-slated-for-puerto-rico> <https://www.icann.org/news/blog/a-look-ahead-to-icann61-in-puerto-rico>
[dns-wg] Extended Deadline for submissions for DNS-OARC Workshop 28
The 28th DNS-OARC Workshop will be hosted by ICANN in San Juan, Puerto Rico, and will take place on March 8th and 9th immediately before ICANN61. The deadline for submissions to the workshop has been extended to February 2nd, with the other workshop milestones updated as follows: 19 Jan 2018 - Original Deadline for submission 23 Jan 2018 - Initial contribution list published 02 Feb 2018 - Extended Deadline for Submission 13 Feb 2018 - Updated contribution list published 23 Feb 2018 - Full agenda published 02 Mar 2018 - Deadline for slideset submission Presentation submission details are at: <https://indico.dns-oarc.net/event/28/call-for-abstracts/> Anand Buddhdev, for the DNS-OARC Programme Committee
[dns-wg] Deletion of ns-v6.ripe.net
Dear colleagues, The RIPE NCC provides secondary DNS for some reverse DNS zones using a server called ns.ripe.net. In the early days of IPv6, this server was also given another name, ns-v6.ripe.net, and some users used this name in their IPv6 reverse DNS zones. Last year, we contacted these users and asked them to switch to the name ns.ripe.net instead. This makes the RIPE NCC's pre-delegation checks and provisioning system simpler. Now that the name ns-v6.ripe.net is no longer in use by anyone, we are going to delete it from the ripe.net zone. We will do this on Thursday, 26 April. If you have any questions or concerns about this, please send an email to . Regards, Anand Buddhdev RIPE NCC signature.asc Description: OpenPGP digital signature
Re: [dns-wg] Deletion of ns-v6.ripe.net
On 24/04/2018 16:48, Jim Reid wrote: Hi Jim, > Anand, could you clarify what you mean by “no longer in use”? Has it > gone from all the reverse zones that referenced it? Are no more queries > for ns-v6.ripe.net hitting the ripe.net name servers? There are no domain objects in the RIPE Database, with "ns-v6.ripe.net" in their "nserver" attributes. The domains that are using "ns.ripe.net", when queried for NS records, only return "ns.ripe.net" and not "ns-v6.ripe.net". Checking for queries for "ns-v6.ripe.net" on the all the ripe.net name servers isn't possible, because we don't have access to query logs of the servers that provide us with secondary DNS service. Even if we *could* look at the queries, and they showed queries for "ns-v6.ripe.net", it doesn't mean that the name is in use. > I’m wondering if the name might still be hard-wired into scripts or > provisioning/testing tools. It may be hard-wired in some scripts, and if so, they may produce an error. However, it is not used as the target of any NS records that we are aware of, so I don't expect any major outages. Regards, Anand
Re: [dns-wg] Deletion of ns-v6.ripe.net
On 24/04/2018 17:33, Gert Doering wrote: Hi Gert, > OTOH it might be worth some considerations about "soft landing" - that > is, point ns-v6.ripe.net at a new server that logs queries, respons to > everything with SERVFAIL (or forwards to ns.ripe.net?), and if you see > significant traffic, contact the sender and notify them of the coming > end... I now realise I should have made this even more explicit: ns.ripe.net and ns-v6.ripe.net are the same server, and have the same IP addresses. It's near-impossible for us to tell whether someone is resolving ns-v6.ripe.net, and then sending queries to its addresses. However, having two names makes our pre-delegation and provisioning somewhat more complex, and so we wish to simplify things. We did check that the name ns-v6.ripe.net was not listed as the target of any NS record in any delegations or apices, to ensure that reverse DNS resolution is not affected. Regards, Anand
Re: [dns-wg] Deletion of ns-v6.ripe.net
On 24/04/2018 17:28, Jim Reid wrote: Hi Jim, > Well, I would say that if the name’s in the query traffic, that > means it’s “in use”. For some definition of that term. YMMV. I respectfully disagree. A human may idly query the name ns-v6.ripe.net out of curiosity. If they happened to use one of these shiny new resolvers that do pre-fetching to keep an entry alive, the queries for that name will persist for a long time, and perhaps even forever. I don't consider this to be genuine usage. Geoff Huston has done some interesting research in this area and shown that even single-use unique names, generated for a special purpose, end up being queried for weeks or months thereafter. Regards, Anand
[dns-wg] Announcement - Joint CENTR-Tech / DNS-OARC Workshop, Amsterdam, NL, 13th/14th October 2018
[with apologies to those who see this on multiple lists] The 29th DNS-OARC Workshop will be a joint workshop combined with CENTR-Tech and will take place at the Hotel Okura, Amsterdam, Netherlands, on October 13th and 14th 2018. Workshop Milestones: 01 May 2018 - Workshop Announcement 01 Jun 2018 - Submissions and Registrations open via Indico 13 Jul 2018 - Deadline for submission 17 Aug 2018 - Contribution list published 14 Sep 2018 - Full agenda published 06 Oct 2018 - Deadline for slideset submission 13 Oct 2018 - Workshop Anand Buddhdev, on behalf of the joint Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor.
[dns-wg] Call For Presentations - Joint CENTR-Tech / DNS-OARC Workshop, Amsterdam, NL, 13th/14th October 2018
The 29th DNS-OARC Workshop will be a joint workshop combined with CENTR-Tech and will take place at the Hotel Okura, Amsterdam, Netherlands, on October 13th and 14th 2018. The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. A timeslot will also be available for lightning talks (5-10 minutes) on day two of the workshop for which submissions will be accepted on the first day of the workshop, until 4pm. The second afternoon of the workshop will start with a Members-only session which will include reports on DNS-OARC's activities. If you are an OARC member and have a sensitive topic that you wish to present during that session those can be accommodated. The Members-only session will be followed by the AGM. Workshop Milestones: 15 Jun 2018 - Submissions and Registrations open via Indico 13 Jul 2018 - Deadline for submission 17 Aug 2018 - Contribution list published 14 Sep 2018 - Full agenda published 06 Oct 2018 - Deadline for slideset submission 13 Oct 2018 - Workshop Details for presentation submission are published here: <https://indico.dns-oarc.net/event/29/call-for-abstracts/> The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via Anand Buddhdev, for the joint Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.)
Re: [dns-wg] How to determine the last message in sequence in DNS TCP responce
On 27/02/2019 17:21, Владимир Мартьянов wrote: Hi Vladimir, > I make DNS zone transfer request (aka AXFR) via TCP to the server. The > answer is too big (>100Kb), so it could not be sent in one TCP > message. So the server send me a sequence of messages. > > How can I determine which message is the last? I can't found anything > about it's count in the first message. I can't found any special flag > in the last one. I can't found anything about it in RFC1035. > > Could you please explain how to find "end of answer"? A zone transfer starts with the SOA record of the zone, and ends with the same SOA record. That's how you know that the transfer is complete. To learn more about zone transfers, see RFC 5936, section 2.2: https://tools.ietf.org/html/rfc5936 Regards, Anand Buddhdev RIPE NCC
Re: [dns-wg] NCC reverse delegation criteria
Good morning Måns, We will come back to you shortly with answers to your and others' questions in this thread. Regards, Anand Buddhdev RIPE NCC On 10/06/2019 09:22, Måns Nilsson wrote: > Recently, a discussion regarding the checks performed by the NCC before > reverse delegation is made came up on the members-discuss list. It was > concluded that this should be discussed here rather than there. > > The members archive might not be available to all, so I'll try to > summarize. Please add your take on summary if you find mine lacking. > > The questioned practice was that the NCC rejects the delegation request > if the target server is found to be an open recursor. > > Some participants argued that this is not a technical problem, and some > said yes it is. > > Some held that the NCC has no authority blocking a request, but it was > argued that every delegation is subject to RFC 1591 responsibilites. > > For starters, are the delegation requirements described somewhere? > > Best regards, >
Re: [dns-wg] Using CDS delegation to add DS records (was Re: NCC reverse delegation criteria)
On 11/06/2019 13:00, Tony Finch wrote: Hi Tony, >> The RIPE NCC recently announced at RIPE 78 that they now support RFC 8078 for >> reverse DNS: >> >> https://ripe78.ripe.net/presentations/138-138-RIPE78_DNS_Update.pdf > > Oh, this is cool! Is there any more information anywhere? I couldn't find > any details in the RIPE database documentation. We haven't yet implemented support for RFC 8078, but we're working on it, as I mentioned during my presentation. We will provide more information here on the mailing list about our progress, and we hope to have it implemented by the end of this year. Please accept our apologies for not providing more information earlier. Regards, Anand Buddhdev RIPE NCC
[dns-wg] RIPE NCC's reverse DNS delegation process and stats
Dear colleagues, As requested, here is some information about the reverse DNS delegation process applied by the RIPE NCC. We perform pre-delegation checks with a local instance of Zonemaster, which is DNS delegation testing software that was developed by AFNIC and IIS. The software performs the following tests: https://github.com/zonemaster/zonemaster/tree/master/docs/specifications/tests Test results are classified into one of five levels of severity: INFO, NOTICE, WARNING, ERROR, or CRITICAL. This classification is governed by a policy, and ours follows the default Zonemaster profile here: https://github.com/zonemaster/zonemaster-engine/blob/master/share/profile.json According to this policy, a name server offering recursion is classified as ERROR. When we perform pre-delegation tests, the request is rejected if any of the test results are classified at the ERROR or CRITICAL levels. We have the results of pre-delegation tests going back to 30 June 2017. Between then and now, we rejected 5,125 delegation requests for 1,833 zones because at least one of the name servers of a zone was an open recursor. It's worth noting that these requests may have been rejected for other reasons in addition to this one, and there were multiple requests for some zones, which accounts for the imbalance between the two numbers. Finally, before Zonemaster we used software called DNScheck, which was developed by IIS. This also checked for open recursive name servers and classified this condition as an error. Regards, Anand Buddhdev RIPE NCC
[dns-wg] Hidden master maintenance
Dear colleagues, The RIPE NCC runs a pair of hidden masters for transferring in zones from various sources, and distributiong these zones to the K-root and reverse DNS anycast clusters that we operate. On Thursday 5 March 2020, between 12:00 and 17:00 UTC, we will be doing maintenance on one of these servers. In this duration, the server will be offline for some time. Its IP addresses are: 93.175.159.250 2001:67c:2d7c:66::53 This maintenance will not affect service in any way. The other hidden master will continue to function and keep all our DNS servers up to date. After the maintenance, I will send a follow-up message. Regards, Anand Buddhdev RIPE NCC
Re: [dns-wg] Hidden master maintenance
Dear colleagues, This work has been completed successfully. Regards, Anand Buddhdev RIPE NCC On 03/03/2020 12:38, Anand Buddhdev wrote: > Dear colleagues, > > The RIPE NCC runs a pair of hidden masters for transferring in zones > from various sources, and distributiong these zones to the K-root and > reverse DNS anycast clusters that we operate. > > On Thursday 5 March 2020, between 12:00 and 17:00 UTC, we will be doing > maintenance on one of these servers. In this duration, the server will > be offline for some time. Its IP addresses are: > > 93.175.159.250 > 2001:67c:2d7c:66::53 > > This maintenance will not affect service in any way. The other hidden > master will continue to function and keep all our DNS servers up to > date. After the maintenance, I will send a follow-up message.
[dns-wg] DNSSEC Validation Failures for RIPE NCC Zones
Dear colleagues, Yesterday afternoon (21 May 2020), our DNSSEC signer rolled the Zone Signing Keys (ZSKs) of all the zones we operate. Unfortunately, a bug in the signer caused it to withdraw the old ZSKs soon after the new keys began signing the zones. Validating resolvers may have experienced some failures if they had cached signatures made by the old ZSKs. We apologise for any operational problems this may have caused. We are looking at the issue with the developers of our Knot DNS signer to prevent such an occurrence in the future. Regards, Anand Buddhdev RIPE NCC
[dns-wg] DNSSEC validation problem with ripe.net
Dear colleagues, On 3 December, at around 15:40 (UTC+1), Matt Nordhoff and Peter van Dijk alerted us to a problem with the DNS resolution of certain names in ripe.net. Upon investigation, we discovered that a recent update in the zone had changed the status of some address records to glue records. This change was not handled correctly by our DNSSEC signer, and it left spurious NSEC records in the zone, which then caused validation failures. Eventually, around 20:00 (UTC+1), we forced the DNSSEC signer to fully re-sign the zone, and this fixed the problem. We have reported this issue to the developers of the DNSSEC signing software, and they are investigating. We are also adding some extra monitoring to our infrastructure, to detect such problems more quickly. Regards, Anand Buddhdev RIPE NCC
Re: [dns-wg] Update RIPE's DNS Zonemaster
On 21/12/2020 11:31, Arsen STASIC wrote: Hi Arsen, > RIPE's DNS Zonemaster version might be outdated, because it does not > support DNSSEC algorithm ED25519. This is the error message: > Signature for DNSKEY with tag 52537 failed to verify with error 'Unknown > cryptographic algorithm'. > https://dnscheck.ripe.net/test/328db6c75665721b You are correct. We are using an older version of Zonemaster, and it does not support ED25519. > But the Zonemaster software (Versions: engine 4.0.3, backend 6.0.2, GUI > 3.2.1) has already support for DNSSEC algorithm ED2551: > https://www.zonemaster.net/result/c1607f01d96a8d60 > > It would be good if RIPE's Zonemaster could also list its version numbers. We are already testing the latest version of Zonemaster, but we also need to update the OS it runs on, since we need newer versions of OpenSSL with support for ED25519. I don't have a date for you, but we hope to update Zonemaster to the latest version very soon. In the meantime, if you need to add or update a DS record for your zones, please email d...@ripe.net with a complete copy of your domain object, and we will do the updates for you manually. Regards, Anand Buddhdev RIPE NCC
[dns-wg] Automatic update of DNSSEC data in the RIPE Database
Dear colleagues, Some time ago, our community asked us to implement the automatic update of delegation signer (DS) records of secure delegations in the reverse DNS zones maintained by RIPE NCC. We are pleased to announce that we have implemented RFC 7344 and RFC 8078. We will begin the automatic updates on Thursday 25th May. You can read more about this in our reverse DNS configuration documentation here: https://www.ripe.net/manage-ips-and-asns/db/support/configuring-reverse-dns#4--automated-update-of-dnssec-delegations At the RIPE DNS working group session on the 24th of February 2021, Ondřej Caletka presented about this topic. A recording of the session is also available for viewing here: https://www.ripe.net/participate/ripe/wg/active-wg/dns/remote-sessions/remote-session-24-february-2021 If you have any questions or concerns, please send email to d...@ripe.net. Regards, Anand Buddhdev RIPE NCC
Re: [dns-wg] Automatic update of DNSSEC data in the RIPE Database
Dear colleagues, I made a mistake in the date. It should have been Thursday 25 March (not May). Apologies for this. Regards, Anand Buddhdev RIPE NCC On 18/03/2021 17:02, Anand Buddhdev wrote: > Dear colleagues, > > Some time ago, our community asked us to implement the automatic update > of delegation signer (DS) records of secure delegations in the reverse > DNS zones maintained by RIPE NCC. > > We are pleased to announce that we have implemented RFC 7344 and RFC > 8078. We will begin the automatic updates on Thursday 25th May. > > You can read more about this in our reverse DNS configuration > documentation here: > > https://www.ripe.net/manage-ips-and-asns/db/support/configuring-reverse-dns#4--automated-update-of-dnssec-delegations > > At the RIPE DNS working group session on the 24th of February 2021, > Ondřej Caletka presented about this topic. A recording of the session is > also available for viewing here: > > https://www.ripe.net/participate/ripe/wg/active-wg/dns/remote-sessions/remote-session-24-february-2021 > > If you have any questions or concerns, please send email to d...@ripe.net. > > Regards, > Anand Buddhdev > RIPE NCC
[dns-wg] DNSSEC algorithm roll-over of all RIPE NCC zones
Dear colleagues, During the RIPE 82 Meeting, we announced that we would soon roll the keys of all our DNSSEC-signed zones to a new algorithm, ECDSAP256SHA256, as recommended by RFC 8624. We are happy to announce that we are now ready to do this. On Tuesday, 15 June 2021, we will start the roll-over of both the Key Signing Keys (KSKs) and Zone Signing Keys (ZSKs) of our zones. The process will take several days to complete. We have performed algorithm roll-over previously, when we switched from RSASHA1 to RSASHA256. We wrote a RIPE Labs article about it, wherein we observed the need to perform this roll-over conservatively, in order to accommodate strict validators: https://labs.ripe.net/author/anandb/dnssec-algorithm-roll-over/ Therefore, our Knot DNS signer will use the conservative approach described in section 4.1.4 of RFC 6781. This approach ensures that even strict validators can continue to validate our DNSSEC-signed responses during the roll-over. If you have any questions or concerns, please send an email to d...@ripe.net. Regards, Anand Buddhdev RIPE NCC
[dns-wg] AuthDNS expansion and improved Hosted DNS app
Dear colleagues, We are happy to announce that you can now apply to host an instance of our AuthDNS service. We have updated our app, and it can now handle applications for both K-root and AuthDNS. Read more about it on RIPE Labs: https://labs.ripe.net/author/anandb/hosted-dns-application-update/ We have also updated our requirements, whereby we will accept well-provisioned virtual servers for hosting these services. Regards, Anand Buddhdev RIPE NCC
Re: [dns-wg] DNS Reverse configuration
On 21/10/2021 17:45, ANTONETTI Gilles wrote: Hi Gilles, [snip] My question is : can I create a new domain object only for this x.x.255.0/24, so that I can create reverse records on our own NS and only for this /24. Unfortunately, this is not possible. The presence of NS records at the delegation point of the /16-sized allocation (x.x.in-addr.arpa) occludes (hides) NS records below it. This is how the DNS protocol works. You'll have to find some way to convince the operator of the name servers to add a delegation for you on their name servers. Regards, Anand Buddhdev RIPE NCC
[dns-wg] Lower TTLs for NS and DS records in reverse DNS delegations
Dear colleagues, Users may request reverse DNS delegation by creating "domain" objects in the RIPE Database. Such domain objects must contain "nserver" attributes to specify the name servers for a reverse DNS zone, and may contain "ds-rdata" attributes, to specify delegation signer (DS) records. When the RIPE NCC publishes these records in the appropriate parent zones, the Time to Live (TTL) of all these records is set at 172800 (two days). The TTL of delegation NS records may be overridden by the TTL of NS records from a zone's apex. Alternatively, many large resolvers ignore the TTL values of NS records and cap them at much lower values such as 21600. Finally, there is no way for a zone operator to change the TTL of a DS record, which is only present in a parent zone. Long TTLs can cause problems for users when they want to change their name servers or perform DNSSEC key roll-overs. A long TTL on a DS record is especially harmful when a user needs to do a key roll-over in an emergency. We propose to lower, in the first quarter of 2022, the TTL on NS records to 86400 and on DS records to 3600. We welcome feedback or discussion about this, ideally via the DNS Working Group mailing list. If you prefer to send your feedback directly to us, you can email d...@ripe.net. Regards, Anand Buddhdev RIPE NCC To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] follow up of "Update RIPE's DNS Zonemaster"
On 18/02/2022 14:41, Nick Cao via dns-wg wrote: Hello Nick, When doing a DNSSEC algorithm rollover from ecdsap256sha256 to ed25519 today, I got the error 'Unknown cryptographic algorithm' when updating ds-rdata field. A quick google search led me to https://www.ripe.net/ripe/mail/archives/dns-wg/2021-January/003796.html, which dates back to more than a year ago. It seems that the zonemaster deployment has not been updated to day, thus I would like to ask about the current progress. Your observation is correct. The version of Zonemaster we're running isn't up to date, and can't handle algorithms 15 and 16. We are working on updating all the things. It is a two-stage process, where we need to update Zonemaster first (running on our current Linux distribution, CentOS 7), and then deploy it on a derivative of RedHat Linux 8, whose openssl understands these newer algorithms. Unfortunately, we cannot yet provide a date by when this will all be done. However, we appreciate your concern, and are putting more priority on getting this work done as soon as possible. The automatic update of your DS record happened as a result of our daily CDS scans. The code that does the scans and checks does not invoke Zonemaster, because it is only concerned with ensuring that the DNSSEC chain of trust is correct. Regards, Anand Buddhdev RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
[dns-wg] Changes to Time-to-Live (TTL) values in reverse DNS zones
Dear colleagues, In 2021, we announced a plan to change the time-to-live (TTL) values in the reverse DNS zones that we maintain. You may view the announcement here: https://www.ripe.net/ripe/mail/archives/dns-wg/2021-November/003928.html Many members of the community expressed support for our proposal. Therefore, we are going to make these changes next week on Wednesday 20 April. We will lower the TTL of NS records to 86400 (1 day) and that of DS records to 3600 (1 hour). Note that the TTL of records imported from other Regional Internet Registries (RIRs) will not be affected. Those records will be imported with the TTLs as published by the origin RIR. Regards, Anand Buddhdev RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] Changes to Time-to-Live (TTL) values in reverse DNS zones
Dear colleagues, This work has been completed, and all zones are now being published with lower TTLs. Regards, Anand Buddhdev RIPE NCC On 11/04/2022 14:44, Anand Buddhdev wrote: Dear colleagues, In 2021, we announced a plan to change the time-to-live (TTL) values in the reverse DNS zones that we maintain. You may view the announcement here: https://www.ripe.net/ripe/mail/archives/dns-wg/2021-November/003928.html Many members of the community expressed support for our proposal. Therefore, we are going to make these changes next week on Wednesday 20 April. We will lower the TTL of NS records to 86400 (1 day) and that of DS records to 3600 (1 hour). Note that the TTL of records imported from other Regional Internet Registries (RIRs) will not be affected. Those records will be imported with the TTLs as published by the origin RIR. Regards, Anand Buddhdev RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] Changes to Time-to-Live (TTL) values in reverse DNS zones
Hi Moritz, In the past 24 hours, we have not seen *any* increase in the query rate. I also checked the individual query rates for NS and DS records, and they are at the same levels as before the change. I'll check again tomorrow, after the original 2-day TTL expires, and report if I see any significant changes. Regards, Anand Buddhdev RIPE NCC On 21/04/2022 09:07, Moritz Müller via dns-wg wrote: Thank you Anand and team! Out of curiosity, do you notice an increase in load at your servers? -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] Changes to Time-to-Live (TTL) values in reverse DNS zones
Dear colleagues, It has been more than 48 hours since we lowered the TTLs. We are *not* observing any increase in query rates for NS or DS records. The rates are at the same levels as before the change (around 12-13k q/s for each of those types). Regards, Anand Buddhdev RIPE NCC On 21/04/2022 10:22, Anand Buddhdev wrote: I'll check again tomorrow, after the original 2-day TTL expires, and report if I see any significant changes. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
[dns-wg] RIPE NCC DNS operations update
Dear colleagues, On Tuesday 3 May, we performed a DNSSEC Key Signing Key (KSK) roll-over for all the zones that we maintain and sign. During this roll-over, we dropped the Zone Signing Keys (ZSKs), and began signing the zones with just their new KSKs. Technically, these keys are the same as any other KSKs, but since they sign the entire zone, and there's no ZSK, such KSKs are informally known as Combined Signing Keys (CSKs). We use Knot DNS for signing, and we enabled the "single-type-signing" option for our zones. We then triggered the key roll-over. Knot DNS waited and watched for DS record updates, and then gracefully introduced and withdrew keys by waiting for the appropriate amount of time as determined by Time To Live (TTL) values in the zones. On Monday 9 May, a new version of the RIPE Database was deployed. This version communicates with our new version of Zonemaster. When users submit domain objects to the RIPE Database, it submits a pre-delegation check to Zonemaster, and only allows the update if Zonemaster returns a result without any errors. This new version of Zonemaster has several bug fixes, improved tests, and most importantly, support for the newest DNSSEC algorithms, algorithm 15 (ED25519) and algorithm 16 (ED448). Regards, Anand Buddhdev RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] RIPE NCC DNS operations update
On 11/05/2022 14:07, Jim Reid wrote: Hi Jim, Many thanks for the update Anand. Could you give a bit more detail on why you decided to dump the ZSKs? Was it just a matter of having fewer keys to manage and fewer moving parts that could break? Managing keys isn't an issue, since it is all automated by the signer. Our main reason is that we do not have separate storage for the KSKs and ZSKs. They were all stored together on the signer. Additionally, our ECDSA KSKs and ZSKs were of the same size. Therefore, there is no additional protection offered by separating them, and so it is reasonable to use a CSK. Regards, Anand Buddhdev RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
Re: [dns-wg] Reverse problem Delegation 153.109
Hello Thierry, The 153.in-addr.arpa zone is managed by APNIC, not ARIN. I am able to look up the SOA record of 109.153.in-addr.arpa: % dig +short 109.153.in-addr.arpa soa dns1.vsnet.ch. root.dns1.vsnet.ch. 2022081000 3600 1800 1209600 3600 If you have more a specific on-going problem, please send email to d...@ripe.net, with the details of the problem, and we will be happy to help you. Regards, Anand Buddhdev RIPE NCC On 25/08/2022 09:23, Thierry Bagnoud wrote: Hi, do you have problem with reverse delegations (subnet 153.109.0.0/16) or it's a problem for ARIN ? Thanks for your response. VSnet -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
[dns-wg] Sunsetting ns.ripe.net - Final Cleanup - Wednesday, 15 January
Dear colleagues, On Wednesday 15 January, we'll be moving on to the final phase of removing our secondary DNS service for LIRs (ns.ripe.net) and updating all associated objects in the RIPE Database. This update will remove the "nserver: ns.ripe.net" attribute from them. I am happy to report that 93% of the zones have been updated and stopped using ns.ripe.net as a secondary name server. The remaining zones that have not been updated will not be affected because they will have at least one working name server after this update. Therefore, we do not expect the DNS resolution of these zones to fail. The full sunsetting plan, published last year, is available on RIPE Labs: https://labs.ripe.net/author/anandb/retiring-nsripenet/ Regards, Anand Buddhdev - To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/dns-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
[dns-wg] Re: Sunsetting ns.ripe.net - Final Cleanup - Wednesday, 15 January
Dear colleagues, This work is complete. Regards, Anand Buddhdev RIPE NCC On Tue, 14 Jan 2025 at 09:59, Anand Buddhdev wrote: > Dear colleagues, > > On Wednesday 15 January, we'll be moving on to the final phase of removing > our secondary DNS service for LIRs (ns.ripe.net) and updating all > associated objects in the RIPE Database. This update will remove the > "nserver: ns.ripe.net" attribute from them. > > I am happy to report that 93% of the zones have been updated and stopped > using ns.ripe.net as a secondary name server. The remaining zones that > have not been updated will not be affected because they will have at least > one working name server after this update. Therefore, we do not expect the > DNS resolution of these zones to fail. > > The full sunsetting plan, published last year, is available on RIPE Labs: > https://labs.ripe.net/author/anandb/retiring-nsripenet/ > > Regards, > Anand Buddhdev > - To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/dns-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
[dns-wg] Re: Sunsetting ns.ripe.net - Final Cleanup - Wednesday, 15 January
Hi Jeroen, Our name servers continue to record some statistics relating to "ns.ripe.net". There are still queries coming to its IP addresses, but this query volume is less than 1% of the total query rate. These queries are likely caused by 345 zones, which still have our name server in the NS records at the zone's apex. DNS resolvers that query our name server are now getting NOERROR responses, with an empty answer section, and the zone's other name servers in the authority section (a referral). Most DNS resolvers are used to dealing with this kind of breakage, and will try the other name servers. Tomorrow, we will drop all the address records of "ns.ripe.net", and that should stop most of the queries. As you have noted, there may still be some queries, either caused by in-zone names for the addresses of our server, or just other random queries. Unfortunately, we do not have the resources to setup another IP address for this name server and capture the traffic. We expect the volume to be very low, and not worth all the extra work of capturing the traffic. In the early days of this project, we sent the notification emails with a bitbucket sender address, so we did not see the bounces. In the last 2 notifications in November and December 2024, we changed the sender address that could see the bounces. We sent the email to over 1000 addresses, and there were around 100 bounces. In a small number of cases, all emails sent to a zone's contacts bounced. Regards, Anand Buddhdev RIPE NCC On Tue, 14 Jan 2025 at 10:13, Jeroen Massar wrote: > > > On 14 Jan 2025, at 09:59, Anand Buddhdev wrote: > > > > Dear colleagues, > > > > On Wednesday 15 January, we'll be moving on to the final phase of > removing our secondary DNS service for LIRs (ns.ripe.net) and updating > all associated objects in the RIPE Database. This update will remove the > "nserver: ns.ripe.net" attribute from them. > > > > I am happy to report that 93% of the zones have been updated and stopped > using ns.ripe.net as a secondary name server. The remaining zones that > have not been updated will not be affected because they will have at least > one working name server after this update. Therefore, we do not expect the > DNS resolution of these zones to fail. > > > Hi Anand, > > After you remove the nserver entry in WHOIS, will you do a bit of dumping > of at least the domains that are still attempted to be resolved through > ns.ripe.net <http://ns.ripe.net/> to have a small overview of the amount > of domains and amount of queries that are still flowing there. > > Before shutting down / removing the label of ns.ripe.net < > http://ns.ripe.net/> another experiment that one could do is to change > the IP of ns.ripe.net <http://ns.ripe.net/> to a distinct one, one then > either should see queries follow to that new IP (thus them having a NS of > ns.ripe.net <http://ns.ripe.net/>) or staying on the old IP (thus them > using a different name in the NS). > > Noting that the group that is using the IP 'directly' (or well, outside of > the ns.ripe.net <http://ns.ripe.net/> name) will cause those queries to > keep on going to your IP, and when you shutdown that IP it will just mean > ICMP traffic and retries... > > For the ones using ns.ripe.net <http://ns.ripe.net/>, they will keep on > trying to resolve ns.ripe.net <http://ns.ripe.net/> but at least if you > put a long TTL on the NXDOMAIN it should be decently cached and thus not > impact your infra too much. > > > Also, as there are contacts in the WHOIS entry, and you did an effort to > contact the owners, can you state what the response rate was, also how many > of the contacts bounced? Were they focussed on a few LIRs or spread out, > old records or any other insights. Could be a good way to see how 'correct' > the data in WHOIS actually is... > > > > Nevertheless good luck! (especially in the hope that the remaining query > rate is low and no incidents too of course :) ) > > > Regards, > Jeroen > > - To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/dns-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
