Jump to content

Talk:Domain Name System Security Extensions/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

trust anchors and rollovers

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)

..as automatic resigning of the zone..

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)

Deployment

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)

less politics, more protocol

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)

Level of complexity of the system, and reasons.

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

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)

References

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

DNSSEC deployment by ISPs

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)

How socially relevant is this?

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)

DNSSEC all the way to the user?

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)

Not illegal in Germany after all

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)

OPT-IN

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)

Absolutely terrible article (as of Nov. 2013)

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)

Google Public DNS

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.

Canada withdrawn ICANN support?

"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)

NSEC

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)

DNSSEC deemed complete and utter failure (as of Jun 2019)

Geoff Huston, chief scientist of APNIC, champion of DNSSEC for the sake of DANE, presented to the Internet Architecture Board and has essentially said that DNSSEC is an utter failure.

A protocol that would be clearly informative of efforts to identify when the DNS is being altered in various ways by third parties would have an obvious role and would be valued by users. Or so we thought. DNSSEC was a protocol extension to the DNS was intended to provide precisely that level of assurance, and it is a complete and utter failure.

http://www.circleid.com/posts/20190611_network_protocols_and_their_use/ — Preceding unsigned comment added by 101.175.11.227 (talk) 00:16, 16 June 2019 (UTC)

That is total BS. You see .com., .ru., are still signed, so it is not failure. Next, DANE is deprecated for DoT in Android 9 and DoH in pretty much everywhere else. So lol. 91.79.174.204 (talk) 08:01, 1 May 2020 (UTC)
And interestingly, APNIC's DNSSEC stats showed the continued growth in DNSSEC validation. - Dyork (talk) 01:24, 2 May 2020 (UTC)

Something missing perhaps...

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 (talk • contribs) 2009-01-24T21:06:06 21:06, 24 January 2009 (UTC)

Article out-of-date - needs some updates on deployment statistics and more

I noticed down under the section on Planning there is the statement:

As of November 2011 more than 25% of top-level domains are signed with DNSSEC.[49]

That number has grown significantly in the nine years since that time.

There are also a number of other references that are dated. Someone with some time needs to really go through and bring this article more up-to-date. I'll try to do so as I have cycles, but would encourage other editors to consider doing so, too. - Dyork (talk) 01:37, 4 June 2020 (UTC)

Section on DNSSEC Lookaside Validation - could add info about removal from software

In the section on DNSSEC Lookaside Validation, the text says:

It is not clear yet if or when DLV support will be removed from BIND and other implementations of validating resolvers.

At this time in 2020, DLV has been retired by RFC 8749 and I believe support for it has already been or is being removed from most resolver software. At some point someone could look at some of the validating resolvers to see anyone is still supporting DLV and update that statement with info about the versions that stopped supporting it. I'm thinking of something like "Support for DLV was discontinued in BIND as of version XXX and in (other software) as of version XXX." - Dyork (talk) 01:32, 4 June 2020 (UTC)

Addressed today Vickyrisk (talk) 20:05, 5 June 2020 (UTC)

Needs mention of Root KSK Rollover in 2019

The article has no mention of the Root KSK Rollover in 2019. There are many articles about this in the media and there was an exhaustive comment period from ICANN. It probably needs a whole section in here about the KSK. - Dyork (talk) 01:40, 4 June 2020 (UTC)

Is Dyork referring

In 2018, ICANN changed the trust anchor for the DNS root for the first time. Many lessons were learned about DNSSEC during that process. Furthermore, many resolver operators became more aware of DNSSEC and turned on validation, and the world got to more clearly see how the entire DNSSEC system worked.

— bottom lines of https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en
23:18, 17 January 2021 (UTC)
Yes, that is what I'm referring to. The root "key signing key" (KSK) was rolled over on 11 October 2018. ICANN has a great amount of info about it and there were many media reports, too. Someone of us (editors) just needs to write some text for the article. - Dyork (talk) 02:14, 18 January 2021 (UTC)

A few words about "zone enumeration"

Prevention of "zone enumeration" where desired

— At the bottom lines of Domain_Name_System_Security_Extensions#Overview

I didn't know what is "zone enumeration". Turned out it is also called zone walking. DNSSEC target to accurately point non existent domains is considered to amplify the zone enumeration effect. I found https://www.zerosuniverse.com/ethical-hacking/what-is-dns-enumeration/ an enlightening short article. Continuing reading,

NSEC3 … uses cryptographically hashed record names to avoid the enumeration

— Domain_Name_System_Security_Extensions#Resource_records

Turns out there is more discussion at Domain_Name_System_Security_Extensions#Authenticating_NXDOMAIN_responses_and_NSEC. 02:58, 19 January 2021 (UTC)

Does this article need mention of the Trusted Community Representatives?

