DNS-OARC is pleased to announce that its 2013 Spring Workshop will take place in Dublin, Ireland, on the 12th and 13th May. This will be at the same location as the subsequent RIPE66 meeting, and is sponsored by:
The meeting will run all day Sunday 12th, including lunch, and a Sunday evening social event. The meeting will continue on the morning of Monday 13th, which includes an OARC members update session.
Coffee Break Sponsor:
Places for the social are limited to OARC Spring Workshop 2013 meeting attendees, so please ensure you have your attendee bage with you when you arrive at the venue.
Increasing DS queries for JP DNS servers and a proposal for its countermeasures
JPRS observed that DS queries for JP registered domain names have
been increasing and 3.5% of queries are qtype DS now. This report
presents current status of JP queries, the reason of increasing DS
queries, possible situations in the future and some idea of
countermeasures for this phenomena.
The reason of increasing DS queries is the following. An unsigned
domain name does not have a DS RR in its TLD zone. NCACHE TTL is
smaller than normal RR TTL in many TLDs. DNSSEC validators need to
know DS RR existence for each query name. As a result, each DNSSEC
validator may send DS queries for TLD DNS servers one zone cut per NCACHE
Bit errors in memory, when they occur in a stored domain name, can direct Internet traffic to the wrong location, potentially compromising security. When a domain name one bit different from a target domain is registered in order to intercept traffic for malicious purposes, the attack is called bitsquatting. For example, by changing only one bit, a target domain such as “twitter.com” can become the bitsquat domain “twitte2.com”.
Jaeson Schultz(Cisco Systems, Inc)
a TCP DNS performance test tool
There were many reasons to develop a TCP DNS performance test tool,
others than there was none available when I began:
- EDNS0 is not a 100% solution to DNSSEC and/or IPv6 large responses
- rate limiting could lead to more TCP queries via artificially
truncated UDP responses
- ICANN requires in its gTLD applicant guidebook page 218/5-6 module 5
section 5.2.2 some TCP performances...
- IXIA boxes could do the job but are a bit expensive
This presentation is about a TCP DNS performance test tool and its findings.
Defending against DNS Amplification Attacks
The goal of this presentation is to show how to defend against DNS amplification attacks. The presentation will focus on Response Rate Limiting (RRL) and the effectiveness of this defence mechanism against current and future attacks.
Javy de Koning(NLnet Labs)
Comparison of RRL behaviour in BIND9, Knot DNS, and NSD
In March 2013 an L-Root node in Hamburg, Germany received abnormal traffic over a prolonged period of time. Initial inspection of the traffic suggested that L was being used as an amplifier as part of a reflection attack. The short-term effects were mitigated using NSD RRL, which resulted in a decrease in outbound traffic that was noticeable, but smaller than we expected given anecdotal reports from other DNS operators using BIND9 RRL.
Full packet captures of the request traffic were retained for further analysis. This retained data was used to replay the query traffic against a variety of authoritative servers that have implemented some form of response rate limiting, in order to compare the implementations from an operational perspective.
PGP Signing Session
Keyring file SHA1 checksum
As a way to build community and expand the web of trust, DNS-OARC runs Key Signing Parties whenever it's possible. We'll have one during the Spring Workshop in Dublin, during the lunch break on Sun May 12th.
In order to participate, you will need:
Upload your key to the event keyring. The deadline to have your key uploaded is Sun May 12th at 11:50 (during the coffee break). That will give the party coordinator time to print the key list and be ready for the signing.
At 13:00 we will convene at the reception desk. All participants will receive a printout with the keys, and you'll need to bring a government-issued identification (passport, driver's license) or an alternative form of ID (employee ID). You will also need a trusted source of your key's fingerprint, which can be your business card, a piece of paper or your laptop screen.
Following the order on the key printout, every participant will have a turn to read their key fingerprint *from its trusted source*, while the rest will verify the fingerprint matches the one listed in the printout.
Once all fingerprints are read, every participant will circulate his/her identification document, to allow the rest to confirm identity.
Now the party is over. It's up to each participant, if satisfied with the fingerprint and ID, to sign other's keys. To make things easier, it's recommended to download the keyring, import it, and then sign the individual keys. Once signed, you'll like to email the signed key back to the owner, and optionally upload the signed key to a PGP server.
DNS Reflection Attacks
Merike Kaeo(Internet Identity)
Classifying Resolver Capabilities
In our attempt to quantify/qualify whether a particular DNS resolver is DNSSEC-compliant, we realized that it is important to test for a resolver's major functional behaviors rather than looking for compliance with all possible corner cases. Based on this idea, we designed a series of tests and grades for resolvers based on each test's results. Based on the tests' outcomes we classify resolvers into categories.
Monitoring Recursive DNS in China
Recursive DNS is used to resolve other people’s domains. In order to investigate the security, stability and resiliency of recuisive DNS used in China, we bulit a nationwide distributed platform to monitor the status of recursive DNS, including all recursive DNS deployed by the three largest ISPs in China. After analyzing these data generated from this platform, some valuable information for these recursive DNS was found.
Self-Serve Open Resolver Testing
Recent attacks bring renewed attention to the millions of open resolvers on the Internet. Discovery of open resolvers has traditionally been done by wide-scale surveys of known name servers or address space. Such surveys suffer from a few problems: (1) probing traffic may be seen as abusive; (2) the desire to provide open resolver addresses to the "good guys" but keep them away from the "bad guys"; and (3) big surveys take a long time and are updated on the surveyor's schedule.
Verisign has developed a new tool that allows network administrators to scan their own address space for open resolvers at their own convenience and quickly view the results.
Open Resolver Project
The Open Resolver Project has been performing scans of the entire IPv4 space weekly and has turned up interesting trends and data about the behavior of hosts on the Internet. Many networks and CPE devices pose a risk in replying to DNS traffic, many times in ways that are unexpected or unintended. We are sharing trends and data on our observations, including providing raw data for derivative research.
Jared Mauch(NTT America)
Duane Wessels(Verisign), Olafur Gudmundsson(Shinkuro), MrXuebiao Yuchi(CNNIC), jared mauch(NTT)
Anycast Enumeration of Large DNS Services
We have evaluated techniques to enumerate instances of DNS anycast,
comparing the use of CHAOS records, traceroute, and a new proposal
using IN TXT records. Enumeration allows a third party to evaluate
the size of an anycast service, and in some cases to identify
masqueraders operating on the same anycast address.
We have evaluated our approaches on F-root, Packet Clearinghouse, and
the AS112 anycast infrastructures to compare the completeness of our
approaches. Joe Abley and L-Root has deployed an IN-based system to
support these approaches, and we have also compared tehse results
against their ground truth.
Remote DNS services and Content delivery networks
The recent growth of remote DNS services can negatively impact CDN’s performance. CDNs rely on the DNS for replica server selection. DNS based server selection builds on the assumption that, in the absence of information about the client's actual network location, the location of a client's DNS resolver provides a good approximation. Remote DNS breaks this assumption. Consider the performances of both remote DNS and CDN, a practical industry solution should be proposed.
DNS monitoring for Norway
Norid will be deploying a new DNS monitoring system this year.
As part of this activity, we've been gathering information on current
tools and methodologies, metrics, common data formats and so on.
These will be used to develop best common practices and their application to Norid's requirements.
We'd like to present our findings and stimulate discussion with others who are interested in
this topic and willing/able to share information, collaborate on code or procedures, etc.
Next Steps In Accelerating DNSSEC Deployment
How can we accelerate the global deployment of DNSSEC? What are the major challenges that we as a community need to examine? Over the past 16 months of rolling out the Deploy360 program we've been analyzing the issues and speaking with operators and content providers around the world. In this presentation, we'll present our findings and outline some of the next steps we see as well as work that is already happening within the community.
With the implementation of a signed root in the DNS, we are now in the initial phases of widespread adoption of DNSSEC. There has been much in the way of surveys of DNSSEC adoption in terms of signed domains, but fewer measurements and studies in the level of use of DNSSEC validation by DNS resolvers and end clients using such resolvers.
The recent announcement by google regarding the use of DNSSEC validation in their public DNS product (220.127.116.11) has increased interest in this topic.
We have been undertaking a novel form of measurement of DNSSEC that uses online advertizing channels to enroll a large number of clients internet-wide to undertake specific DNS tasks that include aspects of DNSSEC behaviour. in this presentation we will explore the methodology, and present some initial findings related to the extend of DNSSC validation by clients, and the behaviours of DNS resolvers when presented with both valid and invalid DNSSEC keychains.
1- Presentation of modular group cryptography based on Diffie-Hellman
(even DNSSEC uses on DSA, not DH, DH math is very simple so far easier
to explain and (I expect) to understand)
2- Presentation of elliptic curve cryptography in comparison with
modular group cryptography (vs all the mathematical details), e.g.,
exponentation is replaced by multiplication
3- The different parameters used in DNSSEC (primes, keys, etc),
including by PKCS#11, with some words about standard optimizations
(again not explaining them but showing how to recognize them)
4- Pros and Cons of ECDSA in DNSSEC (pros 20 times faster, smaller
parameters, cons (inherited from DSA) requires a random number for
signing, verification slower than signing)
5- ECDSA in practice (bind 9, etc) and open real world questions
(e.g., what are the registries which accept ECDSA KSKs/DS RRs)
6- A word about hidden ECC in DNSSEC (GOST which is in fact ECDSA,
Chinese commercial crypto too) as a conclusion.
GPU-based NSEC3 Hash Breaking
NSEC3 is a mechanism for authenticated denial of existence in DNSSEC-signed zones. To avoid zone enumeration, names are hashed with SHA-1 and only the resulting hash values are enumerable. In this talk, we present a GPU-based tool for NSEC3 hash breaking, written in OpenCL and Python. The tool can compute 1.8 billion NSEC3 iterations per second on a high-end gaming GPU (AMD Radeon HD 7970). We discuss hash breaking optimization attempts which are inspired by password cracking techniques. The results are meant to aid operators in deciding whether NSEC3 is a useful building block for their DNSSEC setup.
MrMatthäus Wander(University of Duisburg-Essen)
DNS Security: Beyond DNSSEC, A "He Must Be Nearing Retirement" Manifesto
Basically, why RRL is only a nice first step, but I want to change the protocol some.
DNSHarness is an open-source tool for testing multiple DNS server implementations. Tests are scripted and may be executed against a number of different implementations in sequence. DNSHarness runs on Linux and uses VirtualBox to build and run all of the popular open source DNS software packages. It can also test closed source implementations running externally.
Changes and updates to dnscap
dnscap is a DNS-specific packet capture utility. It has recently been given a plugin-style architecture, such that the user can specify multiple modules to analyze captured packets. One such module provides statistics for root server operators. Plugins may be even be written by end users and/or third parties.
OARC Status and Development Plan
The OARC Board recently had a retreat to consider OARC's strategy and development. The output from this is a development plan, which the President will be sharing with OARC's members and other interested parties, as well as an update on OARC's recent progress and current status.
DNS-OARC Systems update
The presentation will go over the short history of systems at DNS-OARC and go through future directions to satisfy member demand and bring about the modernization required.