Talk:Domain Name System Security Extensions

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
WikiProject Computing (Rated C-class, Low-importance)
WikiProject iconThis article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.
 

Absolutely terrible article (as of Nov. 2013)[edit]

This is one of the worst wiki articles I have ever come across in my life. No meaningful discussion of DNSSEC can happen if its necessity isn't discussed. This article attempts to include such a discussion, but fails miserably. Nowhere on the page was there discussion of SSL/TLS aka HTTPS.

Here is a nice quote from an insightful comment on an article discussing DNSSEC:

Cache poisoning isn't a serious threat if SSL/TLS is working correctly. In the presence of functional SSL/TLS, DNS cache poisoning can only produce a denial of service attack. The scenario we're trying to prevent is, "A thinks he is talking with B, but is actually talking with C." Cache poisoning can give A the address of C instead of B, which is a start, but C can't pass himself off as B unless he compromises the SSL/TLS process.
SSL/TLS provides end-to-end security. It catches DNS forgery. It catches route hijacking. It catches an arbitrary man in the middle. If SSL/TLS is working, every security compromise that DNSSEC can prevent has already been covered, and then some.
By "The Famous Brett Watson" from: http://www.circleid.com/posts/securing_a_domain_ssl_vs_dnssec/#5841

And another from his original comment:

If your threat is the classic "man in the middle attack", then you need SSL/TLS more than you need DNSSEC. In a world without DNSSEC (i.e. the world most of us live in), such an attacker can easily direct you to the wrong place, but you'll know it's the wrong place when you get there, so the attack fails. In a world with DNSSEC but not SSL/TLS, the attacker can't steer you in the wrong direction, but he can intercept you on the way, and you'll be none the wiser.
This analysis should give us pause for thought. DNSSEC is supposed to defend against MITM (man in the middle) attacks, and it does so to some degree (by protecting the name-to-address resolution process), but it relies on SSL/TLS to finish the job. One of the arguments used in favour of DNSSEC is that SSL/TLS isn't working all that well in practice, so we need the additional security of DNSSEC. Unfortunately, DNSSEC isn't actually providing additional security against a genuine MITM attack: SSL/TLS is still the weak link in the chain when DNSSEC is used!
http://www.circleid.com/posts/securing_a_domain_ssl_vs_dnssec/#5830

If this is accurate, and I believe his analysis is correct, then DNSSEC amounts to a giant waste of time. ---- itistoday (Talk) 04:19, 4 November 2013 (UTC)

That analysis is wrong. He is ignoring how SSL/TLS gets initiated (via 3xx redirect over HTTP port 80 usually) - google "sslstrip". That said - DNSSEC have somehow managed to mess up the key signing mechanisms, omitting verification/id checking and giving domain registrars unacceptable levels of access. 120.151.160.158 (talk) 20:52, 30 January 2014 (UTC)

OPT-IN[edit]

There should be mention of the OPT-IN controversy. This blocked deployment for many years. --Gorgonzilla 20:16, 11 August 2006 (UTC)

Is there some kind of known plain text attack that can be done on NSEC3 with '.com', '.org', etc... ? —Preceding unsigned comment added by 66.93.109.10 (talk) 14:06, 26 February 2008 (UTC)

Short names can be enumerated and checked for existence. The check can be done mostly off-line ( after the finite number of NSEC3 records have been found ), but is slowed by the number of hash iterations specified. So NSEC3 does make it harder for someone to obtain a list of domain names, especially where the names are long and not easy to guess. —Preceding unsigned comment added by 92.238.99.235 (talk) 08:46, 11 June 2010 (UTC)
It's not a new "vulnerability" as NXDOMAIN reveals exactly as much information. --KiloByte (talk) 14:27, 27 December 2012 (UTC)

trust anchors and rollovers[edit]

Can someone elaborate on "trust anchors" and the associated "rollover problem". These are mentioned in the article, but no information is given and no links are supplied. Dthvt 23:06, 5 December 2006 (UTC)

Deployment[edit]

The Internet is considered a critical infrastructure by many, yet it was originally based on the fundamentally insecure DNS.

