Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment: Re:They're assholes. (Score 1) 336

by marka63 (#48677461) Attached to: Why Lizard Squad Took Down PSN and Xbox Live On Christmas Day

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.

Comment: Re:DNSSEC (Score 1) 110

by marka63 (#48629249) Attached to: Hackers Compromise ICANN, Access Zone File Data 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.

Comment: Re:I'm fine with a fine (Score 1) 179

$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.

Comment: Re:Easy to solve - calibrate them to overestimate (Score 1) 398

by marka63 (#48198711) Attached to: Speed Cameras In Chicago Earn $50M Less Than Expected

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.

Comment: Re:Why do people use internal TLDs? (Score 1) 101

by marka63 (#47699371) Attached to: ICANN Offers Fix For Domain Name Collisions

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.

Comment: Re:1993 All over again (RFC-1935) (Score 1) 101

by marka63 (#47692885) Attached to: ICANN Offers Fix For Domain Name Collisions

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.

Comment: Re:Why do people use internal TLDs? (Score 1) 101

by marka63 (#47692805) Attached to: ICANN Offers Fix For Domain Name Collisions

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.

Comment: Re:Why do people use internal TLDs? (Score 1) 101

by marka63 (#47692701) Attached to: ICANN Offers Fix For Domain Name Collisions

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.

Seen on a button at an SF Convention: Veteran of the Bermuda Triangle Expeditionary Force. 1990-1951.

Working...