Call for Nominees - 2011 OARC Board of Directors

At the upcoming AGM DNS-OARC members will be electing two directors for its board of directors.

We are looking for nominations for candidates willing to serve a two-year term on the Board and contribute to the continued growth of OARC. The Board meets monthly, by teleconference, to review DNS-OARC operations. We expect our directors to actively contribute to the various ongoing, email based, discussions and provide feedback as needed.

An ideal candidate will be one with the business experience to help formulate strategy and guide the policy that drives DNS-OARC. To be eligible, a candidate must be from an DNS-OARC Member in good standing.

Submitted by wayne@dns-oarc.net on Tue, 2011-08-09 17:12. categories [ ]

DNS Operations Trust Group

Dear colleagues,

I am pleased to announce the formation of the DNS-OARC DNS Operations
Trust Group. This group is an evolution of a previous secure
operations mailing list and is intended to enable and encourage secure
exchange of operational information about the DNS for the purpose of
promoting and improving the security and stability of the global DNS.
New participants will be vetted by the existing membership with the
intent to produce a group with the greatest level of trust possible.
The new platform this trust group resides on has much better
mechanisms for vetting members and managing the list members, which we
believe will lead to better communication for everyone involved.

The trust group's scope is the identification, discussion, and

Submitted by mlarson@dns-oarc.net on Mon, 2011-06-13 21:02. categories [ ]

The 2011 Workshop on DNS Health and Security

DNS-OARC is pleased to announce our involvement in the DNS EASY 2011 conference being held this fall in Rome. Focusing on Security, DNS EASY 2011 does not replace our traditional fall workshop and AGM (which will be announced soon) but serves provides specific focus for a broader audience than is typical for DNS-OARC workshops.

The 2011 workshop on DNS HEALTH & SECURITY (DNS EASY 2011) October 18-20, 2011
GCSEC headquarters
Rome, Italy

http://dnseasy.gcsec.org

A joined event GCSEC - ICANN - DNS-OARC

SCOPE

Submitted by wayne@dns-oarc.net on Mon, 2011-06-13 20:02. categories [ ]

IPv6-Day DITL Data Collection

A Day in the Life of the Internet is a large-scale data collection project undertaken by CAIDA and OARC every year since 2006. In addition to the recently completed 2011 collection, DNS-OARC is sponsoring a IPv6-Day collection. If you would like to participate by collecting and contributing DNS packet captures, please subscribe to the DITL mailing list.

Participation Requirements

Submitted by wayne@dns-oarc.net on Fri, 2011-05-13 14:19.

2011 DITL Collection

The 2011 DITL data collection has been completed.

We are pleased to have collected 7TB of data from 22 participants. This years dataset includes 51,460,040,025 queries and is available to DNS-OARC members for analysis.

Participant Queries
a-root 3100056869
afilias 2768893087
afrinic 595595831
apnic 5461740647
as112-yow 123432737
c-root 4054871929
cznic 689322420
d-root 2767857591
e-root 1924833681
f-root 3671672555
h-root 2545855790
j-root 4581118378
l-root 2092120590
m-root 2989158432
nethelp 1105480300
niccl 177633332
nominet 1742248215
nzrs 87964802
ripe 10806874217
tix-or-tz 44340541
uninett 43468341
wide 85499740

A coverage map is available.

Our thanks goes out to Duane Wessels and Geoff Sisson for managing the collection process.

Submitted by wayne@dns-oarc.net on Mon, 2011-04-25 16:43. categories [ ]

DITL 2011 Data Collection

A Day in the Life of the Internet is a large-scale data collection project undertaken by CAIDA and OARC every year since 2006. This year, the DITL collection will take place in April. If you would like to participate by collecting and contributing DNS packet captures, please subscribe to the DITL mailing list.

Participation Requirements

There are no strict participation requirements. OARC is happy to accept data from members and non-members alike. You will need a login from OARC to submit data and OARC will need your ssh public key. Contact OARC Admin if you need to setup or update your login or ssh keys. If you are not an OARC member, you may want to sign a Proprietary Data Agreement with us, but this is not required.

In terms of data sources, we are always interested in getting a lot of coverage from DNS Root servers, TLD servers, AS112 nodes, and "client-side" iterative/caching resolvers.

Types of DNS Data

Most of the data that we collect for DITL will be pcap files (e.g., from dnscap or tcpdump). We are also happy to accept other data formats such as BIND query logs, text files, SQL database dumps, and so on. We have an established system for receiving compressed pcap files from contributors. If you want to contribute data in a different format, please contact us to make transfer arrangements.