There are a couple problems with that sentence. First, it's not strictly true: The internet builds on the Internet Protocol, and second, it's not actually true: The first name-to-ip translation was done through the hosts file (yes, that hosts file) and administrators asking other administrators to update their copy, and later on updating that file from a central site with a presumably well-known IP address. Third, there is that just about everything on the early internet started out as horribly insecure (the famous hardcoded sendmail backdoor, for one) and amazingly that was, back then, not a problem. Point being that singling out DNS is less than thruthful. Of course this is nitpicking, but we still need a better sentence there. 85.178.92.98 (talk) 11:42, 3 April 2008 (UTC)


This article is about DNS. It's not necessary to indicate problems with other systems. I suggest that for the purpose of this article, the above sentence is appropriate. We don't need a full history of the internet here, only an indication of what role DNS plays in it. It is reasonable to state that the internet is "based on" DNS even though it is not entirely accurate from a more complete point of view. —Preceding unsigned comment added by 206.186.240.194 (talk) 14:44, 21 November 2008 (UTC)

How about: "The Internet is considered to be critical infrastructure by many, yet its operation depends on the fundamentally insecure DNS"? That weakens the (slightly) problematic claim, and maintains simplicity and avoids dragging other protocols into the mix. It also avoids "an infrastructure". - Paul (talk) 17:55, 27 May 2009 (UTC)

Something missing perhaps...[edit]

This article doesn't actually seem to describe DNSSEC at all in any level of detail. It's great to talk about about zone enumeration problems at length but possibly an actual description beyond "things get signed" might be useful. —Preceding unsigned comment added by 212.35.31.33 (talkcontribs) 2009-01-24T21:06:06

Canada withdrawn ICANN support?[edit]

"For example, Canada's .ca TLD administration, CIRA (Canadian Internet Registration Authority), has withdrawn ICANN support."

This statement is not backed up by the reference cited. The link is now broken, The Internet Archive does have it and the letter from the CIRA just asks the ICANN to make certain changes; there is no suggestion that ICANN support was withdrawn.

I've removed this statement and the claim that there exist any top-level domains that exist without an agreement to ICANN.

217.169.15.243 (talk) 22:20, 24 February 2009 (UTC)

I know the .ca registry refused to pay the ICANN administration dues at one point, but I don't think we need to detail all of the ICANN drama that goes on. Indolering (talk) 06:26, 25 November 2016 (UTC)

less politics, more protocol[edit]

Maybe it is just me, but I find it a little strange that this article was almost completely about the politics and technical work-arounds, rather than discussing how the protocol actually works. I added a "how it works" section, but it could use some diagrams and more information. I don't think we need to go into the level of detail of how exactly the Key Tag value is calculated, but I think there could be more details than what I've added so far. Thoughts?

Things that I think could/should be added:

  • What are "trust anchors" and "rollovers" (as per the comment above)
  • How to apply DNSSEC to the last mile. (TSIG vs security-aware resolvers vs...)
  • Why is there a DS record, rather than just putting the DNSKEY record into the parent zone?
  • The difference between zone-signing-keys (ZSK) and key-signing-keys (KSK)
  • The CD and AD bits
  • What a domain has to do to support DNSSEC. Not how to set up a domain, that would violate WP:NOTHOWTO, but how it has to generate the keys, sign all the records, get the parent zone to add a DS record, etc.
  • Performance impact. Each DNS answer is larger, zones are larger, many more DNS lookups to get DS/DNSKEY records (although those may be cached), how resolvers have to do lots of calculations to verify things on the fly but authoritative servers can still server just static records.
  • how wildcards are handled.
  • the need to keep clocks synced.
  • *maybe* even get into things like how RRSIG records tell you the number of labels in the domain with the DNSKEY record and the Key Tag can help choose which of the DNSKEY records is the right one? I tend to think that is too much detail, but...
  • The different algorithms, which are optional, their advantages. (e.g. RSA/SHA-1 v DSA/SHa-1 vs ECC)

Wrs1864 (talk) 17:41, 2 March 2009 (UTC)

Note: it appears that the German version of the DNSSEC article covers much more of the protocol, maybe we could use that as a base using babelfish. Wrs1864 (talk) 01:57, 3 March 2009 (UTC)
I've stricken out the topics I've already added. Also, I've reviewed the german article and it doesn't seem to cover much that the english article doesn't already cover now. Wrs1864 (talk) 04:03, 8 March 2009 (UTC)
It's not just you. There's a ton of political stuff in there that just seems unnecessary, particularly now that the root zone is signed. And the technical stuff that's been added is very helpful. Abhayakara (talk) 16:26, 18 July 2010 (UTC)

