Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Communications The Internet

Comcast Launches First Public US Trial of DNSSEC 100

cryan7755 and netbuzz both sent along a NetworkWorld story on Comcast's public test deployment of DNSSEC. Here is the company's blog post announcing the trial. "Comcast this morning announced what is believed to be the first public test deployment of DNS Security Extensions. The company says it has deployed DNSSEC throughout its nationwide network and will immediately make validating servers available to customers. In addition, Comcast said it would digitally sign all of its own domain names using DNSSEC by early next year. 'There is often talk about a chicken-and-egg sort of problem with DNSSEC. People don’t want to sign their own domains with DNSSEC until people are validating signatures,' says Jason Livingood, Executive Director of Internet Systems Engineering at Comcast. 'We want to explain how we as an ISP have a roadmap for validating signatures with DNSSEC.'"
This discussion has been archived. No new comments can be posted.

Comcast Launches First Public US Trial of DNSSEC

Comments Filter:
  • by vlm ( 69642 ) on Tuesday February 23, 2010 @04:16PM (#31249582)

    The most interesting part of the article didn't make the summary...

    "Opt-in by changing your DNS server IP addresses to 75.75.75.75 and 75.75.76.76 (we'll be adding IPv6 addresses soon)."

    75.75.75.75 will answer outside of the comcast network... so I can use it to test DNS entries. (Or presumably someone could use it in an amplifier attack)

  • by characterZer0 ( 138196 ) on Tuesday February 23, 2010 @04:49PM (#31250066)

    DNSSEC increases your maintenance costs (constant resigning even if no changes), makes DYNDNS servers harder to run, exposes your zone data, and helps DDOS attacks.

    Did I miss anything?

  • by Anonymous Coward on Tuesday February 23, 2010 @05:08PM (#31250364)

    Then you probably want to mod him "Underrated".

  • by JackHoffman ( 1033824 ) on Tuesday February 23, 2010 @05:09PM (#31250382)

    DNSSEC uses cryptographic signatures to authenticate DNS records and thereby prevents DNS spoofing. DNSSEC does not use encryption, only authentication, i.e. it provides trust, but not privacy.

    DNS spoofing is an attack which can be used to redirect traffic to an attacker's server, where the attacker can intercept the traffic for a man in the middle attack or create an impostor service and harvest credentials. There are several countermeasures in plain DNS to prevent spoofing, but Dan Kaminsky's discovery of a fundamental spoofing vulnerability in the DNS protocol finally pushed DNSSEC out of the labs into the wild.

  • by ctg1701 ( 311736 ) on Tuesday February 23, 2010 @05:16PM (#31250480)

    You should read our FAQ on the DNSSEC trial, particularly this section:

    http://www.dnssec.comcast.net/faq.htm#faq7

    What happens to Comcast Domain Helper, which offers DNS redirect services, when you fully implement DNSSEC?
    We believe that the web error redirection function of Comcast Domain Helper is technically incompatible with DNSSEC.
    Comcast has always known this and plans to turn off such redirection when DNSSEC is fully implemented.
    The DNSSEC trial servers we are announcing today do not have Comcast Domain Helper's DNS redirect functionality enabled.
    We plan to update our IETF Internet Draft on this subject, available at http://tools.ietf.org/html/draft-livingood-dns-redirect, to reflect this in the coming months.

  • by Thanatiel ( 445743 ) on Tuesday February 23, 2010 @06:26PM (#31251696)

    A DNSKEY is put at the top of the zone. (ie: yourdomain.tld. IN DNSKEY blablablablabla)
    Your server is supposed to be authenticated using some other mean. (ie: X509 certs for https servers & cie)

    Please also note that there are no "certificates" for DNSSEC, only very basic key pairs:

    _ Generate your zone-signing keypair (rsa/dsa) and/or your key-singing keypair (idem). Generate them for the algorithms used in the zone (hopefully NSEC3, else NSEC and its damn zone-walk issue)
    _ Put the public key record into your zone file and sign the zone (opt-out or not)
    _ Give the public key digest (or public key, depending on the TLD's policy) to the registrar (So it can obtain the DS record for your domain)

    Done: the DS on the TLD will be the link with your domain's key(s). Note that the TLD will be trusted because either the key is "known" either it is authenticated by '.' whose key will be "known".

    Note that the chain will only be complete when '.' will be signed.

    Viva paranoïa.

  • by nine-times ( 778537 ) <nine.times@gmail.com> on Tuesday February 23, 2010 @07:19PM (#31252396) Homepage

    However, the same people that screw up their SSL / HTTPS config and convince everyone to just click thru the error messages, will be running/ruining their dnssec config

    Well it's kind of funny that this is your complaint, since one of the reasons admins ask people to click through the error message is that they have self-signed certs because they don't want to pay ridiculous amounts of money to a CA. From what I understand, (which admittedly is limited) DNSSEC could possibly open the door to putting signed public keys into DNS records, which would mean you wouldn't really need SSL certificate authorities.

    So instead of being the same problems as SSL all over again, this could help address the SSL problems. Maybe. I still suspect certificate authorities will find a way to keep anything like that from happening.

  • by ctg1701 ( 311736 ) on Tuesday February 23, 2010 @07:38PM (#31252630)

    You noticed correctly. This will put an end to redirection as we deploy DNSSEC.

    Thanks

    Chris Griffiths
    Comcast

"May your future be limited only by your dreams." -- Christa McAuliffe

Working...