Reading about the recent death of Dan Kaminsky, I saw that he was a DNSSEC TCR, some of which help manage the root key for the whole thing. I wanted to find out more about this but was surprised to find out that TCRs (their role, how they're selected, etc) are not discussed in this article. Does anyone familiar with the topic think it might be a good subject to add a paragraph about? In case notable TCRs are appropriate to mention, I checked a couple of random names in the list and found two others notable enough to have articles (Bevil Wooding and John Curran (businessman).) EditorInTheRye (talk) 20:10, 28 April 2021 (UTC)

  • @EditorInTheRye: I think it's actually a bit of a bigger challenge. As I mentioned earlier on this talk page there is no mention in the article about the Root KSK Rollover in 2019. Since writing that, I actually found a brief mention over in the DNS root zone article, but it's just that... brief! This article could really have a bit more of an explanation about how ICANN manages the root key, the fact that they have regular key signing ceremonies in two different data centers, and yes, the role of the TCRs in all of that. There is a good bit of info on IANA's site and also in various media articles that have been written over the years. It's just that "someone" has to make the time to go through all that and add appropriate text to this article. 🙂 - Dyork (talk) 02:22, 29 April 2021 (UTC)

Requested move 31 March 2021

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: There's consensus to use the full name of the protocol in the article title. Some editors expressed that many RS will give the full name of the protocol at first mention and then the acronym afterwards, and this style is considered better for Wikipedia, as well as being used in many related articles. (non-admin closure) (t · c) buidhe 13:09, 16 May 2021 (UTC)


Domain Name System Security Extensions → DNSSEC – Per the Google Ngram viewer here, far less people are using the full name. Per WP:COMMONNAME, DNSSEC should be used. PhotographyEdits (talk) 12:10, 31 March 2021 (UTC) —Relisting. BD2412 T 00:29, 9 May 2021 (UTC)

  • Uncertain - In general I don't like to use acronyms for page titles, however I do understand the MOS:ACROTITLE principle, and in the case of "DNSSEC" I suspect that a very high percentage of visitors will search for the acronym instead of the full name. At this time I do not directly "oppose" this move as I have done over on the Talk page for "DNS". However, as I did there, I do question whether the Google Ngram Viewer is giving us the most accurate data to help us decide. If that tool is search books for both "Domain Name Security Extensions" and "DNSSEC", then it will naturally find few occurrences of the full name and many occurrences of the acronym because that is how authors write! Is there perhaps a different tool that could look at Google search volume or something similar? - Dyork (talk) 01:21, 1 April 2021 (UTC)
@Dyork: Let me point out that searching for both terms gives me 60k results here , and only searching for the abbreviation gives 6 million results, see here, which implies that a lot of websites use the abbreviation without explaining the full name. PhotographyEdits (talk) 11:48, 1 April 2021 (UTC)
@Dyork: Please vote if you have made a decision about it. I'd like to note that you have linked it as DNSSEC on your own user page, contrary to Session Initiation Protocol PhotographyEdits (talk) 13:23, 7 April 2021 (UTC)
  • Oppose - (Changing from 'Uncertain' to 'Oppose') I just went through and reviewed the other articles in the Internet Security Protocols template box and in the Internet protocol suite and in almost all the articles for other protocols, the title is for the full name of the protocol (with HTTPS and DMARC being two exceptions). I think for consistency with the overall suite of articles, and for reasons others have cited, this article should continue to be titled with the full name of the protocol. - Dyork (talk) 00:13, 8 April 2021 (UTC)
Thank you for pointing that out. I guess I don't understand Wikipedia's search algorithm, because typing D N S S . . always auto-completes to Dnssec, and unless you type the entire DNSSEC and hit return then you are led to the Dnssec redirect. I guess this is what I think could be improved; I don't think that the literature ever calls it "Dnssec". ---Avatar317(talk) 03:00, 2 April 2021 (UTC)
Yes, our search function sucks. See WP:CANCER to see what we spend money on instead. One of the way it sucks is that it capitalizes search terms, which is how most people search. If I do a search on "DnSsEc" it should say "(Redirected from DnSsEc)" instead of "(Redirected from Dnssec)" --Guy Macon (talk) 03:46, 2 April 2021 (UTC)
  • @Avatar317: - do you have an opinion (either 'oppose' or 'support') on the requested move? You don't have to.. but I am just wondering if you do so that we can perhaps move closer to a consensus (or a lack of consensus). Just curious. - Dyork (talk) 01:38, 14 May 2021 (UTC)
  • 3 opposed
  • 2 supporting
I would also note that a similar request to move was raised for Domain Name System on March 31, and the result was a consensus NOT to move the page to "DNS". I have already stated my opposition above, but I would further strengthen it by stating that I think this page should be consistent with the Domain Name System page, i.e. spelling out the entire name in the title. - Dyork (talk) 02:39, 9 May 2021 (UTC)
  • @PhotographyEdits: It happens that I am the guy who wrote that particular page on the Internet Society's website.🙂 (That is my employer.) I do understand MOS:ACROTITLE, but I still oppose changing this Wikipedia article title. I think article titles should spell out the whole protocol name, as if you were encountering it the first time in a publication. And, in this case, I think that the article for DNSSEC should remain consistent with the article for DNS, where the full name is spelled out. - Dyork (talk) 01:34, 14 May 2021 (UTC)
  • @Dyork: Nice that you wrote that. But, the Wikipedia article title should refer to the commonly known name, and the first sentence should explain the full name. I think that the subject is primarily known for its abbreviation and that the same applies for DNS. Another example is IPsec, which is the common name for Internet Protocol Security, while the Internet Protocol article has a fully spelled out title. PhotographyEdits (talk) 09:07, 14 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Domain_Name_System_Security_Extensions/Archive_1&oldid=1088277115"