Jump to content

Talk:Domain Name System Security Extensions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by EditorInTheRye (talk | contribs) at 20:10, 28 April 2021 (→Does this article need mention of the Trusted Community Representatives?: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

WikiProject iconComputing 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.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
CThis article has been rated as C-class on Wikipedia's content assessment scale.
LowThis article has been rated as Low-importance on the project's importance scale.


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

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)[reply]

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)[reply]
And interestingly, APNIC's DNSSEC stats showed the continued growth in DNSSEC validation. - Dyork (talk) 01:24, 2 May 2020 (UTC)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)

Requested move 31 March 2021

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)[reply]

  • 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)[reply]
@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)[reply]
@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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]

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 DNSSEC or 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)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Domain_Name_System_Security_Extensions&oldid=1020386897"