Talk:Domain Name System Security Extensions
This is the talk page for discussing improvements to the Domain Name System Security Extensions article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1Auto-archiving period: 12 months ![]() |
This is the talk page for discussing improvements to the Domain Name System Security Extensions article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1Auto-archiving period: 12 months ![]() |
![]() | Computing C‑class Low‑importance | |||||||||
|
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)
- 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)
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)
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)
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
23:18, 17 January 2021 (UTC)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.
- 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
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
![]() | It has been proposed in this section that Domain Name System Security Extensions be renamed and moved to DNSSEC. A bot will list this discussion on the requested moves current discussions subpage within an hour of this tag being placed. The discussion may be closed 7 days after being opened, if consensus has been reached (see the closing instructions). Please base arguments on article title policy, and keep discussion succinct and civil. Please use {{subst:requested move}} . Do not use {{requested move/dated}} directly. |
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)
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)
- Oppose for the same reasons multiple editors have opposed at Talk:Domain Name System#Requested move 31 March 2021. Dyork is correct; many engineering and scientific documents use "Domain Name System Security Extensions (DNSSEC) exactly once in the first paragraph and then use "DNSSEC" hundreds of times. Ngrams are a nice tool, but like all tools they have limitations. --Guy Macon (talk) 02:26, 1 April 2021 (UTC)
- Comment I would like to point out that the name of this article was DNSSEC before, but it was WP:BOLDLY moved. See here. PhotographyEdits (talk) 11:40, 1 April 2021 (UTC)
- Oppose. kbrose (talk) 20:27, 1 April 2021 (UTC)
- Question Why don't we have a redirect from (all caps) DNSSEC to here, rather than the existing one: Dnssec to here? ---Avatar317(talk) 21:34, 1 April 2021 (UTC)
- Both redirects exist. See DNSSEC and Dnssec ("dnssec" is automatically included in "Dnssec"}. --Guy Macon (talk) 01:53, 2 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)
- 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)
- Support per WP:COMMONNAME.--Ortizesp (talk) 01:35, 14 April 2021 (UTC)