Can a person educated, please offer an extensive reply concerning the distinctions and also advantages/disadvantages of both strategies?

I am not a DNS specialist, not a designer. I have a suitable standard understanding of DNS, and also sufficient expertise to recognize just how points like the kaminsky bug job. From what I recognize, DNSCurve has more powerful security, is much less complex to arrangement, and also a completely far better remedy.

DNSSEC is unnecessarily made complex and also makes use of breakable security, nonetheless it gives end to end security, something DNSCurve does not. Nonetheless, most of the write-ups I have actually read have actually appeared to show that end to end security is of little usage or makes no distinction.

So which holds true? Which is the far better remedy, or what are the disadvantages/advantages of each?


I would certainly value if a person can clarify what is obtained by securing the message materials, when the objective is verification as opposed to discretion.

The evidence that keys are 1024bit RSA keys is here.

2022-06-07 14:36:08
Source Share
Answers: 5

Its important to understand "trust" rather than "encryption" is the key to security. You can have a "secure" conversation with someone using "encryption" but what good does it do you if the person on the other end is not who you think they are?

The major take-home difference between DNSSec and DNSCurve is that DNSSec signs everything, there is a clear trust-chain from the root all the way up to the host records provided by each operators DNS servers.

DNSCurve does NOT sign anything there is no trust chain at all. DNSCurve focus is narrowed to preventing passive or blind poising of DNS responses.

It boils down to practicality... There are huge operational challenges with DNSSec - how do you practically create a trust anchor the size of the planet? When the millions upon millions of domains are being signed what mechanisims are used to instill confidence that keying material necessary to forge any signature does not fall into the wrong hands or is not used improperly? Trust on a large scale is very difficult from an operational perspective to pull off and maintain.

DNSCurve does not even try.

Now having answered the basic question heres my take of what the problem to be solved actually is and which of the two technologies is a better fit.

The Internet is inherently as much a condiut of nonsense as it is of salient discussion and enlightenment. In my view a fully trust-worthy Internet isn't a reasonable or obtainable goal and if it were to become so there would likely be negative implications in terms of freedoms and anomyous speech and actions.

In my opinion all thats needed is a DNS solution which is at least as trustworthy as the underlying transport. It needs to practically prevent poisioning of DNS records by attackers who blindly inject false messages or passivly sniff requests and forge UDP responses. It does NOT need to gurantee security above and beyond that. This way the Internet continues to route packets and provide DNS services in a reliable but not necessarily secure manner.

DNSSec and its global trust anchors in my opinion is a fools errand which focuses almost entirely on solving a problem that does not exist. (All end-end encryption systems that can be used over the Internet already have their own methods for verifying identity)

DNSSec is slow, expensive and will significantly delay the clear and present issues with DNS that like moving to IPv6 should have been resolved yesterday.

What DNSCurve does is protect the network so that the naming service is at least as reliable as the underlying transport of packets over the network but not more so. In my view it solves the exact problem that is actually being faced in the real world. DNSCurve prevents passive MITM but it does not practically protect against active MITM without ssh style "leap-of-faith" signature caching.

To play the devils advocate large scale deployment of DNSSec can potentially have positive implications. The PKI infustructure can replace the SSL secure server CAs and provide some trust binding for IPSec and other encrypted conversations between peers.

2022-07-16 16:05:47

Honestly? Neither suffices. DNSSEC falls down under its very own weight: it is extremely made complex, packed with openings, and also will possibly never ever function effectively. DNSCurve is efficient what it does, yet does not go virtually much sufficient. It is less complicated to spot right into a DNS web server, yet as a result of the method which it was created and also is being advertised, will possibly never ever see prevalent usage.

I prefer to release DNSCurve than DNSSEC on my very own (recursive) DNS web server, yet just due to the fact that DNSCurve is extra specific concerning what it can and also can refrain, and also does not give an incorrect complacency the means DNSSEC can - - a great deal of clever individuals assume DNSSEC suffices, and also it is not .

My suspicion is that there is even more yet ahead in the DNS security battles, and also we'll possibly see a 3rd alternative arise. With any luck it'll be improved DNSCurve, given that I assume DNSCurve is exceptionally well - made for safeguarding the avenue in an in reverse - suitable fashion.

2022-06-08 04:02:33

I have actually gotten to a verdict, that DNSCurve is a far better alternative.

Due to the fact that:

DNSSEC makes use of 1024bit RSA keys for finalizing, which were currently taken into consideration solid in 2003 by huge netowrks, botnets. The instance is still real today.