..as automatic resigning of the zone..[edit]

What does this mean? The zone is resigned regulary? Why and how often? Would be great if someone could answer this, if I understand the answer I can add it to the article ;) --79.234.161.226 (talk) 15:41, 20 April 2009 (UTC)

The phrase you quoted is in the "tools" section of the article, where the descriptions are pretty short. I recently added a section on "key management" that discusses this more. I don't see a quick/easy way of answering this kind of question in the "tools" section, but I'll ponder it some more. Did you read the "key management" section? If so, what could be changed to make it clearer? I agree that the whole article is short on explaining the subject of what DNSSEC is and how it works, and instead spends too much time on the politics and deployment issues. Wrs1864 (talk) 16:00, 20 April 2009 (UTC)

I just read somewhere that it is necessary to resign the complete zone regulary and I don`t understand why. In my opinion it is just necessary to resgin the modified records at a DNS update and to resign the whole zone at a key rollover. --141.75.248.149 (talk) 14:38, 21 April 2009 (UTC)

With every technology comes decisions and trade offs. For DNSSEC, the signature lifetimes are somewhat different than other technologies where you probably don't care if the signature is long lived. In DNS, where record data may change, you may not want the signature to be long lived or else someone can replay previously valid data and the end-user will continue to believe it to be authentic. Zones that may change on a really rare basis may be perfectly fine with resigning on only rare events. Zones that are actively dynamic with rapidly changing data may have different signature lifetime requirements. Hardaker (talk) 20:22, 21 April 2009 (UTC)
That is clear for me, you have to resgin the record everytime it changes, otheriwse it would not be verifiable. Therefore the signature lifetime may not be too high, as the caching servers would otherwise cache old data. But if the signature lifetime is due, why do I than need to resgin the record? As I understood DNSSEC all records are stored anyway, there is no dynamically resigning. I can just check, whether it has been changed and if not, I just use the old signature. Using this way most of the records should not be resigned at all. --141.75.248.181 (talk) 10:50, 22 April 2009 (UTC)
If you accept old signatures of old data that hasn't changed then there is no way to securely remove records from DNS. With your proposal of ignoring the signature lifetime then the data may always be deleted or changed by anyone replaying the data (ie, forcing the previously good data into a cache and the cache will believe it). Hardaker (talk) 13:20, 22 April 2009 (UTC)
My proposal is not to ignore signature lifetime. We are talking about different things ;-) Signature lifetime is a good idea, otherwise you would have "wrong" data spread around. But if the signature lifetime is due, the server (in your example the cache server) will sooner or later ask my nameserver again. In the case data has not changed, I can give him the same RR, and a RRSIG with same signature but with updated signaure lifetime. Than I do not need to resign every record regulary. I just dont get why a record needs to be resigned every few minutes, for me it would be ok, to resign it after 30 days, or if it has been changed. --79.234.163.36 (talk) 21:51, 22 April 2009 (UTC)
You don't resign every few seconds. Signature lifetimes are normally fairly long (30 days is actually the most likely default in fact). And during that time, the name server will reserve the existing records without signing. (the signature lifetimes are (normally) much longer than the TTLs, eg). IE, I think DNSSEC is already designed to do what you want :-) Hardaker (talk) 13:41, 23 April 2009 (UTC)
Ok, good that was what I assumed :-) So I picked up wrong information. The only strange thing I found on the web is that the british were evaluating which signing hardware they should use. Actually then the signing process is not so timecritical, is it? --141.75.151.111 (talk) 13:54, 23 April 2009 (UTC)

Level of complexity of the system, and reasons.[edit]

The system described is fairly complex. It seems to me that it is explicitly designed with the idea that non-resolving servers are basically dumb servers, that do little more than look up lines in the zone file, and spit it out upon request. Most specifically, the servers do not have the private key, and are not dynamically signing output. Instead the zone file is signed, and distributed to the machines.

I don't care if those machines are who they say they are, or if they are compromised, as the data they output can be validated. If the data is valid, all is well, if not, that is equivalent to a DoS attack.

This is in stark contrast to traditional TTL style security, in which the key is on the machine, and if the machine is compromised, all bets are off.

Things would be simpler if we authenticated the machines, and assumed they were not compromised, since then a resolver would connect to a root server, and use the trust anchor to verify that it is talking to the root server. Get the information for the "com." TLD server, including information needed to authenticate the "com." TLD server. Then the resolving server connects to the "com." TLD server, and authenticates it. If the "com." server claims there is no "example.com." domain, then we can trust that there is not.

On the other hand, that requires smarter servers, creates some additional difficulties with with other things. For one thing it prevents the possibility of a verifying stub resolver, which currently allows the use of untrusted resolving servers.

That all sound right? 129.74.231.143 (talk) 22:12, 13 October 2009 (UTC)

The assumption that a machine that is connected to the Internet is sufficiently secure to be trusted making assertions of security on behalf of the entire Internet is questionable. Difficult to believe, actually. Also, signing is expensive, and you only want to do it once, not on every machine. So the capability to do offline signing not only means you can have the machine that has access to the keys somewhere where it can't be reached without sneakers and a floppy disk (or modern equivalent), it also means that you only have to sign the zone once, not (in the example of the root zone) twelve or more times. Abhayakara (talk) 16:26, 18 July 2010 (UTC)

Deployment across root servers[edit]

Wasn't DNSSEC deployed on the root servers on 05 May 2010? //Blaxthos ( t / c ) 02:07, 10 May 2010 (UTC)

I think the last server started issuing DNSSEC-enabled replies the other day, but the algorithm in use is still an invalid/reserved algorithm (8). This article says (but does not cite) that the real signatures and keys will not be distributed until July 1st. But from my understanding, the whole affair is coordinated by ICANN, VeriSign, and the Dept. of Commerce, so who knows. I for one cant wait to fill my `/etc/trusted-key.key' file. Int21h (talk) 05:46, 10 May 2010 (UTC)

