As a Industry there is lots one can do to prevent / reduce a DoS.

You can quarantine infected machines.
You can install BCP 38 filters so traceback is more effective.
You can ensure that fixed software images are always available.
You can not orphan software just because it is old.
You can auto update software.

You can take pro-active steps like surveying the your customers and informing them when they have a known vulnerable system.

For the root zone there is very little that is actually signed as most of the root zone is delegating NS records (not signed just their presence in the NSEC record is signed) and glue address records (not signed). If you can alter the root zone contents you can introduce new DS records matching DNSKEY records you control. These would then get signed and if you can direct your targets to this alternate version of the TLD it will be accepted as valid. This will only work until the zone signing key is rolled at which stage the DNSSEC validation chain will no longer work and you will need to go back and get the DS re-signed. Actually changing the root zone contents like this will almost certainly be caught as it is a highly examined zone. In particular people checking DS/DNSKEY pairs looking for errors so they can be fixed quickly. Now if you can get someone to sign a isolated DS RRset that is not in the root zone but is for a TLD then this could go undetected for longer but that is a much harder problem than just changing the root zone contents. That still only has a limited lifetime as the RRSIGs need to be refreshed.

The signing ceremony is where the DNSKEY RRset is re-signed to introduce / remove zone signing keys. The private part of the zone signing key has to be available on a day to day basis for the normal day to day changes in the root zone. That said the private part is still held in a HSM and the worst that can happen is that someone can get some data signed which can be used until the zone signing key is rolled.

And how do you know what to filter?

RPKI is about providing a trustworthy database that can be used to decide what to filter and what to permit.

The Australian Competition and Consumer Commission (ACCC).

$monthly * (throttled time / time in month) * 10.

The 10 times multiplier is a penalty. This is applied to all months for which the customer held a unlimited plan.

If AT&T don't have the data for when the plan was throttled the assumption should be that the plan was being throttled all the time.

It should also be a cheque not a credit.

The smart thing is to make all the cameras speed and red light camera. Prominently display where such camera are installed. Traffic will get used to this.

Where I live most of the red light cameras have been converted to safety cameras (red light + speed) and you will go through lots of intersections with them. This brings the speed down between cameras as well as reducing the number of accidents at intersections. Traffic actually travels within the speed limit instead of the +10 I often see on US roads.

And if sites actually added the SRV records specified in RFC 6186 Apple could avoid having to maintain a database of email to submission/pop3/imap/pop3s/imaps servers.

It's not like it is hard to add these records.

And at 3.3M they may as well just push it out rather than delaying it. A couple of checks will be more costly than just letting everyone download it straight away.

Actually we are getting Dr Who simultaneously with the UK if you are willing to get up at that time of the morning to watch. Or you can just record and time shift.
Sunday 7:30pm is a replay of the morning's broadcast.

Not DANE the people, DANE (DNS based Authentication of Named Entities) http://tools.ietf.org/html/rfc... Mozilla are in a position to both publish TLSA record and authenticate the CERT.

Firstly ICANN had a black list of TLD labels that is wasn't going to allow anyone to apply for because they know they were likely to be in use.

If they looked at every "bad" TLD name that hit the root servers they could never add any new TLDs.

Having awarded contracts for TLD's they are try to minimise the impact on those labels that didn't make the black list or that they were unaware of.

Actually they do own and run one of the root servers. The company I work for owns and runs another of them. I submitted arguments, as a private individual, to not expand the root zone when this was being mooted. That all being said they are the legitimate party to decide what gets added to the root zone.

This isn't RFC 1535 all over again unless you are using partially qualified names where the end of the partially qualified name just happens to match one of the new TLDs. Partially qualified names have always been dangerous.

I just wish I had been able to convince Paul to break all existing use of partially qualified names back then by not appending search elements to any name with multiple labels. As much as foo.lab is convenient to type, foo.lab.example.net was safe as was foo + lab.example.net as a search list element.

They don't own you. However they are the authority for which names are added to the root zone. New TLD labels have always been possible and have been added from time to time.

The RBDMS vendors that squatted on a TLD were not rational actors. They knew or should have known that new TLDs could be added to the DNS at anytime. That new TLDS would be added to the DNS was published as part of the switch from a flat namespace to a hierarchical namespace. They failed to do due diligence. If they wanted a reserved name they could have requested one or heaven forbid registered one.

This is like vendors that squatted on 1.0.0.0 address space.

Firstly ICANN didn't just assert ownership of the root. They inherited it along with the rest of the IANA.

And the administrators gambled that no one else would ever register that tld. Sorry they just lost that bet.

The DNS is designed to allow everyone to have their own namespace. To do this you need to register the name so that it can be uniquely yours. If you can't register it, don't use it. Period.

As for those protocols they could have requested a reserved name. They just failed to do so. There have always been processes to get reserved names.

Multiple address, source address routing and multi path TCP will address lots of the reasons people want PI addresses today. IPv6 has enough addresses to make that mix of technologies a viable solution space. IPv4 is too resource constrained to make that a viable solution.