http://www.intodns.com/ no go for tlds

http://www.intodns.com/ does not seem to work for cctlds

randy

Missing nameservers reported by parent

Hello,

from: http://www.intodns.com/dns-oarc.net

FAIL: The following nameservers are listed at your nameservers as 
nameservers for your domain, but are not listed at the parent 
nameservers (see RFC2181 5.4.1). You need to make sure that these 
nameservers are working.If they are not working ok, you may have problems!
ns2.dns-oarc.net

How about this warning?

Regards.

Multi-master setups

Dear DNS folk,

I'm thinking about multi-master setups to add some resiliency to our DNS
infrastructure.

In our specific case we have a distribution server which slaves several
zones from various different parties. They also send notify messages to
this server. Once it transfers a zone, it sends notify messages to our
public-facing DNS cluster, and they all transfer the zone from it.

Obviously, this single distribution server is a single point of failure,
and I'd like to get rid of it.

The simplest solution is to add a second server to our infrastructure,
with an identical zone configuration, so that it is also a slave for all
the same zones. It would also transfer zones directly from the masters,
and provide AXFR/IXFR to our cluster.

Adding a second distribution server has management overhead though. We
have several hundred masters, and even after contacting all of them, we
will never have a 100% clean setup where the master allows zone
transfers for both our distribution servers. So if I want to ensure that
both our distribution servers hold identical copies of zones, then I
would ideally want them to notify each other, and pull zones off each
other as well. Do any of you do this?

Aside from this idea, are there any other clever ideas people have
implemented?

Regards,

DNS amplification attacks in draft-ietf-savi-threat-scope-08

IETF document
<http://www.rfc-editor.org/internet-drafts/draft-ietf-savi-threat-scope-08.txt> 
(approved by IESG and currently in the RFC Editor Queue) contains:

>   DNS is one of the common targets of such attacks.  The
>   amplification factor observed for attacks targeting DNS root and
>   other top level domain name infrastructure in early 2006 was on
>   the order of 76:1.

Two things puzzle me: I'm not sure of what attack they are referring
to since there is no reference in the RFC. Is it the one discussed in
tge "DNS deluge for x.p.ctrc.c" thread on the NANOG mailing list in
february 2006?

And the second is the mentioned amplification factor. All the DNS
servers I know limit the size of the UDP answer to 4 096 bytes, 4 144
with the IPv4 and UDP headers. A factor of 76:1 needs requests smaller
or equal to 54 bytes, which leaves only SIX bytes for the DNS
message... How did they reach this number?
_______________________________________________
dns-operations mailing list
dns-operations <at> lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: bind force qtype=ANY to TCP

> From: Jared Mauch <jared@...>