Supposedly it's live. Abhayakara (talk) 16:26, 18 July 2010 (UTC)

I made the following edit having to do with deployment--this:

Many are interested in deploying DNSSEC at the root level.[who?] If deployed widely at the root level, DNSSEC could support distribution of public keys associated with any arbitrary domain name, countering many spam and spoof attacks.[citation needed] Having a few DNS root-level DNSSEC public keys would greatly simplify the deployment of DNSSEC resolvers, since those few keys could be the basis for any other key.[citation needed]

changed to this:

DNSSEC was first deployed at the root level on July 15, 2010.[1]This is expected to greatly simplify the deployment of DNSSEC resolvers, since the root trust anchor can be used to validate any DNSSEC zone that has a complete chain of trust from the root. Trust anchors must still be configured for secure zones if any of the zones above them are not secure, however.[citation needed]

The main motivation for this change was to reflect that DNSSEC is in fact deployed at the root now, and why that's useful. I took out the sentence in the middle that talked about stuffing public keys in the DNS and about using DNSSEC to fight spam. I don't think what that sentence said about spam is true, and stuffing public keys in the DNS is probably not a wise security strategy by itself, whether it's signed or not. If the author of that sentence could maybe expand it into a paragraph to clarify the point they're trying to make, I think it would be helpful. Abhayakara (talk) 16:32, 18 July 2010 (UTC)

DNSSEC deployment by ISPs[edit]

Edited the article to point out that they were the first "major" to do so. My employer (a small-medium sized ISP in the midwest) had been validating ISC DLV on the main recursive nameservers since before the DURZ was even published. I refrained from adding their name as I thought while commendable, it didn't meet notability guidelines.

Though this section itself should probably be expounded on and rearranged so it doesn't become a list of ISPs that have deployed DNSSEC resolvers and when. woops, forgot signature --208.83.66.136 (talk) 04:05, 28 December 2010 (UTC)

DNSSEC all the way to the user?[edit]

Could somebody who knows add a paragraph to explain if the major versions of windows(TM) XP, Vista, and 7 are secure from the ISP's DNS server to the user? Also, is Ubuntu safe to the user? Is there a command to check if the connection is secure? —Preceding unsigned comment added by 71.131.9.76 (talk) 16:26, 11 April 2011 (UTC)

Windows is; your Windows is (probably) not. Unless you have an IPsec-secured connection to your ISP, which you, like 99.9% of the world, probably don't. No idea about Ubuntu and its versions of libc DNS resolvers... Int21h (talk) 18:02, 21 December 2011 (UTC)
I have edited the sections on the lookup procedure. While I cannot find a source that outright says no one's computers are secure even with DNSSEC because they do not use IPsec with their DNS, I think people can connect the dots easier now. Int21h (talk) 18:49, 21 December 2011 (UTC)

