OARC 43 - Call for Contribution (location and date changs)
The DNS-OARC Programme Committee is seeking contributions from the community. This workshop will be a hybrid event. Date - likely in the week of 26-27 October 2024, details will be confirmed later Location - Prague, CZ Time zone - approximately 09:00-17:00 UTC +5 (TBC) Partnered/co-located with - RIPE NCC Submission requirements - Topic must be related to DNS - 10 or 20 minutes (there will be additional 5 min of Q following each talk) - Will be broadcast live and recorded for future reference - Presentation slides will be publicly available before, during and after meeting Acceptance Criteria - Proposal should be at a high technical level suitable to the audience - Submissions should include draft slides or at least detailed description of the proposed talk content - PC might require improvements to slides before and after talk acceptance How to submit - Submission deadline: 2024-07-23 23:59 UTC - You will need to create an account in the Indico system - A Step-by-Step guide to submitting in Indico can be found here: <https://bit.ly/49GftMx> Suggested Topics All DNS-related subjects and discussion topics are welcome! Here’s a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve time to recovery, tooling), interoperability concerns and experience. - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS server efficiency - Security/Privacy: DNSSEC signing and validation, key storage, qname minimization, DoH/DoT/DoQ Workshop Milestones - CFP submissions open in Indico: now - Deadline for Submissions: 2024-07-23 23:59 UTC - Preliminary list of contributions published: end of July 2024 - Full agenda published: beginning of August 2024 - Deadline for slides submission - no changes possible: 2024-10-12 23:59 UTC - Remote speaker rehearsal: will be confirmed later Relevant Links - Registration page and details for presentation submission <https://www.dns-oarc.net/oarc43> - FAQ - Submitting a Proposal for the Workshop <https://bit.ly/49GftMx> - Contact information (who to contact for what) <https://indico.dns-oarc.net/event/51/page/294-who-do-i-contact> - Guidelines for presentation slides <https://www.devconf.info/cz/speakerguide/> Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net John Todd, for the DNS-OARC Programme Committee For OARC 43 we are open to patronage and donations to fund the Workshop and associated events. Please contact spon...@dns-oarc.net if your organization is interested in becoming an OARC 43 patron. (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.) -- John Todd - jt...@quad9.net General Manager - Quad9 Recursive Resolver
OARC 43 - Call for Contribution
The DNS-OARC Programme Committee is seeking contributions from the community. This workshop will be a hybrid event. Date - likely in the week of 23-27 September 2024, details will be confirmed later Location - South America, exact location will be confirmed later Time zone - approximately 09:00-17:00 UTC -5 (TBC) Partnered/co-located with - related industry events, will be confirmed later Submission requirements Topic must be related to DNS 10 or 20 minutes (there will be additional 5 min of Q following each talk) Will be broadcast live and recorded for future reference Presentation slides will be publicly available before, during and after meeting Acceptance Criteria Proposal should be at a high technical level suitable to the audience Submissions should include draft slides or at least detailed description of the proposed talk content PC might require improvements to slides before and after talk acceptance How to submit Submission deadline: 2024-06-23 23:59 UTC You will need to create an account in the Indico system A Step-by-Step guide to submitting in Indico can be found here: <https://bit.ly/49GftMx> Suggested Topics All DNS-related subjects and discussion topics are welcome! Here’s a non-exhaustive list of ideas: Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve time to recovery, tooling), interoperability concerns and experience. Deployment: DNS config management and release process. Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. Scaling: DNS performance management and metrics. Increasing DNS server efficiency Security/Privacy: DNSSEC signing and validation, key storage, qname minimization, DoH/DoT/DoQ Workshop Milestones CFP submissions open in Indico: now Deadline for Submissions: 2024-06-23 23:59 UTC Preliminary list of contributions published: end of June 2024 Full agenda published: beginning of July 2024 Deadline for slides submission - no changes possible: 2024-09-12 23:59 UTC Remote speaker rehearsal: will be confirmed later Relevant Links Registration page and details for presentation submission <https://www.dns-oarc.net/oarc43> FAQ - Submitting a Proposal for the Workshop <https://bit.ly/49GftMx> Contact information (who to contact for what) <https://indico.dns-oarc.net/event/51/page/294-who-do-i-contact> Guidelines for presentation slides <https://www.devconf.info/cz/speakerguide/> Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net John Todd, for the DNS-OARC Programme Committee For OARC 43 we are open to patronage and donations to fund the Workshop and associated events. Please contact spon...@dns-oarc.net if your organization is interested in becoming an OARC 43 patron. (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.)
OARC 42 - Call for Contributions (co-located with NANOG 90)
OARC 42 will be a two-day hybrid meeting and the dates are 8th and 9th February to be co-located with NANOG 90 in Charlotte, North Carolina, USA. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). Deployment: DNS config management and release process. Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT The presentations can be either 10 or 20 minutes in length (plus 5 minutes for Q). Proposals for in-person lightning presentations will be opened closer to the Workshop dates. Workshop Milestones: 2023-09-07 Submissions open via Indico 2023-11-22 Deadline for submission (23:59 UTC) 2023-11-29 Preliminary list of contributions published 2023-12-13 Full agenda published 2024-01-10 Deadline for slideset submission and Rehearsal 2024-02-08 OARC 42 Workshop - Day1 2024-02-09 OARC 42 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc42> 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. Example guidelines for presentation slides: https://www.grammarly.com/blog/presentation-tips/ Additional information for speakers of OARC 42 - your talk will be broadcast live and recorded for future reference - your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting - remote speakers have mandatory rehearsal (Date and Time TBD). It would be very useful to have your slides (even if draft) ready for this Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net OARC depends on sponsorship to fund its workshops and associated social events. Please contact spon...@dns-oarc.net 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.) John Todd, for the DNS-OARC Programme Committee -- John Todd - jt...@quad9.net General Manager - Quad9 Recursive Resolver
OARC 41 - Call for Contribution -- deadline extension & location announcement
Deadline for OARC 41 abstract submission is extended to June 20th, 23:59 UTC. Please note that, we are looking for contributions and remote participation is actively supported * OARC 41 will be a two-day hybrid meeting and the dates are 6th and 7th September to be co-located with ICANN DNS Symposium in Da Nang, Vietnam. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). Deployment: DNS config management and release process. Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT The presentations can be either 10 or 20 minutes in length (plus 5 minutes for Q). Proposals for in-person lightning presentations will be opened at the Workshop. Workshop Milestones: 2023-04-16 Submissions open via Indico 2023-06-20 Deadline for submission (23:59 UTC) 2023-06-27 Preliminary list of contributions published 2023-07-11 Full agenda published 2023-08-08 Deadline for slideset submission and Rehearsal 2023-09-06 OARC 41 Workshop - Day1 2023-09-07 OARC 41 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc41> 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. Example guidelines for presentation slides: https://www.grammarly.com/blog/presentation-tips/ Additional information for speakers of OARC 41 your talk will be broadcast live and recorded for future reference your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting Remote speakers have mandatory rehearsal on 2023-08-08 at 14:00 UTC. It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net John Todd, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact spon...@dns-oarc.net 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.)
OARC 41- Call for Contributions
OARC 41 will be a two-day hybrid meeting and the tentative dates are 6th-7th September to be co-located with ICANN DNS Symposium in Asia. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: * Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling) * Deployment: DNS config management and release process.Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection * Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency * Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT The presentations can be either a full-length presentation - 20 mins (+5 mins Q/A) or a lightning presentation - 10 mins (+5 mins for Q/A) Workshop Milestones: 2023-04-16 Submissions open via Indico 2023-06-10 Deadline for submission (23:59 UTC) 2023-06-27 Preliminary list of contributions published 2023-07-11 Full agenda published 2023-08-08 Deadline for slideset submission and Rehearsal 2023-09-06 OARC 41 Workshop - Day1 2023-09-07 OARC 41 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc41> 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. Example guidelines for presentation slides: https://www.grammarly.com/blog/presentation-tips/ Additional information for speakers of OARC 41: * Your talk will be broadcast live and recorded for future reference * Your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting * Remote speakers have mandatory rehearsal on 2023-08-08 at 14:00 UTC. It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net OARC depends on sponsorship to fund its workshops and associated social events. Please contact spon...@dns-oarc.net 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.) John Todd, for the DNS-OARC Programme Committee -- John Todd - jt...@quad9.net General Manager - Quad9 Recursive Resolver
Reminder OARC 40 - Call for Contribution
Deadline Extension for OARC 40 abstract submission - January 5, 23:59 UTC Please note that, we are looking for contributions and remote participation is actively supported Subject: OARC 40 - Call for Contribution OARC 40 will be a two-day hybrid meeting held on 16 & 17 February in Atlanta (GA), USA at 10:00 AM (Local time - EST (UTC-05:00)). The onsite part of the meeting will be colocated with NANOG 87. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: • Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). • Deployment: DNS config management and release process. • Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. • Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency • Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT The presentations can be either a full-length presentation - 20 mins (+5 mins Q/A) or a lightning presentation - 10 mins (+5 mins for Q/A) Workshop Milestones: 2022-10-22 Submissions open via Indico 2022-01-05 Extended Deadline for submission (23:59 UTC) 2023-01-10 Preliminary list of contributions published 2023-01-17 Full agenda published 2023-01-30 Deadline for slideset submission and Rehearsal 2023-02-16 OARC 40 Workshop - Day1 2023-02-17 OARC 40 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc40> 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. Guidelines for presentation slides: https://www.grammarly.com/blog/presentation-tips/ Additional information for speakers of OARC 40 • your talk will be broadcast live and recorded for future reference • your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting • Remote speakers have mandatory rehearsal on 2023-01-31 at 14:00 UTC. It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net John Todd, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact spon...@dns-oarc.net 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.) -- John Todd - jt...@quad9.net General Manager - Quad9 Recursive Resolver
Reminder OARC 40 - Call for Contribution
Reminder: Deadline for OARC 40 abstract submission - December 20, 23:59 UTC Please note that, we are looking for contributions and remote participation is actively supported Subject: OARC 40 - Call for Contribution OARC 40 will be a two-day hybrid meeting held on 16 & 17 February in Atlanta (GA), USA at 10:00 AM (Local time - EST (UTC-05:00)). The onsite part of the meeting will be colocated with NANOG 87. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: • Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). • Deployment: DNS config management and release process. • Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. • Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency • Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT The presentations can be either a full-length presentation - 20 mins (+5 mins Q/A) or a lightning presentation - 10 mins (+5 mins for Q/A) Workshop Milestones: 2022-10-22 Submissions open via Indico 2022-12-20 Deadline for submission (23:59 UTC) 2023-01-10 Preliminary list of contributions published 2023-01-17 Full agenda published 2023-01-30 Deadline for slideset submission and Rehearsal 2023-02-16 OARC 40 Workshop - Day1 2023-02-17 OARC 40 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc40> 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. Guidelines for presentation slides: https://www.grammarly.com/blog/presentation-tips/ Additional information for speakers of OARC 40 • your talk will be broadcast live and recorded for future reference • your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting • Remote speakers have mandatory rehearsal on 2023-01-31 at 14:00 UTC. It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net John Todd, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact spon...@dns-oarc.net 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.) -- John Todd - jt...@quad9.net General Manager - Quad9 Recursive Resolver
DNS OARC 40 - Call for Contribitions
OARC 40 will be a two-day hybrid meeting held on 16 & 17 February in Atlanta (GA), USA at 10:00 AM (Local time - EST (UTC-05:00)). The onsite part of the meeting will be colocated with NANOG 87. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT The presentations can be either a full-length presentation - 20 mins (+5 mins Q/A) or a lightning presentation - 10 mins (+5 mins for Q/A) Workshop Milestones: 2022-10-22 Submissions open via Indico 2022-12-20 Deadline for submission (23:59 UTC) 2023-01-10 Preliminary list of contributions published 2023-01-17 Full agenda published 2023-01-30 Deadline for slideset submission and Rehearsal 2023-02-16 OARC 40 Workshop - Day1 2023-02-17 OARC 40 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc40> 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. Guidelines for presentation slides: https://www.grammarly.com/blog/presentation-tips/ Additional information for speakers of OARC 40 - Your talk will be broadcast live and recorded for future reference - Your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting - Remote speakers have mandatory rehearsal on 2023-01-31 at 14:00 UTC. It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net John Todd, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact spon...@dns-oarc.net 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.) -- John Todd - jt...@quad9.net General Manager - Quad9 Recursive Resolver
Extended Deadline and Reminder OARC 39 - Call for Contribution
OARC 39 will be a two-day hybrid meeting held on 22 & 23 October in Belgrade, Serbia at 10:00 AM (Local time - CEST (UTC+02:00)) The onsite part of the meeting will be colocated with RIPE 85. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). Deployment: DNS config management and release process. Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT Note: OARC 39 will be a joint conference with CENTR and abstract submissions from CENTR members are welcome. As it is an hybrid workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). Workshop Milestones: 2022-07-30 Submissions open via Indico 2022-09-06 Deadline for submission (23:59 UTC) 2022-09-08 Preliminary list of contributions published 2022-09-20 Full agenda published 2022-10-03 Deadline for slideset submission and Rehearsal 2022-10-22 OARC 39 Workshop - Day1 2022-10-23 OARC 39 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc39> 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. Additional information for speakers of OARC 39 - Your talk will be broadcast live and recorded for future reference - Your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting = Remote speakers have mandatory rehearsal on 2022-10-04 at 14:00 UTC. It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net John Todd, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact spon...@dns-oarc.net 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.)
DNS-OARC 39 Call for Contributions
OARC 39 will be a two-day hybrid meeting held on 22 & 23 October in Belgrade, Serbia at 10:00 AM (Local time - CEST (UTC+02:00)) The onsite part of the meeting will be colocated with RIPE 85. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT As it is a hybrid workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). Workshop Milestones: 2022-09-06 Deadline for submission (23:59 UTC) 2022-09-08 Preliminary list of contributions published 2022-09-20 Full agenda published 2022-10-03 Deadline for slideset submission and Rehearsal 2022-10-22 OARC 39 Workshop - Day1 2022-10-23 OARC 39 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc39> 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. Additional information for speakers at OARC 39: - Your talk will be broadcast live and recorded for future reference - Your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting - Remote speakers have mandatory rehearsal on 2022-10-04 at 14:00 UTC. It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via John Todd, for the DNS-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.) -- John Todd - jt...@quad9.net General Manager - Quad9 Recursive Resolve
Re: Carrier Options in Bogota
On 1 Jul 2022, at 6:47, nanoguser99 via NANOG wrote: Nanog, I need good connectivity to local eyeball networks there. I've explored Cogent, Lumen, and a local clled Telxius and results are all over the map. Is there a provider that's 'well peered' with all the locals? Hoping this formats correctly but here's the results of ping tests on various looking glasses to prefixes of the various locals. Local Carriers IP Prefix Telxius Lumen Cogent COLOMBIA TELECOMUNICACIONES S.A. ESP 152.200.0.0/14 22.025 ms 164ms 115 ms Telmex Colombia S.A. (Claro)190.144.0.0/14 14.319 ms 63ms115 ms Empresas Públicas de Medellín E.S.P. 201.220.30.0/23 94.264 ms 126 ms 102 ms Movistar Colombia 186.116.14.0/24 38.894 ms 193ms 118 ms ETB - Colombia 186.154.0.0/16 5.340 ms130ms 2.21 ms Columbus Networks Colombia 138.121.12.0/24 60.212 ms 99ms89.8 ms Metrotel Colombia 190.1.128.0/19 20.989 ms 148ms 90.5 ms Any advice? -Nanoguser99 Sent with [Proton Mail](https://proton.me/) secure email. [not exactly fitting the NA of NANOG, but I’m guessing there is an interest in North-and-South connectivity in general, so will continue the conversation] You didn’t specify exactly how you’d like to get access to the eyeballs, so I’ll throw our 2 pesos in here: We have deployed a number of recursive resolvers in EdgeUno (AS7195) datacenters in LATAM including Bogotá and have been very pleased with the results reaching local eyeball networks. They have IP transit, co-location, and other offerings so perhaps there is a match there. We are also deployed in IX locations in LATAM with other sponsorship/partnerships, but there are always edge cases that for whatever political/economic/telcomindedness reasons are better covered by transit arrangements. For the nations in which we are deployed with them, EdgeUno has solved most of those issues for us. Tests are possible via their LG: https://lg.edgeuno.com/ JT -- John Todd - jt...@quad9.net General Manager - Quad9 Recursive Resolver
OARC 38 Call for Contributions
OARC 38 will be a two-day hybrid meeting held on July 30th and 31st, 2022 starting at 10 am (Eastern). The onsite part of the meeting will be co-located with IETF 114 (Philadelphia). The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT As it is an hybrid workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). **Workshop Milestones:** 2022-05-01Submissions open via Indico 2022-06-20Deadline for submission (23:59 UTC) 2022-06-21Initial Contribution list published 2022-06-28Full agenda published 2022-07-12Deadline for slideset submission and Rehearsal 2022-07-30OARC 38 Workshop - Day 1 2022-07-31OARC 38 Workshop - Day 2 The Registration page and details for presentation submission are published at: https://www.dns-oarc.net/oarc38 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. Additional information for speakers of OARC 38: * your talk will be broadcast live and recorded for future reference * your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting * Remote speakers have mandatory rehearsal on 2022-07-12 at 15:00 UTC. It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via John Todd, for the DNS-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.) -- John Todd - jt...@quad9.net General Manager - Quad9 Recursive Resolver
Re: Certificates for DoT and DoH?
On 28 Feb 2022, at 7:11, Bill Woodcock wrote: >> On Feb 28, 2022, at 3:29 PM, Bjørn Mork wrote: >> Any recommendations for a CA with a published policy allowing an IP >> address SAN (Subject Alternative Name)? >> Both Quad9 got their certificate from DigiCert: >> >>Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 >> 2020 CA1 >>Subject: C = US, ST = California, L = Berkeley, O = Quad9, CN = >> *.quad9.net >>X509v3 Subject Alternative Name: >>DNS:*.quad9.net, DNS:quad9.net, IP Address:9.9.9.9, IP >> Address:9.9.9.10, IP Address:9.9.9.11, IP Address:9.9.9.12, IP >> Address:9.9.9.13, IP Address:9.9.9.14, IP Address:9.9.9.15, IP >> Address:149.112.112.9, IP Address:149.112.112.10, IP Address:149.112.112.11, >> IP Address:149.112.112.12, IP Address:149.112.112.13, IP >> Address:149.112.112.14, IP Address:149.112.112.15, IP >> Address:149.112.112.112, IP Address:2620:FE:0:0:0:0:0:9, IP >> Address:2620:FE:0:0:0:0:0:10, IP Address:2620:FE:0:0:0:0:0:11, IP >> Address:2620:FE:0:0:0:0:0:12, IP Address:2620:FE:0:0:0:0:0:13, IP >> Address:2620:FE:0:0:0:0:0:14, IP Address:2620:FE:0:0:0:0:0:15, IP >> Address:2620:FE:0:0:0:0:0:FE, IP Address:2620:FE:0:0:0:0:FE:9, IP >> Address:2620:FE:0:0:0:0:FE:10, IP Address:2620:FE:0:0:0:0:FE:11, IP >> Address:2620:FE:0:0:0:0:FE:12, IP Address:2620:FE:0:0:0:0:FE:13, IP >> Address:2620:FE:0:0:0:0:FE:14, IP Address:2620:FE:0:0:0:0:FE:15 >> >> Does this mean that DigiCert is the only alternative? > > I assume not, but we’d already used them for other things, and they didn’t > have a problem doing it, so we didn’t shop any further. Update to Bill’s comments: They were the only CA at that time who would include IPv6 addresses in the signature, so it actually was a simple decision but for a different reason. We’re happy with how it’s working with them. For a few niche cases like recursive DNS, v6 signing is required, and Digicert went out of their way to implement that v6 ability. Thanks to them for making it available to what is probably a very small group of potential customers - they deserve some credit for making the technical effort and product decision. >> And do they really have this offer for ordinary users, or is this also some >> special >> arrangement for big players only? > > No, we didn’t have to do anything special, to the best of my knowledge. Nothing “special” meaning there is no custom business relationship, but it did take time and having a highly capable and persistent team here at Quad9 who could track the request through the process and get it done successfully, and for Digicert to work to create a process that wasn’t entirely customized. While I can’t speak for Digicert, I would suspect v6 address signing is still not entirely “off the shelf” or in the best case it is “barely off the shelf” for ordering on the website but it is a product they can reliably deliver if you talk to someone there. >> That does make me wonder how they verify that I'm the rightful owner of >> "sites, IP addresses, common names, etc.". In particular, "etc" :-) >> Or you could ask yourself if you trust a CA with such an offer... [snip] To validate that the addresses were “ours” or at least under our control, there were still some hoops to jump through other than the standard validation of registry data. For example, we had to activate web servers and objects on our anycast network to answer specific queries during some of the check processes. TL;DR: Digicert is still the only player for v6 signing, and it will not be entirely hands-free to manage but also not overly difficult. JT -- John Todd - jt...@quad9.net General Manager - Quad9 Recursive Resolver
Re: Authoritative Resources for Public DNS Pinging
I think it would be fair to say that ICMP echo to easy-to-remember internet resources is tolerated, but not encouraged, and is probably not a good idea unless one knows and very well understands the implications of failure (or success!) modes that don’t match the conditions that are expected. Terrible monitoring is easy; good monitoring is quite difficult. It is reasonable to expect operators of systems designed for one type of service to quickly rate-limit or entirely filter non-critical alternate capabilities in the event of resource exhaustion or other type of risk to the primary service - this applies to web severs, DNS servers, NTP servers, etc. Also, choosing as an indicator a response from a protocol such as ICMP echo/reply which has had a historical risk of flooding attacks and which may have rapid clamping of traffic seems to be also a large check mark in the “do not use” column. ICMP echo stands real risks of not providing expected results for reasons that are known only to the target operator, and which do not take your non-obvious intentions into consideration. More central to the issue: “The Prudent Mariner never relies solely on any single aid to navigation” (hi, Ken!) is an applicable quote here. Nothing is immune from interruption of service, especially as it becomes more distant from your administrative control. I see all too often people using ICMP to a nameserver, or a query to a nameserver, or a socket request to port 80 of some well-known name as the only method utilized for determining if a larger set of systems are available. This is not typically a good idea. I shudder to think what would happen if certain well-known domains were to be unavailable due to one of a dozen different potential failure cases. There are far too many poorly-written stacks that assume some singular conditions are “impossible” unless as a result of local failure, and that always ends in sadness and late nights spent writing root-cause analysis reports. Further adding to this complexity is the benefit or detraction of anycast for many of these larger public services. What is “up” and what is “down”? What is the signal generated or inferred by presence or absence of this monitoring sample? The question typically generates lively debate within a network or monitoring team. I am pretty sure that “But I could ping x.x.x.x” is not typically a statement that has much weight when considering overall reachability. I do admit it is a hint, but not the answer, for many network conditions, but probably not by itself should any system consider that result canonical for anything other than that exact result. If one is going to use responses of exterior (not within the same organizational control) services as an indicator of reachability, then a broad spectrum of tests are probably the only way to have anything approaching certainty or knowledge upon which action could be based, and even that will always have a shadow of a doubt. In that mix, ICMP echo/reply to public nameservers is probably not the best indicator to add in a monitoring suite, though it may appear to be perfectly OK… until it isn’t. DNS queries to DNS servers seems to be the most reasonable thing to use as test material, rather than ICMP, if one were building a rickety monitoring house out of the resources at-hand. Additionally: The suggestions of building some new ICMP-responding service may end up being counter to the goals of the people using external tests, so careful what is wished for. Witness everyone installing various “speed testing” servers in their own networks, which may not truly provide accurate measurements of anything other than local loop speeds, which now sort of defeats the purpose of the speed test for anything other than the most local set of results. JT -- John Todd - jt...@quad9.net General Manager - Quad9 Recursive Resolver On 8 Feb 2022, at 9:56, Mike Hammett wrote: Yes, pinging public DNS servers is bad. Googling didn't help me find anything. Are there any authoritative resources from said organizations saying you shouldn't use their servers for your persistent ping destinations? - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP
Re: DNS-OARC 37 Call for Presentations
The Program Committee has decided to extend the Call for Contributions until 17 Jan 2022 23:59 UTC. The OARC Board has decided that OARC 37 will be a one day hybrid conference. Thank you if you've already submitted a proposal. We still haven't filled the capacity and are able to accept more content. Please note that remote participation is actively supported. Revised Workshop Milestones: * 27 December 2021 - Submissions open via Indico * 17 January 2022 - Deadline for submission (23:59 UTC) * 19 January 2022 - Initial Contribution list published * 21 January 2022 - Full agenda published * 3 February 2022 - Deadline for slideset submission and Rehearsal * 17 February 2022 - OARC 37 Workshop ( One day conference) The details for presentation submission are published at the Workshop website: https://www.dns-oarc.net/oarc37 If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via John Todd, for the DNS-OARC Programme Committee -- John Todd - jt...@quad9.net - +1-415-831-3123 General Manager - Quad9 Recursive Resolver
DNS-OARC 37 Call for Presentations
OARC 37 will be a online/hybrid meeting on February 17th and 18th, 2022 starting at 16:00 UTC (10:00 CST). The onsite part of the meeting will be held in Austin, Texas. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: Managing DNS changes and propagation, release process, change management. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: Managing service capacity, failovers, disaster recovery. As it is an online/hybrid workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). **Workshop Milestones:** * 27 December 2021 - Submissions open via Indico * 10 January 2022 - Deadline for submission (23:59 UTC) * 11 January 2022 - Initial Contribution list published * 18 January 2022 - Full agenda published * 3 February 2022 - Deadline for slideset submission and Rehearsal * 17 & 18 February 2022 - OARC 37 Workshop The Registration page and details for presentation submission are published at: https://www.dns-oarc.net/oarc37 DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups at DNS-OARC. See the registration page for details. 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. Additional information for speakers of OARC 37: * your talk will be broadcast live and recorded for future reference * your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting * you will be expected to attend a rehearsal on 3rd February 2022. It would be very useful to have your slides (even if draft) ready for this. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via John Todd, for the DNS-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.) -- John Todd - jt...@quad9.net General Manager - Quad9 Recursive Resolver
Re: PCH.net questions and thoughts - Re: Prefix hijacking by AS20115
Since it’s come up on the list and we haven’t given a public update recently, I thought I’d just write a quick note on the state of INOC-DBA. For those who aren’t familiar with it, INOC-DBA is a SIP-based hotline communications system between NOCs and CERTs: https://www.pch.net/services/INOC_DBA https://en.wikipedia.org/wiki/INOC-DBA PCH has been the secretariat for INOC-DBA for the past thirteen years as a function of our not-for-profit purpose, serving network operators. During that time, the INOC-DBA back-end and self-provisioning systems have been completely replaced three times, and we’re currently at work on moving from the SER-driven 3.0 series of releases to a more modern BE7k-driven 4.0 system. Because INOC-DBA has only been intermittently directly grant-funded, sometimes, like now, it is funded entirely out of our overhead budget, so progress can be slow. The consequence is that, in order to make headway on the 4.0 transition, we’ve had to move people off of active support of the old 3.0 self-provisioning system. So, it’s fine for people who are already using it, but there’s not currently a way to create a new user within the 3.0 system, nor for existing users to make significant changes to call routing. ASNs have proven to be a good identifier, allowing network operators to communicate with each other in a way that’s vetted, while avoiding putting PCH in the position of judging who qualifies to join and who doesn't. Whether you know the name of a network, or where it’s located, or even what timezone they’re in, you know them by their ASN. And a hotline system that bypasses directories and receptionists and escalation chains is a quick and low-friction way of reaching someone who has the authority and access to resolve a problem. While email is the most venerable and well-known communication method it is often filtered, missed, or funneled through helpdesks that don’t have sufficient clue, or are stymied by dealing with someone who isn’t one of their own customers. Facebook and general-purpose chat systems are less than ideal as well, as they’re un-vetted and quickly suffer the same fate as email: if they’re paid attention to at all, filters or automated systems are put in place to block the noise. So, a closed network for voice, video, presence and chat has proven to be an immediate, low-noise way for those network operators who choose to use it, to communicate with each other. In the 4.0 system, XMPP chat using the same identifiers in the same closed network is a natural extension and the new feature that, though hardly revolutionary, we’re most looking forward to releasing. The technical issues that were discussed in this thread about NAT/PAT problems are certainly valid, but can be circumvented in a number of different ways, some of which are addressed in our documentation. SIP and RTP can work through NAT if correctly configured in simple circumstances, or in the presence of a NAT-traversal server, such as is included in INOC-DBA. An organization may have multiple INOC-DBA users and opt to have a SIP-capable system at the border of their network with one side facing the public Internet, and one side facing their private network, and which manages call flow and media handling (Asterisk, Freeswitch, or any one of a number of free or commercial SIP PBX-like systems will do this fairly easily; again, there are tutorials in our documentation). This also allows after-hours routing to PSTN lines or to call groups as needed, controlled by a local administrator. We also have considered keeping the media path through our servers, which aids the NAT traversal issue while not precluding local SIP enclaves as described above. One of the things that we struggle with is maintaining an appropriate balance between, on the one hand, keeping the network operations community informed of the status of the system, so they don’t feel compelled to ask on NANOG, versus not pro-actively over-sharing on lists and making a nuisance of ourselves. Admittedly, if the 4.0 transition were going faster, this would be less of an issue. So, we’re glad of the continued interest (particularly in the NANOG community, where INOC-DBA is not as widely used as in, for instance, the LACNIC community), and we apologize for the slow transition to the new 4.0 back-end and self-provisioning system. As always, you can contact us directly about INOC-DBA related stuff on opera...@pch.net JT --- John Todd - jt...@pch.net - +1-415-831-3123 On 29 Sep 2015, at 8:05, Bob Evans wrote: Nice of you to check Jim. This brings up the old idea - A long time ago I had an INOC phone by PCH.NET - It never rang, as we filter our outbound with detail everywhere we announce. ISPs need to provide us their address list. And the few times I needed to use it , no one ever answered. ( It was a decade ago before NANOG membership.) So after a while I too
Re: Whats' a good product for a high-density Wireless network setup?
On 20 Jun 2015, at 9:37, Sina Owolabi wrote: I'd be grateful for any information on how to calculate for large scale wifi deployment [snip] While it is vendor specific (and therefore subject to certain biases) I’ve found the Aruba VRD (Validated Reference Design) documentation fairly clear and applicable to many high-density environments. It covers theory, planning, and engineering. http://community.arubanetworks.com/t5/Validated-Reference-Design/Very-High-Density-802-11ac-Networks-Validated-Reference-Design/ta-p/230891 I’m certain that Cisco, Xirrus, Ruckus, Ubiquiti, Areohive, etc. also have papers on the topic that (hopefully) have the same basic theory concepts applied to their specific configuration syntax and special sauces. I’ve had good experiences with Aruba with high-density auditorium usage on several occasions, though I tend to turn off some of the proprietary features to keep things simple. There are also some less-formal slide decks on the same topic from Aruba that are a bit redundant but more conversational: http://www.wlanpros.com/wp-content/uploads/2014/03/Ultra-High-Density-WLAN-Design-Deployment-Chuck-Lukaszewski.pdf http://community.arubanetworks.com/aruba/attachments/aruba/tkb@tkb/86/3/2012%20AH%20Vegas%20-%20WLAN%20Design%20for%20High%20Density.pdf JT
ATT's blue network SMS-SMTP off the air
To those of you who may rely upon ATT to deliver your email-to-SMS messages for monitoring: some of you may be currently out of luck. I would just send this to the outa...@puck.nether.net list, but it does seem to be a meta-network failure in that for better or worse many of us use SMS as a method to monitor outages, so this perhaps moves it up a notch in the importance hierarchy enough to warrant a NANOG post. I am experiencing failures on my email transmissions to my older blue (aka: Cingular) ATT devices at the moment, for both incoming and outgoing. Many of you may be using older blue cards in your NOC phones, SMS gateway devices, or perhaps even your personal mobile devices for those of you who still live in the dark ages of phones that aren't [2.5,3,4,x]G capable. I am unable to diagnose the problems fully, but at least some (if not all) of the SMS-to-email gateway failures are due to mmode.com's MX hosts (in the airdata.com zone) being unreachable due to absence of functioning authoritative resolvers for that zone, and possibly other failures as well. This appears to be causing 550 Access Denied messages being returned to my mobile devices that are sending to email addresses, and mail spooling on my Internet SMTP hosts that are trying to send to the npaxxxy...@mmode.com addresses for SMTP-to-SMS relay. There is a rumor that this is NOT related to the deactivation of the downloads components of the blue network on the 15th, but I suspect that someone just decided to pull the plug on everything. Reading to the end of the thread below, there is someone who states ATT claims it will be back online by the evening of the 17th at the surprisingly accurate time of 9:55 PM (timezone unstated.) More speculation: http://forums.wireless.att.com/t5/mMode/URGENT-mmode-down-again-Their-mta01-cdpd-airdata-com-mail-server/td-p/1939480 I don't know if this is causing problems with anyone using TAP interfaces, or with any of ATT's other SMTP-SMS gateway services like @txt.att.net. SMS, and mobile devices in general, are a single point of failure for contacting on-call staff for various problems - perhaps it's time to insist that everyone carries two mobile devices, on different frequency and technology platforms, with different carriers, and split messages to both due to the anecdotally increasing failure rates of mobile networks. Conspiracy theories of how collusive unreliability would increase ARPU across the board for all carriers would be interesting to hear... but not in this forum, I suspect. :-) JT
Re: How common are wide open SIP gateways?
On Feb 5, 2010, at 1:27 PM, Scott Howard wrote: On Fri, Feb 5, 2010 at 9:45 AM, David Birnbaum dav...@pins.net wrote: We have noticed a lot of issues with Asterisk 1.2 and some 1.4 rollouts. FreePBX had some truck-sized holes in it. Most/all of the big issues that existed in previous version of Asterisk/FreePBX have been resolved in later releases. The majority of the stolen SIP cases I've heard of have come down to brute forcing of often very insecure passwords - quite often stupid insecure passwords like the same as the username. And of course the username itself is normally the extension, which makes is relatively easy to guess (if 100 doesn't exist, then 200 or 1000 probably does, etc). Then there's the issue of unencrypted/unsecured phone provisioning files, complete with SIP usernames/passwords, hosted on internet webservers - often with the only security being your ability to guess the MAC address... On our relatively small client base, we are seing SIP probing on more or less a non-stop basis, and some of our customers have been hacked over the Presuming you're running Asterisk, fail2ban can help. The only real issue I've had with it is that many softphones will repeated try to register if you get the password wrong, so a user entering their username/password even only once will get them blocked for X minutes. Scott I'll second Scott's comments, and add a few. SIP servers aren't much good unless they're wide open, if you're serving to a large number of diverse users whose networks you do not control with a VPN or a customized client. This invites probing to determine identity choice weakness. It seems that new SIP servers are discovered within about 5 days of being put up without filtering, at least looking at my logs. The most commonly-available toolset for such attacks seems to have moved SIP attacks into script-kiddie land about a year and a half ago. The tool has three functions: scan for SIP servers (UDP 5060), identify SIP identities via login failure or other error message information leakage, and lastly guess passwords in brute-force manners on those identified SIP extensions. The attacks seem to be geographically diverse - I've seen originations both in North America as well as non-NA origins, though the ultimate origin is often a mystery due to compromised servers being used for probe sweeps. The attacks also seem to have a variety of purposes. The four that I've most commonly seen are: 1) Experimenting, joy riders. 2) Attacking to obtain free international long distance 3) Attacking to obtain access into the PBX network with fraudulent identity to perform fraudulent internal activity (This is Bob from accounting...) 4) Attacking to create large numbers of domestic calls for phishing scams (This is your bank. Please enter your credit card number now.) Of these, #4 seems to be the only one that gets significant attention of LEA resources. I wrote some notes for security basics on this a while back as it pertains to Asterisk in particular, but the problem remains with some very old installations that accept inbound calls into the default Asterisk context (which is not a bug, but really a configuration error) or it crops up anew with administrators who do not adequately create sufficiently random SIP identities and passwords. Asterisk is fairly robust against such attacks, but often the flexibility of a complex system allows administrators to inadvertently expose themselves in ways they wouldn't ordinarily think about. More here: http://blogs.digium.com/2009/03/28/sip-security/ As far as network impacts: some of these probes are fairly significant in bandwidth consumption (3-5 mbps, from what I've seen) and may cause problems with whatever your SIP authentication method is due to the volume of requests. A distributed attack at higher volumes has less chance of success because most SIP platforms do not have the ability to respond to high volumes of requests anyway. Fail2Ban can be implemented on most SIP platforms at the application level, and works quite well against most probe methods. I can't even comment on the issue of unencrypted/unauthenticated provisioning servers. If you're provisioning in an unauthenticated way across the big internet, then... well, you takes yer chances. Lastly: SIP is very flexible in handling alternate ports for communications in URIs or other pointers, though I have never seen a SIP server using anything other than 5060/5061. Perhaps related, I've never seen a suspicious system probing on 5060 looking at any other ports. Maybe changing ports would siipmly solve problems pretty quickly for people seeing attacks who have some ability to influence/ configure their end devices or trunking peers. (At least, for a little while. Remember: when chased by a bear, you just need to be faster than the guy behind you.) JT
Re: SMS
On Sep 22, 2009, at 9:29 AM, William Herrin wrote: On Tue, Sep 22, 2009 at 11:59 AM, Scott Berkman sc...@sberkman.net wrote: [snip] I believe there was another solution that involved direct carrier connections, but these are most likely cost prohibitive in most situations. Any pointers on this would be greatly appreciated. I have a need for geographically redundant access to the same phone numbers in order to send and receive SMS messages. Even if I have to buy a pair of T1s that are 99.9% idle, it'd be worth it. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 This question frequently arises on the VoIP/Asterisk lists, since it is a question that VoIP service providers often wish to answer - How do I SMS-enable my VoIP customer numbers? In other areas of the world, SMS is much more easily tied into existing voice networks - in the UK (among others) for instance, SMS is possible over PRI connections, which enables land lines to send and receive SMS messages. Clickatell, the company referenced previously, is based in South Africa. Buying their service for delivery of SMS into North America means that your messages will be sent with a generic short-code, which is not guaranteed and has in the past even been blocked by carriers. Users cannot reply to those messages, because many other companies are using the same short code return address. If you look at their website, you'll see that if you live in one of a few non-NA nations, you can buy an actual phone number (not a short code) which can be used for high-volume bidirectional communication via SMS. Here in North America, we're basically out of luck unless you hack together a hardware-based SMS device, and even that may be not reliable since carriers explicitly state that their accounts cannot be shared, and a large number of SMS messages to/from a particular account may cause it to be disconnected without warning. It appears to me that carriers have taken the stance that SMS should be for infrequent messages between actual fingers (no automation allowed!) or via short codes, and short codes involve a significant amount of cost, configuration, and even arbitrary approvals from the carriers on the use of a short code. If you look at the form required for a short code request, you'll discover that it's not for generic use - it's geared entirely for ad campaigns. A few years ago I tried searching for SMS-enabled SIP telephone numbers (DIDs) and found that there was a new service available, but the monthly price floor was pretty steep. I still have not met anyone actually offering the service, but I'm sure there must be resellers of it by now. It was Level 3, offering SIP trunks with DIDs on them. Another company, Syniverse, was then SMS-enabling those numbers in an exclusive agreement. Payment had to go to each company, separately. The costs per number to enable SMS were fairly low, and the costs for message transmission were fairly low, but the Level 3 minimum purchase price was quite high (imagine that you could buy a nice sports car every month with the minimum payment.) I have no idea if this service is still available, or how successful it's been. If anyone now has direct experience with a reseller or small distributor of this service, let me know - I'm still looking for a SIP- capable DID that can handle SMTP/SMPP/XML-HTML transmission of SMS messages with some decent volume (200-1000 messages per day.) Here's a message in a thread from a while back on this topic which has some pointers: http://lists.digium.com/pipermail/asterisk-users/2008-October/220726.html JT --- John Todd email:jt...@digium.com Digium, Inc. | Asterisk Open Source Community Director 445 Jan Davis Drive NW - Huntsville AL 35806 - USA direct: +1-256-428-6083 http://www.digium.com/
Re: TRIP deployment?
[sorry for late reply - .us Thanksgiving plus LIFO mailing list reading creates posting latency] On Nov 24, 2008, at 9:20 AM, [EMAIL PROTECTED] wrote: I'm not sure if this is the right mailing list for this question: how widely is TRIP (Telephone Routing over IP [RFC3219]) deployed / used in current networks? There was a reference stack made in the Vovida package for TRIP, but in my experiments with it a number of years ago I was unable to implement it in any satisfactory way, and the code was far from complete. There was a TRIP commercial implementation in the Acme Packet SBC (Session Border Controller) equipment, and one in the Jasomi SBC IIRC, but I don't know what the status of those two stacks is today or if anyone uses them. I've never seen TRIP offered as a peering method in any exchange of any sort, so the short answer to your question as far as I know is There is no significant use of TRIP today. This is a shame, since it seems like it would be useful. My belief is that there are significant economic dis-incentives for E.164 interconnection that are easily implemented and which create fluid, low-cost (or zero-cost) marketplaces for minutes, and I will not discuss the obvious opponents to such marketplaces. E.164-based ENUM is another casualty of that economic structure as it is inextricably linked to political decisions. There are additional problems with large-scale distributed routing of E.164 numbers as the trust model for number ownership is difficult to manage (the root cause of so many problems) and routing failures are much more operationally painful and difficult to resolve during unexpected failures. I'd be happy to be proven wrong on my assumption that TRIP is not used - does anyone have evidence of TRIP being used in readily-joinable federations, either in conjunction with geographic layer 3 peering fabrics or otherwise? Despite the failure of TRIP to catch on, there was some use that has come out of RFC3219 (TRIP). The ITAD concept, which defines an IANA- allocated unique identifier to telephony entities in other use cases. An ITAD is much like an ASN, except 32 bits, and currently zero-cost. The freenum.org project uses ITADs as part of a lookup mechanism based on ENUM-like DNS methods, in effect creating a phone keypad-friendly, IP communications-focused alternative to the normal E.164 phone numbers that are the standard for PSTN dialing. This moves quickly out of typical NANOG charter areas, but is worth mentioning as ITAD resources are being used to uniquely identify worldwide telephony networks that are layered on top of existing IP networks. As of 2008-12-03, the ITAD number space of the next assignment block will cross into the four-digit range. (full disclosure: I manage the Freenum project, so I'll be biased and suggest that anyone who manages any sort of IP-based telephony system with public inbound SIP capability should examine this - it's trivial to set up.) Other routing or routing-like protocols for telephony you might find interesting include OSP (Open Settlement Protocol), DUNDI (Distributed Universal Number DIscovery), and ENUM (ENUM). Each protocol has niche areas in which they are used for different purposes, but none have been overwhelmingly successful in a public setting, though ENUM has been very successful in private interconnects and mildly successful in some locations which have enlightened and technically educated national regulators. North America is not implementing ENUM in any public manner at this time to my knowledge. References: http://www.freenum.org/ http://www.ietf.org/rfc/rfc3219.txt http://www.iana.org/assignments/trip-parameters/ http://www.vovida.org/protocols/downloads/trip/ (death via Cisco?) http://www.voip-info.org/wiki-DUNDi http://www.voip-info.org/wiki-OSP http://www.voip-info.org/wiki-ENUM JT
Re: hosted PBX/VOIP thru VPN?
On Nov 11, 2008, at 6:17 PM, Lorell Hathcock wrote: All: My customer wants to try to improve performance to his ATAs by creating a VPN from his network to the VOIP provider's network through the internet. I have to admit, the idea caught me flat footed. At the outset, it seems like we would want to do it just to improve security for end users. However, my customer wants it because he thinks it will improve performance (i.e. voice quality). We are suffering from poor VOIP quality due to the Sprint / Cogent depeering and subsequent squirming by our vendors. The only reason I can think that VOIP thru a VPN would help is that *perhaps* routers in the middle on ASNs I have no control over *may* prioritize VPN traffic higher than regular traffic. They opposite could also be true. Specifically the ASNs in the middle are Level 3, Sprint and Time Warner. Thoughts? Should I try to dissuade him from this if performance is his main motivator? The implementation of a VPN indeed would probably not result in an improvement of your customer' RTP packet delivery, either for jitter or packet loss. If you wish to see if RTP is being meddled with, try changing the RTP port numbers on the ATA or on the remote side to something less typical of the RTP port range - try something 1. While some deep-packet inspections will dig through each packet to categorize and stomp on RTP voice audio, it is probably not the case that anyone in the path you describe is applying anything other than port number and protocol (UDP/TCP) inspections, if they are doing any such punitive QOS at all. I would be very interested to learn if you or anyone does know of a transit carrier who is de-pref'ing RTP packets as a peered transit provider (or non-paid peering partner.) This doesn't mean static end customers - I'm really talking about traffic that is ingress/egress from some other ASN, even if that ASN is paying for transit. This would be a fairly major departure from any type of QOS or de- preferencing that I've seen before, and I'm sure the list would be interested in any results as well. The root cause of the problem your customer describes also needs to be identified - that will tell you a lot. Wireshark a few calls and see what you can see on the RTP packet path. Without more specifics on the bad performance, it will be difficult to determine if this is even a network issue at all - maybe it's just a sub-standard ITSP, gateway, or even PSTN path on the far side of the equation. A very slight chance exists that due to round-robin routing you are getting out-of-order packets in one or both directions of the media stream. RTP does not recover well from OOO packets. Try some traceroutes in the RTP port range to see what happens. You can see one direction for the traceroute UDP outbound and watch for multi- pathing, and you can see the other direction with wireshark on inbound OOO RTP streams to your customer. If the problem is out-of-order RTP packets, then there are some things that a GRE tunnel plus some creative route announcements/static routes might be able to solve, and those are left as an exercise for the reader. But a VPN is almost always going to be the wrong answer for VoIP performance increases - GRE is better suited for encapsulating UDP, and I run VoIP connections over GRE all the time due to the perverse and unfortunate routing situation for my home network, which resides at the end of a consumer- grade cable IP connection. I would not recommend even GRE as a matter of course for VoIP RTP transport; I merely say that it is possible, and in some fringe cases the only solution available. FWIW: Snom (a SIP-based desk phone) now includes a built-in IPSEC tunnel protocol stack so the phone can securely establish connections back to the PBX or other endpoints. The reasons for doing this are not clearly not performance-oriented - they are security-oriented. It even will encapsulate traffic from any hosts attached to the one-port switch on the back. Desk phones are getting pretty scary. I'm waiting for sh ip bgp for my Cisco 7960... http://wiki.snom.com/VPN http://www.snom.com/en/products/snom-370-voip-phone/ JT