Pre-collection Checklist

  • Please make sure that your collection hosts are time-synchronized with NTP. Do not simply use date to check a clock since you might be confused by time zone offsets. Instead use ntpdate like this:
    $ ntpdate -q clock.isc.org
    server 204.152.184.72, stratum 1, offset 0.002891, delay 0.02713
    

    The reported offset should normally be very small (less than one second). If not, your clock is probably not synchronized with NTP.

  • Be sure to do some "dry runs" before the actual collection time. This will obviously test your procedures and give you a sense of how much data you'll be collecting.
  • Carefully consider your local storage options. Do you have enough local space to store all the DITL data? Or will you need to upload it as it is being collected? If you have enough space, perhaps you'll find it easier to collect first and upload after, rather than trying to manage both at the same time.

Collecting Data with dnscap

If you don't already have your own system for capturing DNS traffic, we recommend using dnscap with some shell scripts that we provide specifically for DITL collection.

  1. Download the most recent version of dnscap.
  2. Note that dnscap does not require libbind, unless you want to use the -x or -X options.
  3. Run ./configure, make and then 'make install' as root. This installs dnscap to /usr/local/bin.

Next download the ditl-tools package, where we provide scripts for using either (dnscap) or (tcpdump and tcpdump-split). In most cases dnscap should be easier. The tcpdump method is included for sites that would prefer it or cannot use dnscap for some reason.

Note that the settings.sh configuration file described below includes variables for both dnscap and tcpdump. Some variables are common to both, while some are unique to each. By default these will store pcap files in the current directory. You may want to copy these scripts to a different directory where you have plenty of free disk space.

  1. Copy settings.sh.default to settings.sh.
  2. Open settings.sh in a text editor.
  3. Set the IFACES variable to the names of your network interfaces carrying DNS data.
  4. Set the NODENAME variable (or leave it commented to use the output of `hostname` as the NODENAME). Please make sure that each instance of dnscap that you run has a unique $nodename!
  5. Set the OARC_MEMBER variable to your OARC-assigned name. Note that the scripts automatically prepend "oarc-" to the login name so just give the short version here.
  6. Note that the scripts assume your OARC ssh upload key is at /root/.ssh/oarc_id_dsa.
  7. Look over the remaining variables in settings.sh. Read the comments in capture-dnscap.sh to understand what all the variables mean.

Here is an example customized settings.sh file:

# Settings that you should customize
#
IFACES="fxp0"
NODENAME="lgh"
OARC_MEMBER="test"

#START_T='2011-04-12 11:00:00'
#STOP_T='2011-04-14 13:00:00'

When you're done customizing the settings, run capture-dnscap.sh as root:

$ sudo sh capture-dnscap.sh

When its time to do the actual DITL data collection, please uncomment the START_T and STOP_T variables in settings.sh and run the scripts from within a screen session.

Collecting Data with tcpdump and tcpdump-split

Another collection option is to use tcpdump and our tcpdump-split program. The instructions are similar to the above.

  1. Download and install the ditl-tools package (see link above).
  2. Copy settings.sh.default to settings.sh and bring it up in a text editor
  3. Set the IFACES variable to the single network interface to collect DNS data from.
  4. Set NODNAME
  5. Set OARC_MEMBER
  6. Set DESTINATIONS if desired

Start the capture with:

$ sudo sh capture-tcpdump.sh

Uncomment the START_T and STOP_T and use screen when its time for the real deal.

Contact

Contact the OARC Admin with any questions about DITL 2010.

Submitted by wayne@dns-oarc.net on Fri, 2011-04-08 12:04.

Deployment of DNSSEC in the Root Zone: Impact Analysis

On January 27, 2010, ICANN and Verisign began a phased rollout of DNSSEC in the root zone. DNS-OARC was contracted by ICANN to co-ordinate data collection from the root zone servers during the rollout and to provide analysis of three key changes: changes in reply sizes, potential signs of path MTU issues, and changes in TCP query rates.

DNS-OARC collected data from nine distinct phases of the rollout including pre and post rollout baselines, the six phased introductions of the DURZ across the root-servers, and, finally, for a period surrounding the July 15th distribution of the validatable, production, signed root zone and the publication of the root zone trust anchor.

This activity resulted in 17.4 TB of compressed pcap files which are available to DNS-OARC members for further research and analysis.

Some of the data has been presented at various conferences and here on the website but we are pleased to announce the availability of the final report.

Deployment of DNSSEC in the Root Zone: Impact Analysis

Submitted by wayne@dns-oarc.net on Tue, 2011-03-08 14:32. categories [ ]

Call for Nominees - 2010 OARC Board of Directors