How socially relevant is this?[edit]

DNSSEC is a protocol specification that nearly no-one is using. Therefore i wonder what the relevance is of putting it up in an encyclopedia. Is this just protocol promotion and explanation? Should other "standards" also be just as elaboratly explained? — Preceding unsigned comment added by 217.149.140.2 (talk) 18:13, 20 December 2011 (UTC)

Very relevant, because it actually is being used. Most root nameservers have DNSSEC signatures. 82.133.80.50 (talk) 13:25, 21 December 2011 (UTC)
"HTML5 is a protocol specification that nearly no-one is using. Therefore I wonder what the relevance is of putting it up in an encyclopedia. Is this just protocol promotion and explanation? Should other 'standards' also be just as elaboratly explained?" Putting your comments in perspective, does this make more sense? You may say, "Oh, but HTML5 is being used and DNSSEC is not, or at least not as much." But this would be an argument to ignorance. This statement was just as true as your statement not so long ago, but should that have meant there should have been no HTML5 article? There is more going on than what you see in your web browser. Int21h (talk) 17:46, 21 December 2011 (UTC)

Google Public DNS[edit]

This section is misleading and or false. Google DNS can and indeed should be validating any recursive query from their servers to a root or domain root. They can provide information on the authoritative nameservers but they cannot themselves validate the result for the client. As the scheme is suggested here, Google can act as the authoritative root and redirect to edited or changed webpages, or act as a proxy between the query target and the client. Scottygage (talk) 11:30, 13 October 2016 (UTC)

  • MORE from above; Google is only authoritative over the google.com domain and any subdomains. Google public DNS can only provide authoritative answers and DNSSEC validation against the google domain, but even full validation of the google domain requires a further query to the .COM domain root in order to verify the NS records given by Google match records at the regional assigning authority. Google is not a root.

Not illegal in Germany after all[edit]

The article states that according to DENIC, DNSSEC is illegal in Germany and other countries, without providing any source. Bt according to the DENIC Web site, DNSSEC has been deployed in Germany: http://www.denic.de/en/domains/dnssec.html

I believe this statement should be removed from the article. — Preceding unsigned comment added by 77.242.202.133 (talk) 11:15, 21 June 2012 (UTC)

NSEC[edit]

About half of article's body is about NSEC and long-solved problems with it. Does anyone even use something else than NSEC3 these days? Let's reduce that part and deliberate on something more relevant instead. --KiloByte (talk) 14:30, 27 December 2012 (UTC)

Yes, there are pros and cons to NSEC and NSEC3. You should pick the right one for your situation, which is probably something the article *should* cover (the differences). NSEC3 is certainly used by most registries, because they need the opt-out support. But I know of a number of sites that deliberately chose NSEC, and it's still the default for most tool sets too. Hardaker (talk) 16:45, 27 December 2012 (UTC)
I mean, it does deserve a mention, but the historical discussion is way too massive.--KiloByte (talk) 02:01, 1 January 2013 (UTC)

This is basically a non-issue as everyone who cares uses online signing and anyone that doesn't like online signing can eventually switch to NSEC5. This section should be cut down to a single paragraph. Indolering (talk) 06:30, 25 November 2016 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 11 external links on Domain Name System Security Extensions. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

As of February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete the "External links modified" sections if they want, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{sourcecheck}} (last update: 15 July 2018).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.


Cheers.—InternetArchiveBot (Report bug) 21:57, 14 December 2016 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 4 external links on Domain Name System Security Extensions. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

As of February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete the "External links modified" sections if they want, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{sourcecheck}} (last update: 15 July 2018).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.


Cheers.—InternetArchiveBot (Report bug) 05:05, 12 September 2017 (UTC)

External links modified (January 2018)[edit]

Hello fellow Wikipedians,

I have just modified 3 external links on Domain Name System Security Extensions. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

As of February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete the "External links modified" sections if they want, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{sourcecheck}} (last update: 15 July 2018).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.


Cheers.—InternetArchiveBot (Report bug) 11:19, 20 January 2018 (UTC)

  1. ^ "Root DNSSEC Status Update, 2010-07-16". 16 July 2010.