> The folks that are most concerned with RRL are those expecting queries
> from stub resolvers, I think this would mitigate this risk.

} > Is it intentional that the patch does not affect authoritative ANY
} > responses?  I think the patch would fail to stop the authorities for
} > isc.org from answering `dig +dnssec isc.org any  <at> ams.sns-pb.isc.org'
} > with almost 4 Kbytes.
}
} It's somewhat accidental, but I think OK.

We disagree on both of those issues.  Reflections from recursive
servers are bad, but reflections from authorities are as bad if only
because many authorities have more resources and so can blast more
bits at a DoS target than many recursives.  There's also the idea
that open recursives should be closed for more reasons than complicity
in reflection DoS attacks but authorities cannot be closed.

}   I think it is fine as it primes the cache if it's a real query, but if it's
} fake then it just keeps sending TC=1 until the TTL expires.

What are "fake" and "real" queries?  I didn't think we were talking
about queries that get NXDOMAIN responses or <random>example.com.
There would be no need for any patches if there were a way to
distinguish forged DoS queries from real queries from the DoS target.

That reference to cache priming suggested another thought.
As you wrote, the patch does not stop recursion from filling the
local cache.  The patched code is not used when the local cache

bind-9.9.3rc2 ANY+TCP patch

I thought I'd share this to anyone that wants to just force all TYPE=ANY queries over TCP to prevent those
from coming from spoofed locations.

This is a crude but effective hack.  It doesn't stop the system from recursing to find the response.

http://puck.nether.net/~jared/bind-9.9.3rc2-tcp-any.patch

	- Jared

security with a firewall

Hi,

Does a hardware firewall help to defend the DNS attack?
If so what's the suggested policy/rules?

Thanks.

DSCng 0.1.0

Hi everybody,

I am happy to announce, that we published the first numbered release of 
DSCng - 0.1.0.

The project is still in development and there will certainly be some 
bugs and rough edges. On the other hand, it is no problem to run DSCng 
alongside your production version of DSC and we feel confident that the 
code is stable enough for broader testing. We also promise to include 
migration scripts for any future updates, should the database structure 
change.

More information about the project, as well as download links and 
installation documentation, is available at http://www.dscng.cz/

Best regards

Beda

--

-- 
Bedrich Kosata
CZ.NIC Labs <http://labs.nic.cz>

Hi everybody,

I am happy to announce, that we published the first numbered release of 
DSCng - 0.1.0.

Call for Participation -- ICANN DNSSEC Workshop 17 July 2013

<div><div>
<div>Call for Participation -- ICANN DNSSEC Workshop 17 July 2013</div>
<div></div>
<div><br></div>
<div>The DNSSEC Deployment Initiative, in cooperation with the ICANN Security</div>
<div>and Stability Advisory Committee (SSAC), is planning a DNSSEC Workshop at</div>
<div>the ICANN meeting in Durban, South Africa on 17 July 2013.&nbsp;&nbsp;The DNSSEC</div>
<div>Workshop has been a part of ICANN meetings for several years and has</div>
<div>provided a forum for both experienced and new people to meet, present and</div>
<div>discuss current and future DNSSEC deployments.&nbsp;&nbsp;For reference, the most</div>
<div>recent session was held at the ICANN meeting in Beijing, China on 10 April</div>
<div>2013. The presentations and transcripts are available</div>
<div>at<a href="http://beijing46.icann.org/node/37125">http://beijing46.icann.org/node/37125</a>.</div>
<div><br></div>
<div>We are seeking presentations on the following topics:</div>
<div><br></div>
<div>1.&nbsp;&nbsp;DNSSEC Activities in Africa</div>
<div>For this panel we are seeking participation from those who have been</div>
<div>involved in DNSSEC deployment in Africa as well as those who have a keen</div>
<div>interest in the challenges and benefits of deployment.&nbsp;&nbsp;Key questions are</div>
<div>to consider include: What would help to promote DNSSEC deployment?&nbsp;&nbsp;What</div>
<div>are the challenges you have faced when you deployed DNSSEC?</div>
<div><br></div>
<div>2. The Operational Realities of Running DNSSEC</div>
<div>Now that DNSSEC has become an operational norm for many registries,</div>
<div>registrars, and ISPs, what have we learned about how we manage DNSSEC?</div>
<div>What's best practice around key rollovers? How often do you review your</div>
<div>disaster recovery procedures? Is there operational familiarity within your</div>
<div>customer support teams? Has DNSSEC made DNS more 'brittle' or is it just a</div>
<div>run-of-the-mill operational practice? What operational statistics have we</div>
<div>gathered about DNSSEC? Is it changing DNS patterns? How are our</div>
<div>nameservers handling DNSSEC traffic? Is the volume as expected? Have we</div>
<div>seen anything unusual?&nbsp;&nbsp;Are there experiences being documented in the form</div>
<div>of best practices, or something similar, for transfer of signed zones?</div>
<div><br></div>
<div>3.&nbsp;&nbsp;DNSSEC and Enterprise Activities</div>
<div>DNSSEC has always been seen as a huge benefit to organizations looking to</div>
<div>protect their identity and security on the Web. Large enterprises are an</div>
<div>obvious target for DNS hackers and DNSSEC provides an ideal solution to</div>
<div>this challenge. This session aims to look at the benefits and challenges</div>
<div>of deploying DNSSEC for major enterprises. Topics for discussion:</div>
<div><br></div>
<div>* What is the current status of DNSSEC deployment among enterprises?</div>
<div>* What plans do the major enterprises have for their DNSSEC roadmaps?</div>
<div>* What are the challenges to deployment for these organizations?&nbsp;&nbsp;Do they</div>
<div>foresee raising awareness of DNSSEC with their customers?</div>
<div><br></div>
<div>4. When Unexpected DNSSEC Events Occur</div>
<div>What have we learned from some of the operational outages that we have</div>
<div>seen over the past 18 months? Are there lessons that we can pass on to</div>
<div>those just about to implement DNSSEC? How do you manage dissemination of</div>
<div>information about the outage? What have you learned about communications</div>
<div>planning? Do you have a route to ISPs and registrars? How do you liaise</div>
<div>with your CERT community?</div>
<div><br></div>
<div>5.&nbsp;&nbsp;Preparing for Root Key Rollover</div>
<div>For this topic we are seeking input on issues relating to root key</div>
<div>rollover.&nbsp;&nbsp;In particular, we are seeking comments from vendors, ISPs, and</div>
<div>the community that will be affected by distribution of new root keys.</div>
<div></div>
<div><br></div>
<div>6.&nbsp;&nbsp;DNSSEC: Regulative, Legislative and Persuasive Approaches to</div>
<div>Encouraging Deployment</div>
<div>There are many models in discussion for encouraging the take-up of DNSSEC</div>
<div>amongst TLDs. In some jurisdictions we have seen governmental edicts</div>
<div>insisting that DNSSEC is deployed across a Top Level Domain. In others, we</div>
<div>have seen reports produced for governments highlighting the lack of take</div>
<div>up and the need for tighter control amongst operators. Recently, we have</div>
<div>witnessed the consideration&nbsp;&nbsp;of mandated DNSSEC signing of zones by some</div>
<div>TLDs in order to gain access to newer premium domains.&nbsp;&nbsp;Have any of these</div>
<div>approaches worked in encouraging take up of DNSSEC? What role does a</div>
<div>national government have in assisting deployment of DNSSEC? How are some</div>
<div>of these measures perceived by registrars, DNS operators, ISPs and</div>
<div>registrants?</div>
<div><br></div>
<div>7. DANE and Other DNSSEC Applications</div>
<div>Using DNSSEC as a means of authentication for http transactions is an</div>
<div>exciting development of DNSSEC. What is the progress of the DNS-Based</div>
<div>Authentication of Named Entities (DANE) initiative? (See</div>
<div>
<a href="http://datatracker.ietf.org/wg/dane/">http://datatracker.ietf.org/wg/dane/.</a>) How soon could DANE become a</div>
<div>deployable reality and what will be the impact of such a deployment, e.g.</div>
<div>impact on traditional certification authorities (CAs)?</div>
<div><br></div>
<div>8.&nbsp;&nbsp;Use of DNSSEC in the Reverse Space</div>
<div>This topic includes signed reverse zones, security products using reverse</div>
<div>DNS lookup for DNSSEC validation?</div>
<div></div>
<div><br></div>
<div>9.&nbsp;&nbsp;The Great DNSSEC Panel Quiz</div>
<div>Ever fancied pitting your wits against your colleagues?&nbsp;&nbsp;Demonstrate your</div>
<div>knowledge and expertise in DNSSEC in our Great DNSSEC Panel Quiz.</div>
<div><br></div>
<div>In addition, we welcome suggestions for additional topics.</div>
<div><br></div>
<div></div>
<div>If you are interested in participating, please send a brief (1-2 sentence)</div>
<div>description of your proposed presentation to&nbsp;<a href="mailto:dnssec-durban@...">dnssec-durban@...</a>&nbsp;by&nbsp;</div>
<div>**Monday&nbsp;27 May&nbsp;2013.**≤/div>
<div><br></div>
<div>We hope that you can join us.</div>
<div><br></div>
<div>Thank you,</div>
<div><br></div>
<div>Julie Hedlund</div>
<div><br></div>
<div>On behalf of the DNSSEC Workshop Program Committee:</div>
<div>Steve Crocker, Shinkuro</div>
<div>Jacques Latour, .CA</div>
<div>Xiaodong Lee, CNNIC</div>
<div>Simon McCalla, Nominet UK</div>
<div>Russ Mundy, Sparta/Parsons</div>
<div>Ond&#345;ej Sur&yacute;, CZ.NIC</div>
<div>Lance Wolak, .ORG, The Public Interest Registry</div>
<div>Yoshiro Yoneya, JPRS</div>
<div>Dan York, Internet Society</div>
</div></div>

Measuring DNSSEC Performance.

from <http://www.potaroo.net/ispcol/2013-05/dnssec-performance.html>:

-----

So the overall result is that if you DNSSEC sign a domain today then some 70% of the received A queries will
request DNSSEC additional information, and the traffic level in responses will rise by a factor of 4.5
over traffic levels for an unsigned domain. If every client used DNSSEC validating resolvers then the
total traffic levels would increase by a factor of up to 13 over levels associated with an unsigned domain.
Obviously, once more, caching of the DNSSEC zone values would have some impact on this number, and a more
accurate working projection is that traffic volumes would increase by a factor of between 6 and 13,
depending on the zone’s key lifetime and query activity.

For the invalidly-signed domain name the traffic levels in the responses have increased by a factor of 5.5.
When the DNSSEC-signatures cannot be validated the client will repeat the query on any alternate DNS
resolvers that have been configured. One way to look at this is to compare it to the validly signed domain.
DNSSEC-invalidity is observed to increase the total response traffic volume by 20%. But this condition
is being encountered by at most 4% of clients. If every client was using resolvers that performed DNSSEC
validation then the consequence of key expiration, or any other event that caused the signature
information be become invalid, would increase the traffic levels by 500%. In other words, the total
traffic volume would be 6 times greater than that of a validly signed domain, or some 96 times higher than
that of a validly signed domain, when using a single name server in the case where none of the responses are
cached in DNS resolvers.

-----

-----------------------------------------------------------------------
Roland Dobbins <rdobbins@...> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton

DNS-OARC Spring Workshop Final Information

Our Dublin workshop is proving to be packed, from both a content and
attendance point of view.

Our main themed session for the workshop is on the ever-topical subject
of open resolver-based attacks, with 4 speakers, chaired by Merike Kaeo
on Sunday afternoon. Much of Monday morning is devoted to talks and
operational experience and measurement of DNSSEC. We have a number of
talks on various approaches to DNS monitoring, and several research talks.

My new colleague William Sotomayor will be reporting on his progress
rejuvenating OARC's infrastructure, and I will be speaking about the
recent member survey, board retreat, and ensuing OARC development plan.
Note that although these talks in the second half of Monday morning are
targetted at and mostly of interest to OARC Members, we are not having a
formally closed members-only session this time.

Please note that the meeting venue is now *full*, and we can't accept
and further registrations or walk-ins. If you registered, please ensure
you pick up your badge when you arrive so you have access to lunch and
the evening social event.

If you didn't register, you can still attend remotely - you can find the
speakers' slides via the agenda at:

  https://indico.dns-oarc.net/indico/conferenceTimeTable.py?confId=0

and we will be webcasting proceedings with help from ICANN at:

  http://icann.adobeconnect.com/dns-oarc/

with jabber remote participation at:

  xmpp:dns-operations@...

For on-site connectivity, we'll be using the RIPE meeting wireless
network, look for SSID "ripemtg".

During the Sunday lunch break, Sebastian Castro will be running a PGP
signing session, please check the  with him for keyring details.

At the end of the Sunday (18:30) we have a social event, we're grateful
to OARC members APNIC, NZRS and RIPE External Relations for sponsoring
this, and also INEX and DB Events for helping organise it.

Finally, a big thank you to IEDR for sponsoring and helping with the
meeting, Nominet for sponsoring our coffee breaks, and the RIPE NCC
meeting and Ops teams for providing connectivity.

Look forward to seeing you all in Dublin !

Keith