To be appropriately applied much code needs to be revised.

The origin web servers will not authorize the full database, not supplying complete defense.

Replay strikes approximately 30 days after a domain name runs out are feasible.

In order to attain security it is essential to reveal all domain.

DNSCurve does not have these troubles, and also permits verification, schedule and also discretion (as in not needing to reveal names) in such a way DNSSEC does not. In addition, it calls for no code alterations, simply added software program.

It additionally has actually defense versus built packages, which DNSSEC does not, along with defense versus replay strikes, as a result of making use of nonces. DNSCurve might undergo a MITM strike that DNSSec is not, yet it is my understanding that if DNSCurve was applied right to the origin, this would certainly not hold true.

2022-06-08 03:32:07

A comment on LWN asserts

DNSCurve safeguards the avenue, not the message. It can not be made use of to shield versus destructive caches, and also isn't a functionnal matching to DNSSEC.

and also web links to a discussion in French.

2022-06-07 16:31:02

DNSCurve gives real security to DNS packages, albeit just on a jump - by - jump basis, and also especially on the jump in between the recursive web server and also the reliable web server.

When made use of on that particular course it can give verification of the area information. Nonetheless any kind of customer better downstream can not gain from this verification due to the fact that the protection is just "hop - by - hop". A destructive resolver beinged in the center of the resolution course can still give incorrect information.

DNSSEC on the various other hand gives an end - to - end proven cryptographic trademark that confirms that the information obtained coincides as that on the reliable web server. DNSSEC makes use of cryptographic strategies, yet does not in fact secure any kind of DNS website traffic.

DNSCurve is use elliptic contour security formulas allows a lot smaller sized keys to be made use of than with RSA to attain the very same degree of cryptographic toughness. Nonetheless there are propositions to include comparable formulas in the checklist intended by DNSSEC.

DNSSEC is standardised by the IETF (RFC 4034 and also RFC 4035, upgraded by RFC 5155) and also applied in numerous preferred name web server executions, consisting of BIND (certainly) and also NSD/Unbound. PowerDNS will certainly have DNSSEC assistance soon.

DNSSEC is unquestionably made complex yet initiatives are recurring to streamline this (see as an example http://opendnssec.org/) and also release is raising every one of the moment. Numerous TLDs (. se,. br,. org,. gov, etc) are currently authorized with DNSSEC and also it has actually been introduced that the origin area will certainly be DNSSEC authorized by the end of the year.

DNSCurve is fairly intriguing, yet as a result of the independent method which it has actually been created it has really little opportunity of seeing any kind of substantial release. IMHO it has absolutely no opportunity of ever before being released on the origin web servers.

BTW your assertion concerning DNSSEC making use of "breakable encryption" seems entirely misguided. On what basis do you claim that?

Area finalizing keys are generally (yet not always) 1024 little bits long. These keys are commonly rolled on a monthly basis approximately, and also existing ideal price quotes are that it would certainly take at the very least a number of years to brute force a 1024 little bit key.

Now in time a brute - pressure strike versus 1024 - little bit RSA would certainly call for concerning 2 years on a couple of million calculate cores with several 10s of gigabytes of memory per cpu or mainboard

which isn't specifically your regular botnet. From the very same paper:

Next taking into consideration unique objective equipment, one of the most confident strategy recommends that sieving for a 1024 - little bit RSA modulus can be carried out in a year for concerning United States $10,000,000, plus a one - time growth price of concerning United States $20,000,000, and also with an equivalent time and also price for the matrix. In our point of view, (usual) apprehension fulfilled by such layouts is close to the factor. Such figures need to not be taken upper bounds, i.e., "Be mindful, 1024 - little bit RSA can be damaged in 2 years for concerning twenty million dollars (thinking free growth), " yet as lower bounds, i.e., "No factor to stress way too much: also under really desirable strike problems, factoring a 1024 - little bit RSA modulus still calls for substantial resources." The price quotes need to hence not read as harmful yet as confidence - motivating.

Or from a one years of age PCPro article:

To place that right into viewpoint, to fracture an RSA 1,024 - little bit key Kaspersky approximates it would certainly take something like 15 million computer systems running all out for a year to do well

Frankly, no - one is mosting likely to place that quantity of initiative right into fracturing one domain name is ZSK!

Besides, the actual protection remains in the key finalizing keys, and also those are generally at the very least 2048 little bits and also usually much longer (4096 little bits). The quantity of time it requires to fracture an RSA key climbs greatly with the key size, not linearly.

2022-06-07 15:45:45