Now that we have venue and accommodations confirmed for our Fall Workshop in Denver, our attention switches to the AGM and the elections for the Board of Directors.

DNS-OARC has two seats on the board which are up for election this year. We are looking for nominations for candidates willing to serve a two-year term on the Board and contribute to the continued growth of OARC. The Board meets monthly, by teleconference, to review DNS-OARC operations. We expect our directors to actively contribute to the various ongoing, email based, discussions and provide feedback as needed.

An ideal candidate will be one with the business experience to help formulate strategy and guide the policy that drives DNS-OARC. To be eligible, a candidate must be from an DNS-OARC Member in good standing.

If you would like to nominate (or self-nominate) a candidate, please send an email to board2010@dns-oarc.net with a brief background. We will be asking nominees for a statement of interest along the lines of what was done last year (https://www.dns-oarc.net/node/180).

Cut off for nominations is September 30th.

If you have any questions, please don't hesitate to contact me directly.

Thanks

Wayne MacLaurin
Executive Director, DNS-OARC
wayne@dns-oarc.net

Submitted by wayne@dns-oarc.net on Tue, 2010-09-21 17:10.

DNS-OARC Public Comment on ICANN's DNS-CERT Business Case

On February 12th, 2010, ICANN issued a invitation for Public Comment on a proposed DNS-CERT. The original invitation can be found at http://www.icann.org/en/announcements/announcement-2-12feb10-en.htm and the list of current public comments maybe be found at http://forum.icann.org/lists/dns-cert-proposal/

DNS-OARC's submission follows:


DNS Operations, Analysis and Research Center

DNS-OARC Public Comment on ICANN's DNS-CERT Business Case

Introduction


DNS-OARC http://www.dns-oarc.net was established in 2004 to address a forseen and growing need to improve the stability, security and understanding of the Internet's DNS infrastructure. Initially funded by the Internet Systems Consortium and a National Science Foundation grant, it is now an established nonprofit with over 60 DNS registries, registrars, operators, researchers and vendors comprising its membership.


DNS-OARC's mission is: to build trust among its members through forums where information can be shared in confidence; to enable knowledge transfer by organizing semiannual workshops; to promote research through data collection, analysis, and simulation; and to increase awareness with publicly available tools and services.


DNS-OARC has been following the DNS-CERT proposals closely as there is much in common between its existing mission and that proposed for DNS-CERT. To date DNS-OARC has worked closely with ICANN in these areas, including collaboration on running the 2 Global DNS Security Stability and Resilience symposia, and participation in the recent DNS-CERT gap analysis workshop.


We are grateful for the co-operation we have received from ICANN in this collaboration, and for ICANN's support both as a member and in funding of our data gathering and analysis related to the DNSSEC signing of the root zone.


In general DNS-OARC welcomes the additional attention that ICANN has brought to the subject are of its mission, and we agree with ICANN's position that additional funding and resources for this area would be beneficial. We do however have some concerns about potential overlap, and some aspects of the approach proposed, which are detailed below.


The views represented in this paper should be noted as being representative of the view of DNS-OARC in its own right, and not necessarily those of OARC's individual members.

DNS-OARC's Capabilities


In the 6 years since its inception, DNS-OARC has developed a number of capabilities with which to fulfill its mission. Many of these are in established widespread use by the DNS operator community, and have contributed both to the response to specific large-scale incidents the global DNS infrastructure has faced, and to the standards of knowledge and best practice within the wider community. Many of these capabilities are compatible with the mission of DNS-CERT, and should be considered as resources that DNS-OARC can "bring to the table" of DNS-CERT's mission.


These capabilities include:

  • Regular open and member-only meetings.
  • A website which places substantial key knowledge, resources and information in the public domain, together with a private section which include a member operational contact directory.
  • Data gathering, monitoring and analysis infrastructure.
  • Archive Data Sets, amounting to over 40 Terabytes dating back 5-10 years.
  • Open, member-only, closed-user and vetted-only mailing lists for knowledge and information sharing, together with a PGP encryption key repository for secure e-mail exchange.
  • Secure real-time Jabber/XMPP-based instant messaging service for members to instantly get in touch and co-ordinate responses during incidents.
  • Publicly available tools for testing, verifying, probing and scanning DNS infrastructure for appropriate behavior and vulnerabilities. Use of many of these tools generate further data sets.
  • Relationships with researchers which allow for analysis and characterization of data, incidents and attacks.
  • Formal relationships with our members which establish DNS-OARC as a self-governing, self-funding neutral membership organization, and places legally-binding confidentiality requirements on all participants.
  • Governance structures including a Delaware legal entity with 501(c)3 nonprofit status and a board of Directors elected by its members.
  • Full-time staff dedicated to fulfilling DNS-OARC's mission.

Partnership with Existing Initiatives


There are various global initiatives that resemble a CERT-like organization. DNS-OARC wishes to draw attention to their existing
activities and emphasize the important of working collectively with them.
  • Mailing lists: there are several which require vetting and which share global incidents (OARC's vetted list, NXD, NSPSEC etc).
  • Meetings: There are several technical colloquia that allow for operationally-relevant DNS meetings, such as DNS-OARC, CENTR-TECH, ICANN's ccNSO-TECH/DNSSECWG, RISG.
  • Active Incident Handling: what might not be shared on the afore-mentioned lists and meetings, is the actual coordination/mitigation of an attack or threat. There are however established CERT organizations that handle those incidents. Some ccTLD registries already operate a CERT on a national level. Lastly, some do have a helpdesk, publish abuse contact addresses, various online tools, and are monitoring lists to handle incidents with actively participating staff, though they do not call it a CERT.


DNS-OARC encourages all organizations to develop a CSIRT-like internal organization or structure. The subsequent step would then be to join FIRST (a vetted membership organization) and/or DNS-OARC in order to share incidents and mitigated threats in a bi-lateral and trusted way.

DNS-OARC Position on a Global DNS-CERT

It is DNS-OARC's view that in order for DNS-CERT to have some impact as a CERT, there needs to be a constituency for it to operate in, including some form of jurisdiction over that constituency, for it to be effective. A CERT needs to gain trust from outside constituencies and other CERTs, in order to share incidents and effectively mitigate threats. This can not be dictated top down, or by unilateral proclamation.


It is also DNS-OARC's experience that sharing of information, whether though data gathering or incident notification, is something that is both essential to DNS infrastructure protection and is something that cannot be compelled. Trust is a very necessary pre-condition for such sharing, but even with trust we have seen that information is not always shared, and some valuable lessons have been learned about what practical limits exist on information sharing.


While ICANN might forsee that extending its jurisdiction could be a means to create a stick for the new gTLDs to participate in DNS-CERT, there is no comparable carrot for the ccTLDs. Additionally, it is unclear what incentives registrars might have to voluntarily co-operate, as co-operation will inevitably lead to loss of income when domains have to be canceled, on top of the labor costs involved to monitor and cancel those.


For an organization such as DNS-CERT to generate the trust it requires to be effective, ICANN needs to allow this entity to be governed and operated outside of the realm and reach of ICANN, working with already established and trusted organizations within the Registry/Registrar/ISP world.


It is projected that the DNS-CERT operating budget will be about US$4.2M annually. ICANN proposes that it is operated by an independent, free-standing entity, governed by a sponsor-based board. At present however there is currently only one sponsor: ICANN. This carries a risk of 'capture' - DNS-CERT can only be truly independent if funded by diverse sponsors and not just ICANN.

Conclusion


DNS-OARC encourages education and awareness in mitigation of threats and handling incidents, and welcomes ICANN's raising the profile of the need for this. We feel it is necessary that this awareness is developed inside organizations that already have a responsibility for parts of the DNS community (such as TLD registries). Subsequently, these organizations can join already established vetted communities like FIRST or DNS-OARC.


DNS-OARC strongly encourages ICANN to work in co-operation with it to build upon DNS-OARC's existing established capabilities within the context of wider DNS security co-operation and initiatives. DNS-OARC would not support any DNS-CERT activity to the extent that it would unnecessarily duplicate DNS-OARC's own capabilities.


We remain to be persuaded of the requirement for developing a single, global DNS-CERT. ICANN has correctly identified some gaps between the capabilities of the existing established DNS security organizations and activities, and DNS-OARC welcomes this analysis. Given the large size of the total potential problem and solution space, we think that it would be overly ambitious to attempt to establish a single over-arching new organization to address all of it. Rather it would be far more effective to fully recognize established activities, and dedicate a more modest budget on addressing the gap. This can be through support and funding to establish, assist and enhance trust and co-operation between these existing organizations.


Building education and awareness of incident handling and mitigation of threats, including development of response teams within, and further consensual co-operation between, existing ICANN constituency organizations will lead to a decentralized global cooperative. We believe that this will be far more effective, with greater ultimate reach and legitimacy than a single central DNS-CERT.



14-Apr-2010

Submitted by wayne@dns-oarc.net on Wed, 2010-04-14 14:14.

DITL 2010 Data Collection

A Day in the Life of the Internet is a large-scale data collection project undertaken by CAIDA and OARC every year since 2006. This year, the DITL collection will take place in April. If you would like to participate by collecting and contributing DNS packet captures, please subscribe to the DITL mailing list.

Participation Requirements

There are no strict participation requirements. OARC is happy to accept data from members and non-members alike. If you are a non-member, you may want to sign a Proprietary Data Agreement with us, but this is not required.

In terms of data sources, we are always interested in getting a lot of coverage from DNS Root servers, TLD servers, AS112 nodes, and "client-side" iterative/caching resolvers.

Types of DNS Data

Most of the data that we collect for DITL will be pcap files (e.g., from dnscap or tcpdump). We are also happy to accept other data formats such as BIND query logs, text files, SQL database dumps, and so on. We have an established system for receiving compressed pcap files from contributors. If you want to contribute data in a different format, please contact us to make transfer arrangements.

Pre-collection Checklist

  • Please make sure that your collection hosts are time-synchronized with NTP. Do not simply use date to check a clock since you might be confused by time zone offsets. Instead use ntpdate like this:
    $ ntpdate -q clock.isc.org
    server 204.152.184.72, stratum 1, offset 0.002891, delay 0.02713
    

    The reported offset should normally be very small (less than one second). If not, your clock is probably not synchronized with NTP.

  • Be sure to do some "dry runs" before the actual collection time. This will obviously test your procedures and give you a sense of how much data you'll be collecting.
  • Carefully consider your local storage options. Do you have enough local space to store all the DITL data? Or will you need to upload it as it is being collected? If you have enough space, perhaps you'll find it easier to collect first and upload after, rather than trying to manage both at the same time.

Collecting Data with dnscap

If you don't already have your own system for capturing DNS traffic, we recommend using dnscap with some shell scripts that we provide specifically for DITL collection.

  1. Download the most recent ditl-tools tarball. This includes a copy of the dnscap sources.
  2. You might need to edit dnscap/Makefile. Then run 'make' from the top-level ditl-tools directory.
  3. Note that dnscap no longer depends on libbind.
  4. Run 'make install' as root. This installs dnscap to /usr/local/bin.

Next we'll be working with some scripts in the scripts directory. By default these will store pcap files in the current directory.
You may want to copy these scripts to a different directory where you have plenty of free disk space.

We provide scripts for using either (dnscap) or (tcpdump and tcpdump-split). In most cases dnscap should be easier. The tcpdump method is included for sites that would prefer it or cannot use dnscap for some reason. Note that the settings.sh configuration file described below includes variables for oth dnscap and tcpdump. Some variables are common to both, while some are unique to each.

  1. Copy settings.sh.default to settings.sh.
  2. Open settings.sh in a text editor.
  3. Set the IFACES variable to the names of your network interfaces carrying DNS data.
  4. Set the NODENAME variable (or leave it commented to use the output of `hostname` as the NODENAME). Please make sure that each instance of dnscap that you run has a unique $nodename!
  5. Set the OARC_MEMBER variable to your OARC-assigned name. Note that the scripts automatically prepend "oarc-" to the login name so just give the short version here.
  6. Note that the scripts assume your OARC ssh upload key is at /root/.ssh/oarc_id_dsa.
  7. Look over the remaining variables in settings.sh. Read the comments in capture-dnscap.sh to understand what all the variables mean.

Here is an example customized settings.sh file:

# Settings that you should customize
#
IFACES="fxp0"
NODENAME="lgh"
OARC_MEMBER="test"

When you're done customizing the settings, run capture-dnscap.sh as root:

$ sudo sh capture-dnscap.sh

When its time to do the actual DITL data collection, please uncomment the START_T and STOP_T variables in settings.
sh
and run the scripts from within a screen session.

Collecting Data with tcpdump and tcpdump-split

Another collection option is to use tcpdump and our tcpdump-split program. The instructions are similar to the above.

  1. Download and install the ditl-tools package (see link above).
  2. Copy settings.sh.default to settings.sh and bring it up in a text editor
  3. Set the IFACES variable to the single network interface to collect DNS data from.
  4. Set NODNAME
  5. Set OARC_MEMBER
  6. Tweak the BPF_FILTER variable as necessary.

Note that tcpdump won't capture IP fragments unless you add "or ip[6:2] & 0x1fff != 0" to your BPF_FILTER.

Start the capture with:

$ sudo sh capture-tcpdump.sh

Uncomment the START_T and STOP_T and use screen when its time for the real deal.

Contact

Contact the OARC Admin with any questions about DITL 2010.

Submitted by admin on Tue, 2010-04-06 20:03.