Re: [dns-operations] COM zone operational announcement: DNSSEC algorithm rollover
--- Begin Message --- Verisign is pleased to announce that an algorithm 13 (ECDSA) DS record has been published for the COM zone, and the algorithm 8 record has been removed. Over the next few days, the algorithm 8 DNSKEY records will be removed from the COM zone, followed by the removal of algorithm 8 signatures. We continue to expect no operational impacts for end users, but please feel free to reach out to us with concerns or any observations of anomalous behavior related to this algorithm rollover. DW --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Root zone operational announcement: introducing ZONEMD for the root zone
--- Begin Message --- I’m happy to announce that the second phase of ZONEMD deployment for the root zone is now complete. As of serial 2023120602, the hash algorithm field is set to 1: ;; ANSWER SECTION: . 86400 IN ZONEMD 2023120602 1 1 9E877AB7584FF83F738D3F51CC914AF396741B7A49E50D0C9ED9BA05 ACA08FC9B62A56673D2D93D5720E4DD505733932 DW > On Sep 21, 2023, at 8:04 AM, Wessels, Duane wrote: > > This work is now complete and as of approximately 13:20 UTC today all DNS > root servers have begun serving a root zone that includes a ZONEMD record, > with a private use algorithm number. > > On December 6th we plan to change the root zone ZONEMD record to the SHA384 > algorithm number, at which time it will become fully verifiable. > > > DW > >> On Sep 12, 2023, at 2:44 PM, Wessels, Duane via dns-operations >> wrote: >> >> >> >> Verisign and ICANN were originally planning to enable ZONEMD for >> the root zone tomorrow, September 13th. During a deployment to the >> operational testing environment, we discovered a minor issue. As >> a result, we, in cooperation with ICANN, have decided to postpone >> the production deployment of ZONEMD until next week, on September >> 21st. >> >> DW > --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] COM zone operational announcement: DNSSEC algorithm rollover
--- Begin Message --- Verisign will soon begin the transition to DNSSEC algorithm 13 (ECDSA) for the COM zone. Over the next few days, algorithm 13 signatures will start to appear in the zone, followed by the algorithm 13 DNSKEY records. We expect the DS record for the COM zone to change from algorithm 8 to algorithm 13 on or around December 7. Additional information can be found at our blog post and DNS-OARC presentation URLs below: https://blog.verisign.com/security/dnssec-algorithm-update/ https://indico.dns-oarc.net/event/47/contributions/1012/ We expect no operational impacts for end users, but please feel free to reach out to us with concerns or any observations of anomalous behavior related to this algorithm rollover. DW --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] NET zone operational announcement: DNSSEC algorithm rollover
--- Begin Message --- Verisign is pleased to announce that an algorithm 13 (ECDSA) DS record has been published for the NET zone, and the algorithm 8 record has been removed. Over the next few days, the algorithm 8 DNSKEY records will be removed from the NET zone, followed by the removal of algorithm 8 signatures. We continue to expect no operational impacts for end users, but please feel free to reach out to us with concerns or any observations of anomalous behavior related to this algorithm rollover. DW --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] NET zone operational announcement: DNSSEC algorithm rollover
--- Begin Message --- Verisign will soon begin the transition to DNSSEC algorithm 13 (ECDSA) for the NET zone. Over the next few days, algorithm 13 signatures will start to appear in the zone, followed by the algorithm 13 DNSKEY records. We expect the DS record for the NET zone to change from algorithm 8 to algorithm 13 on or around November 8th. Additional information can be found at our blog post and DNS-OARC presentation URLs below: https://blog.verisign.com/security/dnssec-algorithm-update/ https://indico.dns-oarc.net/event/47/contributions/1012/ We expect no operational impacts for end users, but please feel free to reach out to us with concerns or any observations of anomalous behavior related to this algorithm rollover. DW --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Root zone operational announcement: introducing ZONEMD for the root zone
--- Begin Message --- This work is now complete and as of approximately 13:20 UTC today all DNS root servers have begun serving a root zone that includes a ZONEMD record, with a private use algorithm number. On December 6th we plan to change the root zone ZONEMD record to the SHA384 algorithm number, at which time it will become fully verifiable. DW > On Sep 12, 2023, at 2:44 PM, Wessels, Duane via dns-operations > wrote: > > > > Verisign and ICANN were originally planning to enable ZONEMD for > the root zone tomorrow, September 13th. During a deployment to the > operational testing environment, we discovered a minor issue. As > a result, we, in cooperation with ICANN, have decided to postpone > the production deployment of ZONEMD until next week, on September > 21st. > > DW --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Root zone operational announcement: introducing ZONEMD for the root zone
--- Begin Message --- Verisign and ICANN were originally planning to enable ZONEMD for the root zone tomorrow, September 13th. During a deployment to the operational testing environment, we discovered a minor issue. As a result, we, in cooperation with ICANN, have decided to postpone the production deployment of ZONEMD until next week, on September 21st. DW --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] EDU zone operational announcement: DNSSEC algorithm rollover
--- Begin Message --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Verisign is pleased to announce that an algorithm 13 (ECDSA) DS record has been published for the EDU zone, and the algorithm 8 record has been removed. Over the next few days, the algorithm 8 DNSKEY records will be removed from the EDU zone, followed by the removal of algorithm 8 signatures. We continue to expect no operational impacts for end users, but please feel free to reach out to us with concerns or any observations of anomalous behavior related to this algorithm rollover. DW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJlAIwcAAoJEGyZpGmowJiNEj4H/R07bC4outa2znVIh7BIsolu mamlG2+NlOBmdAOTzk8vdmoUMy11RHeG0W+6o6oQS9gALUgj4shxPF5z+Je0R6Us Y54HDnE4mi1KAGKOtg/AE5RYCZeA/rhLk/qxRnLiUBtlmuRwMpjkJ5k+viCEFVX+ IyZPWEJyDSC8bFx4LThYt7AP093r74vjKHa2wMffa+3VHZgrEpHReL6Na149+u3L Idb1In9cCs6nYFp/DuMopdVHy3EqK6psPSCt7jCG27qAtM4+ormsCPYYo4KI7RUo lF7X2SdDmVUfoL4lzrLUzl7MFBxJxNYCt/yPvN/VBLw2Yby2AhPHVQt7lpjIQXo= =/uAl -END PGP SIGNATURE- --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] EDU zone operational announcement: DNSSEC algorithm rollover
--- Begin Message --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Verisign will soon begin the transition to DNSSEC algorithm 13 (ECDSA) for the EDU zone. Over the next few days, algorithm 13 signatures will start to appear in the zone, followed by the algorithm 13 DNSKEY records. We expect the DS record for the EDU zone to change from algorithm 8 to algorithm 13 between September 12-15. Additional information can be found at our blog post and DNS-OARC presentation URLs below: https://blog.verisign.com/security/dnssec-algorithm-update/ https://indico.dns-oarc.net/event/47/contributions/1012/ We expect no operational impacts for end users, but please feel free to reach out to us with concerns or any observations of anomalous behavior related to this algorithm rollover. DW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJk90tSAAoJEGyZpGmowJiNynsIAIWBx6Gc8CyOl0pcr65a3aUh FnrrteufEs1KvNk+HtexDs8opUGz8sKf4zG/ABj4NtTQFRwsvD/nxh8q+fnu4Vci niSPbJLZcadY+344FioGNE4/jE28jKmItx7fFmTBoaBcF5iy1aS5xSh4vOA6fcSy snJeYd6VsnrezK6IujgmiqAg7iLwl+YHvPnu8lJuXEpUPqBmO/EEHZPn7oEps8Xf A8duusfKIvP6zrIF0vnnqwS0TgUpTdam5MGtVAkv+JUlpzRmqAYNcQd872nYUVIp 5qZ1R+pjHsngwe+8pf/LQtpYwKjaiP06CUbZH8hlg3ioDWSLEAjs0NEgb45Wmhw= =Wi2m -END PGP SIGNATURE- --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Root zone operational announcement: introducing ZONEMD for the root zone
--- Begin Message --- Hi Otto, I see now. My email had a typo / mistake. Sept 6th should be Sept 13th. DW > On Jul 21, 2023, at 11:48 PM, Otto Moerbeek wrote: > > Thanks, but I'm stilll puzzled, > > According to your original post the publishing of the downloadable > root zone with a ZONEMD record starts at Sept 6. It is not clear to me > what Hash Algorithm it will use on that date, as the date is before > Sept 13. > > -Otto > > > On Sat, Jul 22, 2023 at 05:04:53AM +, Wessels, Duane wrote: > >> Hi Otto, >> >> From 2023-09-13 to 2023-12-06 the Hash Algorithm field of the ZONEMD record >> will be set to 241 (the first value in the private use range). >> >> On 2023-12-06 we will change it to Hash Algorithm 1, which is SHA-384. >> >> DW >> >> >>> On Jul 20, 2023, at 11:02 PM, Otto Moerbeek wrote: >>> >>> Hello, >>> >>> thanks you for working on this! >>> >>> From the description it is not clear what the Hash Algorithm of the >>> ZONEMD record included in the downloadable zone file will be per Sept >>> 6th. Will this ZONEMD record also use a private algorihtm and switch >>> to SHA-384 at a later moment? If so, when? >>> >>> Thanks, >>> >>> -Otto >>> >>> On Wed, Jul 19, 2023 at 04:10:25PM +, Wessels, Duane via dns-operations >>> wrote: >>> >>>> Date: Wed, 19 Jul 2023 16:10:25 + >>>> From: "Wessels, Duane" >>>> To: Andy Smith via dns-operations >>>> Subject: Root zone operational announcement: introducing ZONEMD for the >>>> root zone >>>> >>>> I am pleased to announce that Message Digests for DNS Zones, also known as >>>> ZONEMD, will be added to the root zone later this year. This feature, >>>> specified in RFC 8976, adds cryptographic data protections to the zone as >>>> a whole, allowing the recipient to verify the authenticity of the zone’s >>>> contents. >>>> >>>> ZONEMD will be added to the root zone using a phased approach. On >>>> September 13, 2023, a ZONEMD record will make its first appearance in the >>>> root zone. At this time the Hash Algorithm field will be set to a private >>>> use algorithm number, making the ZONEMD record deliberately unverifiable. >>>> >>>> On December 6, 2023, the ZONEMD record will be published with the SHA-384 >>>> Hash Algorithm, thereby making it verifiable. >>>> >>>> We expect no operational impacts for end users. ZONEMD does not affect >>>> root zone queries and responses. The root server operators have agreed to >>>> not alter their zone ingestion processes for at least a year after ZONEMD >>>> is first introduced. >>>> >>>> Anyone that downloads the root zone file from >>>> http://secure-web.cisco.com/13zHe0PSUNNCJBM54qbqfvmLTQg1GfbkWLEKyj11uJKxr0cKwV4m8nmumCACCRc4TgWQiGSCfSGuab49nQ6t190PzZtdsghnWGBape45q7yscRuI72y4rVA9FKtruoIUJQOYRD6hxmpgoa0lss35RtP8oNP419dfbfY8ihpz2HiszKMFbjYaocQQtWkQRKyEoPgOCXuUYIOZH5HpdhzIBT3zEwLzflnqL6eR3vOHzkuaVR_loD-7WM4o8M-F3-mIdQ6_IU5BkH_ZZ8ZDDpoXPLuPtbA4-cR5rjj38JhobF0bvH1PXHByckj2a54_02zMz/http%3A%2F%2Fwww.internic.net >>>> or rs.internic.net should be aware that it will include the new ZONEMD >>>> resource record in its native presentation format starting on September >>>> 6th. >>>> >>>> Please feel free to follow up with any questions or concerns. >>>> >>>> References and further reading: >>>> >>>> [1] RFC 8976: “Message Digest for DNS Zones”, >>>> https://secure-web.cisco.com/1XacvzAe3KCmD305ieQ292ovYQ65x-D9JyNQdhLvttzBjgk_MG_6FPETg8ekoItXo6qHCk148b0VNJDrijtKvnuhj8UrvfHd7HBzGvj4F4ggvNm8WmQRjo5OBRwa5Oq9zVIsC8y89tmSj2huHT0eluDy04igbLGg3IfodIUxONEjurDcYsu6e9cKU0ovYEEg-lW5fWr5WHv3k35aCnqYXpmej0QhYGklxxdrPwiuQCW49VFfxdg_MFcumelbQdTeOIBwvSoHdjUP3Cy6h-jFkMLRcMch-gtVEooh55H6OUK7QqXX-lgDEjF1Y7kfAR5xz/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8976 >>>> [2] Root Server Operators Statement on adding ZONEMD to the root zone, >>>> https://secure-web.cisco.com/1csi7pcWnfEk3MLCMTDpMIepUdApvVU-b-tnpRX8PnOKn9nNkbrgZcZH62k21N7DUG8idMbIuxr-PBwCg3jX0SY2AegsYwVyMTfeARtd1s8147gy-akpwRWMoYlEgiJeWr4cw-JDy68YPNrnP0kNTeaWXhUsXID92S4aPLSCsW1xsNRaXBxRoeLaTw4BJnfQXdKOWbCUPpgIKwolYYobY4I0A3vwcYS-PnVIxOcaCMe3k8haS7ZzAP0Udcs1prvi9xIIdE3FL1lXocAMOJeZiNlri6V4KDKge_hGAMm32TFeDk5oC_eoM68noNMSAjTCI/https%3A%2F%2Froot-servers.org%2Fmedia%2Fnews%2F2022-08-Statement_on
Re: [dns-operations] Root zone operational announcement: introducing ZONEMD for the root zone
--- Begin Message --- Hi Otto, >From 2023-09-13 to 2023-12-06 the Hash Algorithm field of the ZONEMD record >will be set to 241 (the first value in the private use range). On 2023-12-06 we will change it to Hash Algorithm 1, which is SHA-384. DW > On Jul 20, 2023, at 11:02 PM, Otto Moerbeek wrote: > > Hello, > > thanks you for working on this! > > From the description it is not clear what the Hash Algorithm of the > ZONEMD record included in the downloadable zone file will be per Sept > 6th. Will this ZONEMD record also use a private algorihtm and switch > to SHA-384 at a later moment? If so, when? > > Thanks, > > -Otto > > On Wed, Jul 19, 2023 at 04:10:25PM +, Wessels, Duane via dns-operations > wrote: > >> Date: Wed, 19 Jul 2023 16:10:25 + >> From: "Wessels, Duane" >> To: Andy Smith via dns-operations >> Subject: Root zone operational announcement: introducing ZONEMD for the >> root zone >> >> I am pleased to announce that Message Digests for DNS Zones, also known as >> ZONEMD, will be added to the root zone later this year. This feature, >> specified in RFC 8976, adds cryptographic data protections to the zone as a >> whole, allowing the recipient to verify the authenticity of the zone’s >> contents. >> >> ZONEMD will be added to the root zone using a phased approach. On September >> 13, 2023, a ZONEMD record will make its first appearance in the root zone. >> At this time the Hash Algorithm field will be set to a private use algorithm >> number, making the ZONEMD record deliberately unverifiable. >> >> On December 6, 2023, the ZONEMD record will be published with the SHA-384 >> Hash Algorithm, thereby making it verifiable. >> >> We expect no operational impacts for end users. ZONEMD does not affect root >> zone queries and responses. The root server operators have agreed to not >> alter their zone ingestion processes for at least a year after ZONEMD is >> first introduced. >> >> Anyone that downloads the root zone file from >> http://secure-web.cisco.com/13zHe0PSUNNCJBM54qbqfvmLTQg1GfbkWLEKyj11uJKxr0cKwV4m8nmumCACCRc4TgWQiGSCfSGuab49nQ6t190PzZtdsghnWGBape45q7yscRuI72y4rVA9FKtruoIUJQOYRD6hxmpgoa0lss35RtP8oNP419dfbfY8ihpz2HiszKMFbjYaocQQtWkQRKyEoPgOCXuUYIOZH5HpdhzIBT3zEwLzflnqL6eR3vOHzkuaVR_loD-7WM4o8M-F3-mIdQ6_IU5BkH_ZZ8ZDDpoXPLuPtbA4-cR5rjj38JhobF0bvH1PXHByckj2a54_02zMz/http%3A%2F%2Fwww.internic.net >> or rs.internic.net should be aware that it will include the new ZONEMD >> resource record in its native presentation format starting on September 6th. >> >> Please feel free to follow up with any questions or concerns. >> >> References and further reading: >> >> [1] RFC 8976: “Message Digest for DNS Zones”, >> https://secure-web.cisco.com/1XacvzAe3KCmD305ieQ292ovYQ65x-D9JyNQdhLvttzBjgk_MG_6FPETg8ekoItXo6qHCk148b0VNJDrijtKvnuhj8UrvfHd7HBzGvj4F4ggvNm8WmQRjo5OBRwa5Oq9zVIsC8y89tmSj2huHT0eluDy04igbLGg3IfodIUxONEjurDcYsu6e9cKU0ovYEEg-lW5fWr5WHv3k35aCnqYXpmej0QhYGklxxdrPwiuQCW49VFfxdg_MFcumelbQdTeOIBwvSoHdjUP3Cy6h-jFkMLRcMch-gtVEooh55H6OUK7QqXX-lgDEjF1Y7kfAR5xz/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8976 >> [2] Root Server Operators Statement on adding ZONEMD to the root zone, >> https://secure-web.cisco.com/1csi7pcWnfEk3MLCMTDpMIepUdApvVU-b-tnpRX8PnOKn9nNkbrgZcZH62k21N7DUG8idMbIuxr-PBwCg3jX0SY2AegsYwVyMTfeARtd1s8147gy-akpwRWMoYlEgiJeWr4cw-JDy68YPNrnP0kNTeaWXhUsXID92S4aPLSCsW1xsNRaXBxRoeLaTw4BJnfQXdKOWbCUPpgIKwolYYobY4I0A3vwcYS-PnVIxOcaCMe3k8haS7ZzAP0Udcs1prvi9xIIdE3FL1lXocAMOJeZiNlri6V4KDKge_hGAMm32TFeDk5oC_eoM68noNMSAjTCI/https%3A%2F%2Froot-servers.org%2Fmedia%2Fnews%2F2022-08-Statement_on_ZONEMD.pdf >> [3] RZERC003: “Adding Zone Data Protections to the Root Zone”, >> https://secure-web.cisco.com/12BOkeZeIXXEc8bHPskskIPYYEB5j6atSHInZVGViHpuEsWFd3i3ORxxQF3d-hBwCUZsL9QLcUDwYl0JO1OMo_1bDLdiEr6SE4gT85zTFYDCN-Y3z0bBPvh6FYjzXltQy1zQY4L4-Z3BrnqpukWZRGIr3SkjWMkw8638PhkW8B41dLIS-IHIwqzAAvoY3lvNNWBJ-Eqon1isiSlBcfFrjJmbexUozG_3TRgPeaPMfzWUYfAAXeJ3wuOe3ym7K6QjqtXdi1KbHhX8_0K0hKVLNAoQ3kqKE8jzExHxgqEJtBrAU-pw_Zd23n-_lt66FBC13/https%3A%2F%2Fwww.icann.org%2Fuploads%2Fckeditor%2Frzerc-003-en.pdf >> [4] Verisign Blog: “Adding ZONEMD Protections to the Root Zone”, >> https://blog.verisign.com/security/root-zone-zonemd/ >> [5] APNIC Ping Podcast episode “Adding ZONEMD protections to the root zone”, >> https://secure-web.cisco.com/18iOqVl2cAOdTphmSsXOmBUjIRxkAH7WRakcRt_PS4P13-NQr-6u5XqSCjbCDss9R8Zm5S3akf5o1AEq5ib0ezfpX-l0Ev3ZXbLj2p-WCMQHti2hedZNF99ok0C33OrnviXVDn5Qnrqa7BnBIP9ec38evs3V4ucParLvxRoMmYIY9lA_-GuAvcWpDTLphlhWTXXbV7LNUzprP0MOKGCw67sbVz5VX98v7N1bGZuGQrft-PzTS_P_oa9i2NA8ZI4niQK7xED4v8dKK4NXNyTRJjvBEPGQ-D9B0oVzm
[dns-operations] Root zone operational announcement: introducing ZONEMD for the root zone
--- Begin Message --- I am pleased to announce that Message Digests for DNS Zones, also known as ZONEMD, will be added to the root zone later this year. This feature, specified in RFC 8976, adds cryptographic data protections to the zone as a whole, allowing the recipient to verify the authenticity of the zone’s contents. ZONEMD will be added to the root zone using a phased approach. On September 13, 2023, a ZONEMD record will make its first appearance in the root zone. At this time the Hash Algorithm field will be set to a private use algorithm number, making the ZONEMD record deliberately unverifiable. On December 6, 2023, the ZONEMD record will be published with the SHA-384 Hash Algorithm, thereby making it verifiable. We expect no operational impacts for end users. ZONEMD does not affect root zone queries and responses. The root server operators have agreed to not alter their zone ingestion processes for at least a year after ZONEMD is first introduced. Anyone that downloads the root zone file from www.internic.net or rs.internic.net should be aware that it will include the new ZONEMD resource record in its native presentation format starting on September 6th. Please feel free to follow up with any questions or concerns. References and further reading: [1] RFC 8976: “Message Digest for DNS Zones”, https://www.rfc-editor.org/rfc/rfc8976 [2] Root Server Operators Statement on adding ZONEMD to the root zone, https://root-servers.org/media/news/2022-08-Statement_on_ZONEMD.pdf [3] RZERC003: “Adding Zone Data Protections to the Root Zone”, https://www.icann.org/uploads/ckeditor/rzerc-003-en.pdf [4] Verisign Blog: “Adding ZONEMD Protections to the Root Zone”, https://blog.verisign.com/security/root-zone-zonemd/ [5] APNIC Ping Podcast episode “Adding ZONEMD protections to the root zone”, https://blubrry.com/ping_podcast/108940688/adding-zonemd-protections-to-the-root-zone/ DW --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region
--- Begin Message --- All, Last week, during a migration of one of our DNS resolution sites in Singapore, from one provider to another, we unexpectedly lost management access and the ability to deliver changes and DNS updates to the site. Following our standard procedure, we disabled all transit links to the affected site. Unfortunately, a peering router remained active, which was not immediately obvious to our teams due to the lack of connectivity there. Over the weekend, this caused an issue that may have affected the ability of some internet users in the region to reach some .com and .net domains, as DNSSEC signatures on the site began expiring. The issue was resolved by powering off the site’s peering router, causing the anycast route announcement to be withdrawn and traffic to be directed to other sites. We are updating our processes and procedures and will work to prevent such issues from recurring in the future. The Singapore site is part of a highly redundant constellation of more than 200 sites that make up our global network. This issue had no effect on the core resolution of .com and .net resolution globally. We apologize to those who may have been affected. DW --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] What is the reason of J-Root doesn't serve the arpa zone?
--- Begin Message --- > On Dec 3, 2021, at 7:05 PM, Paul Vixie via dns-operations > wrote: > > > 2870 was wrong in this respect, and should be revised to allow ARPA. > > vixie Well, it sort of was. 2870 was updated by 7720, which notes that the operational requirements are given in RSSAC001, which in turn says: Root Servers also serve additional zones. All Root Servers are authoritative for the ROOT-SERVERS.NET zone and currently twelve of the thirteen are authoritative for the ARPA zone. DW --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] What is the reason of J-Root doesn't serve the arpa zone?
--- Begin Message --- Thanks for the opportunity to add some clarity around J-root and the arpa zone. Here is a brief history of events that can provide some context: In the 1996 time frame there were 9 root servers: A through I. In addition to the root zone, they also served a number of TLDs, including com, net, org, and arpa. It is important to understand that when Jon Postel expanded the root servers in 1997 to include J, K, L, and M, the new ones only served the root and root-servers.net zones. In June 2000 RFC 2870 was published with section 2.5 stating: [root servers] also MUST NOT provide secondary service for any zones other than the root and root-servers.net zones. Around this same time (+/- 1 year) the first nine root servers stopped serving com, net, and org, but not arpa. In November 2002 K, L, and M were added to the NS list for arpa, but J was not. We can't speak to decisions made by the other operators, but Verisign chose not to put j.root-servers.net in the NS set based on the language of RFC 2870. DW > On Dec 2, 2021, at 10:08 PM, Yasuhiro Orange Morishita / 森下泰宏 > wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > Hi, > > Now I'm writing an article for Japanese people that introduces the > IETF's recent DNS-related activities, and I have a question about the > current "arpa" zone. > > RFC 9120 says: > > Historically, the "arpa" zone has been hosted on almost all of the > root nameservers (NSs), and [RFC3172] envisages the "arpa" domain to > be "sufficiently critical that the operational requirements for the > root servers apply to the operational requirements of the "arpa" > servers". To date, this has been implemented by serving the "arpa" > domain directly on a subset of the root server infrastructure. > > Yes, it is "almost all", not "all". Currently, the "arpa" zone has > been hosted on 12 root servers, except to J-Root. > > Probably, this is a part of the "Historically", but I want to know why. > > -- Orange > > -- > Yasuhiro 'Orange' Morishita > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://secure-web.cisco.com/1UPWQoE5QZLgSrY5t3Pk7jXYfTh275uVJ8x1xZqeVty8lc-Yaa_VRvU_qscPHa63slHPejQEwqAeGcHQqGLFc8cxEazngQZbzGtRJs-kpGh1Ix2ImAu6_Db9Ei0BEH7ExEYpVkdqdAdQoOhIczU-CA_RzUA5Q2ZcnDm3-NF07D4OKwhGGmE81IOScm_VxTGW5pUfkPp1xa7_aUn26-u0HJ6CCRP33Yi1TAEz0TCAxZtMHo4t0TVlG9rqLS6IBN0is8o8vD9eZMN5UAsokuWH72Q/https%3A%2F%2Flists.dns-oarc.net%2Fmailman%2Flistinfo%2Fdns-operations > --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Lot's of TXT queries from Google
--- Begin Message --- Moritz, I can't explain the TXT queries, but the NS queries seem to be Google's method of doing qname minimization, with an added nonce value. See https://indico.dns-oarc.net/event/39/contributions/864/ and https://developers.google.com/speed/public-dns/docs/security?hl=en#nonce_prefixes DW > On Oct 7, 2021, at 4:50 AM, Moritz Müller via dns-operations > wrote: > > > From: Moritz Müller > Subject: Lot's of TXT queries from Google > Date: October 7, 2021 at 4:50:21 AM PDT > To: > > > Hi, > > For the second time in a few weeks we noticed a significant increase in > queries for NS and TXT records at our .nl name servers, originating almost > exclusively from the Public DNS resolvers of Google > Did someone else noticed something similar or has an explanation? > > In comparison to beginning of September, the number of NS queries increased 2 > fold and the number of TXT queries almost 6 fold. > At some point, 25% of all queries to our name servers for .nl where for TXT > record. > > The resolvers query either for a domain name following the pattern > _dmarc.foo.nl or default._domainkey.foo.nl. > Where foo is a random string, 12 characters long. > > Examples are: > _dmarc.mdvlxtagogij.nl. > default._domainkey.vppj4svmbclt.nl. > > The queried second level domain names are not registered and queries for the > same domain name are repeated 3 to 5 times. > At some point, 80% of all TXT queries from google had these patterns, 36% of > all queries from Google resolvers. > > The queries started ramping up around 2021-09-05 and reached their peak at > 2021-09-18. They never reached a concerning level, but we first noticed them > because our machine processing the incoming PCAP files couldn’t cope anymore. > > We assume that this is likely not an attack but some tests/measurements, > which got a bit out of hand. But since we don’t see the origin of the queries > behind the Google resolvers, we’re not sure to whom to reach out. > > — > Moritz > > — > SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM > T +31 (0)26 352 55 00 > moritz.mul...@sidn.nl | www.sidn.nl > pgp key: https://pgp.mit.edu/pks/lookup?op=get=0x0AF8922B1659B448 > > > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://secure-web.cisco.com/1j0tUWdtkXBzH95d3NJuJ85PVsyNQjXNWdO32ER-v_iT_UjT59vzGAmM02xy_33dtoTHStrRux8cAZ5IJLBUBd0AnsjCN0CSNyR6a3HYO9F4zJlt7_KL2YK4NW13MBo9xJN5dqR6R0rKlERPBOlMfhxmZBw7tIJHwfTHN6lsPwpxyH2XxqTPH9HQTFkJ9A84Bq6Uhc9MQjU-TlN6ef9LLrCbsG7abZ9xqHMbBQLToaQcMLkmMTLbepYwv1EZH_Bn7UZUhfEVyND7-IIZxugF3ow/https%3A%2F%2Flists.dns-oarc.net%2Fmailman%2Flistinfo%2Fdns-operations smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] RRSIG expiry versus TTL
--- Begin Message --- > On Sep 5, 2021, at 9:08 AM, Matthew Richardson > wrote: > >> the RRSIG TTL should match the NS record TTL, but ..., the validating >> resolver does not care, and should not, about RRSIG TTL. So the >> difference between the expiration of the rrsig and the TTL shouldn't >> or doesn't impact the online services. > That may be true for validating recursive name servers, because the spec says the validator should use the minimum of the two TTLs if they differ. However, if there is a non-validating resolver (cache) in the resolution path then they can be cached differently and the wrong signatures could be returned to a client. DW smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Verisign won't delete obsolete glue records?
--- Begin Message --- > On Mar 2, 2021, at 12:10 PM, Doug Barton wrote: > > On 3/2/21 11:49 AM, Andrew Sullivan wrote: >> On Mon, Mar 01, 2021 at 04:35:47PM -0800, Doug Barton wrote: >>> >>> >>> Perhaps I didn't ask my question clearly enough. Let's take a delegation >>> for example.com to ns1.example.info and ns2.example.info. There will be no >>> host records at Verisign for those two names, right? >> If the registry uses both domain objects and host objects ... > > I think you missed my followup where I indicated that from what I can see, > Verisign is creating host objects for every host mentioned in a delegation > regardless of bailiwick, but not putting glue records into the zone where > they are not needed. Hi Doug, Verisign does not create these on its own, but rather requires the registrant to set at least one IP address on what the EPP RFC 5732 calls an "internal host." Any .COM or .NET host in the registry is considered an internal host. An internal host can be used as a delegating name server for any .COM or .NET domain in the registry. The delegation is made in the registry on the creation of a domain or an update of a domain. The host must exist prior to the delegation from a domain, so they must be set with the IP addresses to cover the case of an in-bailiwick name server. You said "but not putting glue records into the zone where they are not needed." The only time something like that would happen is for what is called orphan glue. As has been discussed on this list before, Verisign does not publish orphan glue records in the zone files you can get (e.g. via CZDS) but will include orphan glue records in DNS delegation responses when needed. But I don't think that's what's happening in your case. DW > > For peace of mind I would much rather see the IP addresses in those host > objects removed when they are not needed as glue, rather than being ignored, > since that reduces the chance of a spurious glue record being published > accidentally. > > Doug > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://secure-web.cisco.com/11YBI52gE988BTx9qH-YZJ5y3kkSasGz65vyjTzgs3vqRFY7nRoAyfkfxumG1bZPJotjwx4uuIjryH2_f8ueNVktf2X_rFnINGggkxbDxCA3Q0NreJNioDmaQpThWqEd49BUHiEjovZuDVKmAzbGVW1Ky5NolUVR-KMq4Qs-JhSSIZ7hQyTxFf-iwVJe6snj2oLUXSiDqfX2DSPEjtQkxA67-QfywcNTu_e6hvxvMa_Dl_xNgiwCu5J28JCNaZIr2_7o8VDqqoCjcINVEQFSiBg/https%3A%2F%2Flists.dns-oarc.net%2Fmailman%2Flistinfo%2Fdns-operations > smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Verisign won't delete obsolete glue records?
--- Begin Message --- > On Mar 1, 2021, at 4:01 PM, Jim Reid wrote: > > The original glue records will not be obsolete even though you believe they > are. There must be at least one other delegation in the .com registry which > references the nameserver object(s) for the glue record(s) you think are no > longer relevant. This would be my guess as well. You can use dns.coffee to find occurrences of this. For example: https://dns.coffee/nameservers/b.iana-servers.net DW smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Incorrect NSEC responses from Verisign root server instances
--- Begin Message --- On February 26, 2021 at ~1431 EST, Verisign was notified that some of its root server instances were returning incorrect responses for queries of type NSEC. We identified the subset of instances affected and took them out of service (as of ~1506 EST). The remainder of our systems are responding appropriately. The NSEC resource record is used in some DNSSEC-signed zones to provide proofs of non-existence. In the normal process of iterating and resolving domain names, validating recursive name servers do not send queries of type NSEC. However, an end-user of a recursive name server may generate NSEC queries using custom software or debugging tools, such as 'dig'. These queries are extremely rare and infrequent in nature and the normal internet user would be agnostic to this condition existing. The incorrect responses from Verisign's root server instances provided an empty owner name in the Authority section records of a delegation response to the NSEC query. The empty owner name corresponds to the root label. A recursive name server that processed one of these incorrect responses could change its cached root NS RRset, meaning that future queries to be resolved in the context of the root zone could be sent to incorrect names servers which are not authoritative for the root zone. Verisign is in the process of patching affected systems, and rolling out the new version, and bringing affected instances back into service in accordance with established operational procedures. Additionally, we expect this may bring some new attention to the way in which authoritative name servers respond to queries of type NSEC. Some implementations respond with referrals, while others respond with an NSEC RR in the Answer section. Verisign will be pleased to work with the community if there are ambiguities in the relevant RFCs (e.g. 4035) that would benefit from clarification, as current behavior beyond this subset of our name servers suggests. Thank you to David Kinzel of Shaw Communications for bringing this to our attention. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAABAgAGBQJgOaBzAAoJEGyZpGmowJiNJqoH/iQcOWk3eMBondU4qyWR8V+M sGj61eugKxsj5oTRx8kdDDYqCGxxnvdDZrHqxN5aQlVuXePfwuA3bxne+Mm7Oluo RH4lWfuLJntrIHD+AStxfthQZGUCUV/LwX/1wRje1+DbxoGUl5dStu/DV03ViNiO V7SQJf7yxeTtw3Hsb4zrTL/r/gLhy1lXeG9VzW1NIDrLCd1JJQ82WRvWr0YDSEBh PRHT6p89uzLzGnkAsmp0GlfZ1G5oia2Svc/YlKowbBG28Egmgmu5IrZcyXzltYgg oLi/YD3HWAxpIvDFEIPLLbbwLKOGowdleKUYlQXNhewkrsH282SyOaewyjGXQX4= =h364 -END PGP SIGNATURE- smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] anybody awake over at comcast.net?
--- Begin Message --- > On Feb 9, 2021, at 9:58 AM, Matthew Richardson > wrote: > > On Tue, 9 Feb 2021 16:43:20 +, Duane Wessels wrote:- > >> If you use Nagios or something compatible, there is this: >> >> http://secure-web.cisco.com/1ZWcEZ_A3D0HVUDh0W30HiqK06_fxVH7k6Y8MQ0xEkq1R7DisrP18NBN1e4yKETi4R0R3tKtYvbgbceXgcgJ9C21mjdIL9Y0Pi_Vi2A0Bec1tUqiBtCl2wuBuf4RT9Knwd995i-JtjkwjqGTjcDaMcEBN2Wd3J0kKflgMjk2Quq2zjxyDzHe1onv98qw0k-KwnjHmEXxC0KV139PzFEJNQuXFh0FvDW6UESHUbtewefOJN2wnn7lvU7iwPnTztW2X_FiaYT56yvFT9z4BFBcAwg/http%3A%2F%2Fdns.measurement-factory.com%2Ftools%2Fnagios-plugins%2Fcheck_zone_rrsig_expiration.html >> >> But it only checks one RR (default SOA) since it doesn't assume access to >> the whole zone. >> That would be a good upgrade, though, to have it axfr the zone and check >> everything. > > Are there any existing tools which would take a whole zonefile and check > the expirations? In a similar way to (for example) dnssec-verify from > Bind. YAZVS: Yet Another Zone Validation Script https://github.com/verisign/yazvs It is designed to also show changes between a new and current zone, but you can skip that part with the -x option. DW smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] anybody awake over at comcast.net?
--- Begin Message --- > On Feb 8, 2021, at 9:27 PM, Paul Vixie wrote: > > i expect i'll crib together some bourne shellack to check my whole signature > chains and warn me when there's less than 72 hours remaining in any validity > period. going into SERVFAIL like this is an operational risk i shouldn't take. If you use Nagios or something compatible, there is this: http://dns.measurement-factory.com/tools/nagios-plugins/check_zone_rrsig_expiration.html But it only checks one RR (default SOA) since it doesn't assume access to the whole zone. That would be a good upgrade, though, to have it axfr the zone and check everything. DW smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] anybody awake over at comcast.net?
--- Begin Message --- > On Feb 8, 2021, at 9:27 PM, Paul Vixie wrote: > > i expect i'll crib together some bourne shellack to check my whole signature > chains and warn me when there's less than 72 hours remaining in any validity > period. going into SERVFAIL like this is an operational risk i shouldn't take. If you use Nagios or something compatible, there is this: http://dns.measurement-factory.com/tools/nagios-plugins/check_zone_rrsig_expiration.html But it only checks one RR (default SOA) since it doesn't assume access to the whole zone. That would be a good upgrade, though, to have it axfr the zone and check everything. DW smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] https://secure-web.cisco.com/1ZjyzJskkYQq7sVMAaORAQUNbtLnCDdiphJXoIUgaA7_oFL6tHC8iV070aZrCZfTyULjhkVi3xJfW5opBdNn-YVZVvneE8CazN4a3cBB_5D0ERlfp-D-9kGVsbAT_XzThiOOKiL1K02Z_t969017Ug
--- Begin Message --- > On Nov 9, 2020, at 11:44 AM, Warren Kumari wrote: > > Erm, what sort of glitch? (seems to work for me - wondering if it is > transient, or ...) It was easily fixed. The glitch was a bug in the backend script such that every request led to an "Internal Server Error". DW smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] https://secure-web.cisco.com/1QObC8qh53iR__TlqRff59E5B8JFiAV2VUGirT2kdLKo0yz-mYw9xle11YYObM5lxuamt1wUA26DRNfoRK6v8IXYl9zUeX7VkWIaBof6KLCFjBHsfqxnMrN2Muac7SkNMlWXCdqDvPKJTAORrYe1s9
--- Begin Message --- Hi Calvin, you can poke me. DW > On Nov 9, 2020, at 1:05 AM, Calvin Browne wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > > > Hi Guys, > > > > seems https://trans-trust.verisignlabs.com/ has developed a glitch - anyone > know who to poke (with thanks of course). > > > > regards > > > > --Calvin > > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://secure-web.cisco.com/1FMqJkV7gNbINx1vDfXazKCpr3zOuXT9N9057UPMBMfmLvhPO6UDpMKy56BJCPP6QvU4kTfnSpRBQiMSWbbs22CgJLomyJ05g-47OkggZhX_YF87ua5GFmPtGZ6N8mSwtBle3uNNh3g0gq0QKTGLoz_8Pc3BxD21O_w4exYKJ_gV5_BSOk9biufi118dEseS3ukd0T7E4q7VOEEvY-vGY3PiDu13L5LQhGkCLZbKgvPCNLgKTZTI97BthigpvvQdSgvy7AVC_FnNLo8XMXzfYyQ/https%3A%2F%2Flists.dns-oarc.net%2Fmailman%2Flistinfo%2Fdns-operations smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] .com delegation responses when glue addresses don't fit
--- Begin Message --- Hi Mukund, We are aware that this situation can arise given certain combinations of referral size and EDNS0 buffer size. We're also aware of draft-ietf-dnsop-glue-is-not-optional, and our engineers are figuring out how best to update our software in that context. It would be nice if some of the open questions around that draft could come to consensus. I would be interested to know more about the resolvers you mention as having trouble with this case. Either privately or on list. In the meantime, of course, the registrant could certainly remove some of the superfluous type 1 DS records to bring the referral size down if necessary. (My apologies for the delay in responding, I was out of the office for a few days.) DW > On Aug 19, 2020, at 10:33 AM, Mukund Sivaraman wrote: > > We notice the following response from .com's namesevers: > > [muks@mx ~]$ dig +nord +dnssec +bufsize=512 @2001:502:1ca1::30 infoblox.com > > ; <<>> DiG 1.1.1.20200608151533.e8a2352e96 <<>> +nord +dnssec +bufsize=512 > @2001:502:1ca1::30 infoblox.com > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15448 > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;infoblox.com.IN A > > ;; AUTHORITY SECTION: > infoblox.com. 172800 IN NS ns1.infoblox.com. > infoblox.com. 172800 IN NS ns2.infoblox.com. > infoblox.com. 172800 IN NS ns3.infoblox.com. > infoblox.com. 172800 IN NS ns4.infoblox.com. > infoblox.com. 172800 IN NS ns5.infoblox.com. > infoblox.com. 172800 IN NS ns6.infoblox.com. > infoblox.com. 86400 IN DS 33613 5 2 > 339462CBAEB1773800EA8B688D2CA048FCAB0EB2933A97AEE2B86A9A 212F37C5 > infoblox.com. 86400 IN DS 33613 5 1 > 629C2D6C060E2133CD0F4470F3ECC8834DA4FAD6 > infoblox.com. 86400 IN DS 49879 5 2 > 605656DB7C9DFE4D8A453C350B3DA63039A78878DA089AD4247AB9A0 D3B43998 > infoblox.com. 86400 IN DS 49879 5 1 > C1DB78AD9A8928CB15A7E0CE9E4468D433F5C638 > infoblox.com. 86400 IN RRSIG DS 8 2 86400 20200823050241 > 20200816035241 24966 com. > 0s/TnWuxLdVzCQqY0tVauNXeCpirT5rYacvEpxaQfTxCjP2XfZkqHy4A > SNoGyYWGZQdxTa7zXVgrKuWOoKZ2CKxC/kd++VnEJKoFw3llOoq56Wz+ > lq65BS7E6/ZlE4Qgce8rhbBQVkE6Sk1YXkuxDbwoPYfvkHlfWaboeiNO > 6y731Xcrq3vjqdG6YZCHyH64SSnVFypUiRN26H2HPsYsSg== > > ;; Query time: 19 msec > ;; SERVER: 2001:502:1ca1::30#53(2001:502:1ca1::30) > ;; WHEN: Wed Aug 19 17:30:29 GMT 2020 > ;; MSG SIZE rcvd: 512 > > [muks@mx ~]$ > > > Glue address records are required in this delegation response, but none > are returned. TC=1 is not set. This causes problems with some resolvers. > > Can someone at Verisign please check correctness of this response, and > set TC=1 for such responses? > > It appears to be the problem statement of: > https://secure-web.cisco.com/1QqHmwaQO268IxVLQk1vG77QkwUfoXr_FsBcOFC3WbBL0-z1sBokN2TQSQUIlO5MUEk8n-QDt5OqsF2XYKXj6HmPtF7d9WVmdFz1IvQLk5erNHt_LWYVK0dBO9yptLYEZ4EBBtErw5M_g__bNhppxQCIjmLWHTgO0OyJsUxZiJJT4oYqXZzP4WdRRZ9lBHWdA0TIjUw4AjyMyrwihFu9kPJxJ22ik6H8Tj5rP77dh9QCAC1kZc3pHQncJpgS7nil_fOSDWB4i_QxV7flDEQV89MBaqKba3UIaPlgYF2ejb0Q/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-andrews-dnsop-glue-is-not-optional-01 > > Mukund > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://secure-web.cisco.com/1ljZcR9ZM3atIeerJ95hsiha_l2uLsF6l6BLGUj7DskdX3f7uA1u_NsaWrLIFO0R4nD5Fd00JnD_E-VdYECtCPH8AiaDf9RoKTjaMGQd33oDfDdigZM1kLFHE0B4yN-PkznyZErWteBP6maqSgpcDUlIH8ce45yn4tCqmwEG5xov3TgvL7UzNr5jc59fZFWiPG4_n-jcN49u7IflMRhvdrTpcQpFxQRdMQqhqjsVBV0egt2YULsp8I6r81z_yjdThfWvK7iyvJPW9aLTkHJeuoQ/https%3A%2F%2Flists.dns-oarc.net%2Fmailman%2Flistinfo%2Fdns-operations smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Disclosure of root zone TSIG keys
--- Begin Message --- > On May 29, 2020, at 2:29 AM, Shane Kerr wrote: > > Duane, > > I really appreciate this level of transparency, thank you. > > This does make me think of a couple of questions. > > > First, I assume that the main goal of TSIG is to prevent modification of the > zone file(s) in transit, more than preventing access. The root zone is > public, right? That is correct. There was a time when we did not have IP ACLs and TSIG was the only method of access control, but that is no longer the case. > > Since the goal is to prevent modification, I guess the root server operators > could fetch PGP signatures from the Internic server and verify the zone > today. Do you know if there is any documentation covering the operational > practices of the root server operators in this regard? I'm not aware of any such documentation or of any operators that actually do that. > > In the future, adding message digests (draft-ietf-dnsop-dns-zone-digest) to > the zones and having both that and the DNSSEC signatures verified by root > server operators before accepting a new version of the root zone would be a > nice additional check. (Whoever thought of those digests seems really > on-the-ball. ) Yes, we would very much like to see ZONEMD advance so we can have that check. > > > Second, while it is nice that there are IP-based whitelists protecting zone > transfers, are there any requirements for IP's on the whitelists to use RPKI > or other routing protections? Even if there are no requirements, does > Verisign check RPKI if the root server operators *do* sign their routes? We > know that there is BGP hijacking in the wild today, so using and encouraging > secured routing seems reasonable to me. Interesting you mention this. We have been evaluating the pros and cons of RPKI publication for our number resources as well as origin validation for received routes. While we are working on this and intend to fully implement RPKI given new dependencies it introduces we are being very deliberate and working closely with our carrier partners, etc.. to minimize the new risks it introduces. More to come on that in the coming months. Work is underway now to ensure that we monitor all the root zone distribution prefixes just as we monitor own prefixes (commercial and bespoke tools for routing system prefixes, attributes, and changes, IRR objects, and RPKI objects). DW > > > Thanks again for the transparency and keep up the good work! > > -- > Shane smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Disclosure of root zone TSIG keys
--- Begin Message --- Dear DNS operations community, Last week Verisign determined that the transaction signature (TSIG) keys used to authenticate and secure root zone transfers from our zone distribution servers to root server operators were exposed to one or more unauthorized parties. For the explanation behind the disclosure, please refer to Appendix A below. We believe that the risks to the root zone from this disclosure were low. Zone transfers from Verisign's distribution servers are first protected by whitelist access control lists (ACLs) provided by each operator, and the root zone content is not sensitive. Nonetheless, upon learning of the disclosure, we notified ICANN and then worked quickly with the root server operators to roll to a new active TSIG key. That work was completed by May 26 and all root operators were confirmed to be using the new key. The urgency for rolling the key across a series of systems and a diverse set of root operators in just a few days rather than weeks / months was in part motivated by a recent BIND TSIG bug, which was seen as heightening the risk of the disclosure, albeit only slightly. More background on the TSIG vulnerability is included in Appendix B below. If you have questions regarding this disclosure please don’t hesitate to contact us at i...@verisign-grs.com --- Appendix A: Background information on recent root TSIG disclosure On May 20, 2020 security tools alerted Verisign security teams that two internal servers were publicly accessible via a file copy service. Upon investigation our teams identified two additional servers that were also accessible. Altogether, these four servers were used for testing and/or staging functions. We have determined that a failure of network access controls was the root cause and that the scope of exposure involves read-only access to a constrained set of directories via the file copy service on these four servers. The DNSSEC keying materials for any Verisign managed zones were not impacted by this incident as the impact was limited to testing and staging environments. Verisign signing servers and related infrastructure are operated in accordance with published DNSSEC practice statements and DNSSEC keys are held in FIPs 140-2 level 3+ validated Hardware Security Modules (HSMs) as well as offline cryptographic systems to ensure the integrity of the signed zones operated by Verisign. No Verisign operated TLDs (e.g., COM, NET, etc.), registry operations, or other services were impacted by this incident. Information contained on the servers did include transaction signature (TSIG) keys used for distribution of the root zone from Verisign’s servers to the root server operators, as well as TSIG keys used by Verisign to retrieve 103 in-addr.arpa child domains from ARIN. Facts related to the incident include: • We have concluded the exposure was introduced on August 21, 2019 • Our analysis has determined that files in the read-only directories, to include the root zone TSIG keys, as well as TSIG keys for in-addr.arpa child zones fetched from ARIN, were accessed by unauthorized parties • The accessible service had been legitimately enabled on these servers for use by Verisign teams; the service should not have been internet-accessible • The files were legitimately placed on the four servers for testing and/or staging purposes • The directories accessible to the service were read-only • The operational security stack for the environment was properly functioning and the four servers were properly logging to local and remote facilities at the time of the investigation • High frequency internal and external vulnerability scanners were properly identifying the services and archiving the condition but not properly alerting on them; a supplementary security tool alerted internal teams to the issue • The systems in these environments are continuously patched and are frequently wiped and rebuilt • No personal information was stored on the servers • The keys used to fetch the ARIN zones were changed on May 22, and the keys used for root zone distribution were changed over a ~3-day period and completed May 26. Identified control deficiencies have been corrected to prevent further unauthorized access, alerting has been enhanced and new capabilities have been developed to prevent and/or more quickly detect and alert on any similar incidents going forward. Current information suggests with a high confidence that no broader internal exposure resulted from the incident (e.g., there were no indications of unauthorized activity beyond access to the read-only directories, there were no indications of system-level compromise, lateral movement, or other subsequent related activities). There are multiple controls around distribution of the root zone file to root operators and the contents of the
Re: [dns-operations] SOA rname breakage (first label split on internal dots) from Verisign public DNS
--- Begin Message --- Viktor, Thanks again for reporting this. We have identified the source of the problem and have begun developing a fix. We'll let you know once it has been deployed. DW > On Mar 24, 2020, at 8:02 AM, Wessels, Duane wrote: > > Thanks Viktor, we will investigate and report back. > > DW > > >> On Mar 23, 2020, at 11:39 PM, Viktor Dukhovni wrote: >> >> The podotrack.nl domain has two authoritative servers: >> >> podotrack.nl. IN NS ns1.exsilia.net. >> podotrack.nl. IN NS ns2.exsilia.net. >> >> Both return the same SOA RR with a escaped "." in the first label of the SOA >> "rname": >> >> $ dig +norecur +dnssec -t SOA +noall +ans podotrack.nl @ns1.exsilia.net >> podotrack.nl. 86400 IN RRSIG SOA 8 2 86400 >> 2020040200 2020031200 16285 podotrack.nl. >> QaAaTslfbdObE8V2vsPtN9j3VEiW5rb1Rq/K7xb9IlDShj06tw3ruRfx >> wmeyaKEqiD+HmXwERervVbx+ilgIcNwD8emqJ+BfZxv4lyhwyVnmPpIW >> /ggeijP4L7EywS7lsO0zs2nwB/Bhv/f5KwFIQy4Cm+hj99zbvULaNuNf ibw= >> podotrack.nl. 86400 IN SOA ns2.exsilia.net. >> j\.deklein.lijnco.nl. 201901 10800 3600 604800 10800 >> >> $ dig +norecur +dnssec -t SOA +noall +ans podotrack.nl @ns2.exsilia.net >> podotrack.nl. 86400 IN SOA ns2.exsilia.net. >> j\.deklein.lijnco.nl. 201901 10800 3600 604800 10800 >> podotrack.nl. 86400 IN RRSIG SOA 8 2 86400 >> 2020040200 2020031200 16285 podotrack.nl. >> QaAaTslfbdObE8V2vsPtN9j3VEiW5rb1Rq/K7xb9IlDShj06tw3ruRfx >> wmeyaKEqiD+HmXwERervVbx+ilgIcNwD8emqJ+BfZxv4lyhwyVnmPpIW >> /ggeijP4L7EywS7lsO0zs2nwB/Bhv/f5KwFIQy4Cm+hj99zbvULaNuNf ibw= >> >> But that is *not* what I see from Verisign public DNS: >> >> $ dig +dnssec -t SOA +noall +ans podotrack.nl @64.6.64.6 >> podotrack.nl. 86400 IN SOA ns2.exsilia.net. >> j.deklein.lijnco.nl. 201901 10800 3600 604800 10800 >> podotrack.nl. 86400 IN RRSIG SOA 8 2 86400 >> 2020040200 2020031200 16285 podotrack.nl. >> QaAaTslfbdObE8V2vsPtN9j3VEiW5rb1Rq/K7xb9IlDShj06tw3ruRfx >> wmeyaKEqiD+HmXwERervVbx+ilgIcNwD8emqJ+BfZxv4lyhwyVnmPpIW >> /ggeijP4L7EywS7lsO0zs2nwB/Bhv/f5KwFIQy4Cm+hj99zbvULaNuNf ibw= >> >> Even though the serial number and RRSIG are the same, the first label is >> not escaped! The answer has a TTL of 86400 and looks fresh (!cached). >> This breaks the SOA RRSIG and denial of existence of TLSA RRs, ... >> >> The remaining usual suspects all return the expected rname: >> >> $ dig +dnssec -t SOA +noall +ans podotrack.nl @8.8.8.8 >> podotrack.nl. 21599 IN RRSIG SOA 8 2 86400 >> 2020040200 2020031200 16285 podotrack.nl. >> QaAaTslfbdObE8V2vsPtN9j3VEiW5rb1Rq/K7xb9IlDShj06tw3ruRfx >> wmeyaKEqiD+HmXwERervVbx+ilgIcNwD8emqJ+BfZxv4lyhwyVnmPpIW >> /ggeijP4L7EywS7lsO0zs2nwB/Bhv/f5KwFIQy4Cm+hj99zbvULaNuNf ibw= >> podotrack.nl. 21599 IN SOA ns2.exsilia.net. >> j\.deklein.lijnco.nl. 201901 10800 3600 604800 10800 >> >> $ dig +dnssec -t SOA +noall +ans podotrack.nl @1.1.1.1 >> podotrack.nl. 10596 IN SOA ns2.exsilia.net. >> j\.deklein.lijnco.nl. 201901 10800 3600 604800 10800 >> podotrack.nl. 10596 IN RRSIG SOA 8 2 86400 >> 2020040200 2020031200 16285 podotrack.nl. >> QaAaTslfbdObE8V2vsPtN9j3VEiW5rb1Rq/K7xb9IlDShj06tw3ruRfx >> wmeyaKEqiD+HmXwERervVbx+ilgIcNwD8emqJ+BfZxv4lyhwyVnmPpIW >> /ggeijP4L7EywS7lsO0zs2nwB/Bhv/f5KwFIQy4Cm+hj99zbvULaNuNf ibw= >> >> $ dig +dnssec -t SOA +noall +ans podotrack.nl @9.9.9.10 >> podotrack.nl. 43200 IN SOA ns2.exsilia.net. >> j\.deklein.lijnco.nl. 201901 10800 3600 604800 10800 >> podotrack.nl. 43200 IN RRSIG SOA 8 2 86400 >> 2020040200 2020031200 16285 podotrack.nl. >> QaAaTslfbdObE8V2vsPtN9j3VEiW5rb1Rq/K7xb9IlDShj06tw3ruRfx >> wmeyaKEqiD+HmXwERervVbx+ilgIcNwD8emqJ+BfZxv4lyhwyVnmPpIW >> /ggeijP4L7EywS7lsO0zs2nwB/Bhv/f5KwFIQy4Cm+hj99zbvULaNuNf ibw= >> >> Checking army.mil (lots of dots in the first rname label), I find the >> same symptoms: >> >> $ dig +dnssec -t soa +noall +ans +add army.mil @64.6.64.6 >> army.mil. 1700IN SOA ns01.army.mil. >> usarmy.huachuca.netcom.mesg.epdns-global.mail.mil. 2007040001 900 90 2419200 >> 300 >> army.mil. 1700IN RRSIG SOA 8 2 3600 >> 20200328054853 20200324044853 51378 army.mil. >> gKsZWexzUD9tYM09JQnF/5pnd1ZKwxtBd9FjWtRTIimQRqldhMwFdALV >> 3vg4UGde6iSS1xH0jmXLeBPlk0ETNLtXwGRl7ywko8Q12eVy7XgUASwM >> OM3Sv6XEfaNglTHbqmeJo987BSlkNqwUFIlCnvI0OFiboLX9le+xl6eI >> bw2GsGrd+/Q+XU37JvDAQ55X9mECMM1jHjraBD2NKfcPGRP700Myie+q >> WgUuQrs40YGR8jFLrxk5/R/A4uPK0hlXVpjHv6cmrlAW00BS7LlP+5Ha >> H+oh10/0hQkofrjhQWINXUKCSHI4mMSO6liubK74cjS5fxg07BnvaMKJ OtoIuQ== >> >> $ dig +dnssec -t soa +noall +ans +add army.mil @8.8.8.8 >> army.mil. 2830IN SOA ns01.army.mil. >>
Re: [dns-operations] SOA rname breakage (first label split on internal dots) from Verisign public DNS
--- Begin Message --- Thanks Viktor, we will investigate and report back. DW > On Mar 23, 2020, at 11:39 PM, Viktor Dukhovni wrote: > > The podotrack.nl domain has two authoritative servers: > >podotrack.nl. IN NS ns1.exsilia.net. >podotrack.nl. IN NS ns2.exsilia.net. > > Both return the same SOA RR with a escaped "." in the first label of the SOA > "rname": > >$ dig +norecur +dnssec -t SOA +noall +ans podotrack.nl @ns1.exsilia.net >podotrack.nl. 86400 IN RRSIG SOA 8 2 86400 > 2020040200 2020031200 16285 podotrack.nl. > QaAaTslfbdObE8V2vsPtN9j3VEiW5rb1Rq/K7xb9IlDShj06tw3ruRfx > wmeyaKEqiD+HmXwERervVbx+ilgIcNwD8emqJ+BfZxv4lyhwyVnmPpIW > /ggeijP4L7EywS7lsO0zs2nwB/Bhv/f5KwFIQy4Cm+hj99zbvULaNuNf ibw= >podotrack.nl. 86400 IN SOA ns2.exsilia.net. > j\.deklein.lijnco.nl. 201901 10800 3600 604800 10800 > >$ dig +norecur +dnssec -t SOA +noall +ans podotrack.nl @ns2.exsilia.net >podotrack.nl. 86400 IN SOA ns2.exsilia.net. > j\.deklein.lijnco.nl. 201901 10800 3600 604800 10800 >podotrack.nl. 86400 IN RRSIG SOA 8 2 86400 > 2020040200 2020031200 16285 podotrack.nl. > QaAaTslfbdObE8V2vsPtN9j3VEiW5rb1Rq/K7xb9IlDShj06tw3ruRfx > wmeyaKEqiD+HmXwERervVbx+ilgIcNwD8emqJ+BfZxv4lyhwyVnmPpIW > /ggeijP4L7EywS7lsO0zs2nwB/Bhv/f5KwFIQy4Cm+hj99zbvULaNuNf ibw= > > But that is *not* what I see from Verisign public DNS: > >$ dig +dnssec -t SOA +noall +ans podotrack.nl @64.6.64.6 >podotrack.nl. 86400 IN SOA ns2.exsilia.net. > j.deklein.lijnco.nl. 201901 10800 3600 604800 10800 >podotrack.nl. 86400 IN RRSIG SOA 8 2 86400 > 2020040200 2020031200 16285 podotrack.nl. > QaAaTslfbdObE8V2vsPtN9j3VEiW5rb1Rq/K7xb9IlDShj06tw3ruRfx > wmeyaKEqiD+HmXwERervVbx+ilgIcNwD8emqJ+BfZxv4lyhwyVnmPpIW > /ggeijP4L7EywS7lsO0zs2nwB/Bhv/f5KwFIQy4Cm+hj99zbvULaNuNf ibw= > > Even though the serial number and RRSIG are the same, the first label is > not escaped! The answer has a TTL of 86400 and looks fresh (!cached). > This breaks the SOA RRSIG and denial of existence of TLSA RRs, ... > > The remaining usual suspects all return the expected rname: > >$ dig +dnssec -t SOA +noall +ans podotrack.nl @8.8.8.8 >podotrack.nl. 21599 IN RRSIG SOA 8 2 86400 > 2020040200 2020031200 16285 podotrack.nl. > QaAaTslfbdObE8V2vsPtN9j3VEiW5rb1Rq/K7xb9IlDShj06tw3ruRfx > wmeyaKEqiD+HmXwERervVbx+ilgIcNwD8emqJ+BfZxv4lyhwyVnmPpIW > /ggeijP4L7EywS7lsO0zs2nwB/Bhv/f5KwFIQy4Cm+hj99zbvULaNuNf ibw= >podotrack.nl. 21599 IN SOA ns2.exsilia.net. > j\.deklein.lijnco.nl. 201901 10800 3600 604800 10800 > >$ dig +dnssec -t SOA +noall +ans podotrack.nl @1.1.1.1 >podotrack.nl. 10596 IN SOA ns2.exsilia.net. > j\.deklein.lijnco.nl. 201901 10800 3600 604800 10800 >podotrack.nl. 10596 IN RRSIG SOA 8 2 86400 > 2020040200 2020031200 16285 podotrack.nl. > QaAaTslfbdObE8V2vsPtN9j3VEiW5rb1Rq/K7xb9IlDShj06tw3ruRfx > wmeyaKEqiD+HmXwERervVbx+ilgIcNwD8emqJ+BfZxv4lyhwyVnmPpIW > /ggeijP4L7EywS7lsO0zs2nwB/Bhv/f5KwFIQy4Cm+hj99zbvULaNuNf ibw= > >$ dig +dnssec -t SOA +noall +ans podotrack.nl @9.9.9.10 >podotrack.nl. 43200 IN SOA ns2.exsilia.net. > j\.deklein.lijnco.nl. 201901 10800 3600 604800 10800 >podotrack.nl. 43200 IN RRSIG SOA 8 2 86400 > 2020040200 2020031200 16285 podotrack.nl. > QaAaTslfbdObE8V2vsPtN9j3VEiW5rb1Rq/K7xb9IlDShj06tw3ruRfx > wmeyaKEqiD+HmXwERervVbx+ilgIcNwD8emqJ+BfZxv4lyhwyVnmPpIW > /ggeijP4L7EywS7lsO0zs2nwB/Bhv/f5KwFIQy4Cm+hj99zbvULaNuNf ibw= > > Checking army.mil (lots of dots in the first rname label), I find the > same symptoms: > >$ dig +dnssec -t soa +noall +ans +add army.mil @64.6.64.6 >army.mil. 1700IN SOA ns01.army.mil. > usarmy.huachuca.netcom.mesg.epdns-global.mail.mil. 2007040001 900 90 2419200 > 300 >army.mil. 1700IN RRSIG SOA 8 2 3600 > 20200328054853 20200324044853 51378 army.mil. > gKsZWexzUD9tYM09JQnF/5pnd1ZKwxtBd9FjWtRTIimQRqldhMwFdALV > 3vg4UGde6iSS1xH0jmXLeBPlk0ETNLtXwGRl7ywko8Q12eVy7XgUASwM > OM3Sv6XEfaNglTHbqmeJo987BSlkNqwUFIlCnvI0OFiboLX9le+xl6eI > bw2GsGrd+/Q+XU37JvDAQ55X9mECMM1jHjraBD2NKfcPGRP700Myie+q > WgUuQrs40YGR8jFLrxk5/R/A4uPK0hlXVpjHv6cmrlAW00BS7LlP+5Ha > H+oh10/0hQkofrjhQWINXUKCSHI4mMSO6liubK74cjS5fxg07BnvaMKJ OtoIuQ== > >$ dig +dnssec -t soa +noall +ans +add army.mil @8.8.8.8 >army.mil. 2830IN SOA ns01.army.mil. > usarmy\.huachuca\.netcom\.mesg\.epdns-global.mail.mil. 2007040004 900 90 > 2419200 300 >army.mil. 2830IN RRSIG SOA 8 2 3600 > 20200328061900 20200324051900 51378 army.mil. > WVAHvrkjdrq4Z1QShUec3xqGT3DSPJIx6vABFUVlO+mQfI4w9ZclXYqP >
Re: [dns-operations] .COM Zone DNSSEC Operational Update -- ZSK length change
--- Begin Message --- > On Dec 28, 2019, at 8:50 AM, Matt Nordhoff wrote: > > On Mon, Oct 14, 2019 at 6:34 PM Wessels, Duane via dns-operations > wrote: >> All, >> >> Verisign is in the process of increasing the size and strength of >> the DNSSEC Zone Signing Keys (ZSKs) for the top-level domains that >> it operates. As part of this process, the ZSK for the .COM zone will >> be increased in size from 1024 to 1280 bits. >> >> On October 10, 2019 the 1280 bit ZSK was pre-published in the .COM zone. >> On October 15, we plan to sign the .COM zone with the 1280 bit ZSK. >> On October 20, we plan to remove the old 1024 bit ZSK from the zone. > > D'y'all have an updated ETA on step 3? > Matt, My apologies for the incorrect information in the initial message. The old 1024-bit ZSK was post-published for an extended period of time. It was removed as of Jan 1. DW smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] root? we don't need no stinkin' root!
--- Begin Message --- > On Nov 25, 2019, at 1:23 PM, Bill Woodcock wrote: > >> On Nov 25, 2019, at 9:54 PM, Florian Weimer wrote: >> The query numbers are surprisingly low. To me at last. > > Duane Wessels did a good study some time ago of queries to the root. I > believe over 99% were bogus, not real queries for resolvable things. For the record, the number from that study (2003!) was 98%. I believe it has since been reconfirmed to be about the same level in a number of subsequent studies by others. DW smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] root? we don't need no stinkin' root!
--- Begin Message --- > On Nov 25, 2019, at 2:19 PM, Florian Weimer wrote: > > * Jim Reid: > >>> On 25 Nov 2019, at 20:54, Florian Weimer wrote: >>> Is it because of the incoming data is interesting? >> >> Define interesting. > > The data could have monetary value. Passwords that are otherwise > difficult to come by might be leaking. Hi Florian, I can assure you that Verisign does not monetize the root server data. If any other operators do, I'm not aware of it. We do utilize root server data for research purposes from time-to-time. Recent examples include the KSK rollover and name collisions. Less recent examples include understanding TTL/caching behavior and preparing for the root ZSK size increase. When DDoS attacks happen, we often analyze the data to see if we can understand how and why it happened, and to be better prepared for the next one. DW smime.p7s Description: S/MIME cryptographic signature --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
