Hot answers tagged

49

There's a problem: DNSCurve is more like TLS for DNS servers, in comparison to DNSSEC, which is signed records. DNSCurve uses point-to-point cryptography to secure communication, while DNSSEC uses pre-calculated signatures to ensure the accuracy of the supplied records. So we can summaraize it like this: DNSSEC: Accurate Results DNSCurve: Encrypted Traffic ...


45

DNS Zone transfer is the process where a DNS server passes a copy of part of it's database (which is called a "zone") to another DNS server. It's how you can have more than one DNS server able to answer queries about a particular zone; there is a Master DNS server, and one or more Slave DNS servers, and the slaves ask the master for a copy of the records for ...


28

DNSSec is normal DNS, but with signatures. It absolutely prevents DNS Spoofing; that's what it's for, and that's what it does. Registrars can still theoretically abuse their position because they're responsible for communicating your intentions to the root servers. This includes information about your DNSSec keys. This relationship will never change; if ...


18

DNSSEC and DNSCurve address completely different aspects of DNS security. First of all, DNSSEC does NOT sign your queries. Rather DNSSEC allows a zone (such as a domain) to be signed by its owner, and allows a resolver (for instance, Comcast's DNS servers) to verify the signature, and therefore be sure that the zone data it gets is authentic. It protects ...


17

@GrahamHill already explained a zone transfer pretty good already, but I'll try to fill in some more. By being able to query for all records from the DNS server, the attacker can easily determine which machines are accessible. The zone transfer may reveal network elements that are accessible from the Internet, but that a search engine like Google (site:....


16

There is a RFC for that. It is part of what DNSSEC is meant to do. Now don't get too hopeful about "top dollar" or reduction thereof. The need to "certify" in some way public keys with regards to server names is not magically removed by switching to DNSSEC. The "CA" role is just moved around, and the associated costs are still there. It can be predicted ...


15

Why not get rid of all certificate authorities and all the special kind of SSL certificates there are (extended validation etc. etc.) and instead just require anyone who wanted SSL to write their own self signed SSL certificate and then have them stored in DNS records. There is even a standard for this: DANE. And it is already in use with some sites, but ...


15

The average user, in my opinion, shouldn't spend any time whatsoever thinking about DNS attacks. First, it just doesn't happen on a scale that warrants such attention. When phishing attacks, ransomware, and password guessing are rampant, users are infinitely better off spending what little security motivation they have on preventing those. Second, an ...


14

It is actually unclear whether DNSSEC is "what we want". Right now, the certification of Web site, i.e. how a Web browser makes sure that it talks to the right site (when doing HTTPS) is done with digital certificates emitted from about a hundred of Root Certification Authorities. The root CA are entities who decided to go into the certificate issuance ...


10

The major reason is that DNSSEC was already being adopted by the major root servers when DNSCurve came out. Furthermore they do not tackle the same problems, they overlap on some points but differ on others. They could very well be used together. Note that we have had a question DNSSec (Comcast) vs DNSCurve (OpenDNS) which details the differences very well:...


10

TL;TR: In some use cases like HTTPS (web) DNSSec is not really needed. In other use cases like SMTP (mail) DNS spoofing will not be noticed by TLS, that is man-in-the-middle is possible if DNS can be spoofed even if TLS itself is properly used. Details: When used within HTTPS (web) and the currently established CA system you don't need DNSSec, because the ...


9

No. DNSSEC does not protect the integrity of a DNS name if the registrar for that name is malicious (or compromised). The registrar for grumpyavians.com is the ultimate source of authority for who owns grumpyavians.com (and, e.g., what is the public key for grumpyavians.com). Consequently, if the registrar is malicious or compromised, then the registrar ...


8

The "Kaminsky bug" (CVE-2008-1447) affects "BIND 8 and 9 before 9.5.0-P1, 9.4.2-P1, and 9.3.5-P1".


8

makerofthings7 wrote: it seems TOR is better/more secure since it doesn't use DNS, and it doesn't rely on CAs Just as it's ultimately the user's responsibility to verify a TLS certificate before accepting it, it's the user's responsibility to verify that an onion address is the intended address. By starting with (a) I know an onion address (b) I know ...


8

Most likely not. IPv6 support is still quite patchy in many parts of the world. The delay is most likely caused by bad routing or network packets having to go through too many hops. You can test out your IPv6 connection here. The hosts file is used to bypass DNS and make your access to websites matching domains listed slightly faster, not slower. A whois ...


8

The Chromium security team say: DNSSEC and DANE (types 2/3) do not measurably raise the bar for security compared to alternatives, and can be negative for security. DNSSEC+DANE (types 0/1) can be accomplished via HTTP Public Key Pinning to the same effect, and with a much more reliable and consistent delivery mechanism. (see https://bugs.chromium.org/p/...


7

One problem with HTTPS is that you need to trust the root CA. And most browsers have many of those by default. With TOR hidden services, the .onion address itself contains a hash of the server public key, so you don't need any CAs. But the main issue is that .onion addresses aren't very user friendly. So the problem shifts to getting/verifying that you're ...


7

If you're willing to rely on an online service (and don't mind one that is pretty picky), the DNSSEC Checker will warn (among other things) about zones that don't use NSEC3. To check by yourself, simply query a non-existent domain and look for either an NSEC or NSEC3 resource record in response. An example query would be dig +dnssec -t any xyzzy14.sdsmt....


7

I strongly believe that the pure usage of DNSSEC should not be indicated to the user at all. DNSSEC just ensures that the DNS lookups are not tampered with by third (fourth?) parties. DNSSEC does not ensure that the connection is really established with the returned IP-address nor that no attacker is listening in on the data. So pure DNSSEC is way too ...


7

Properly used https can mitigate the risk of not using DNSSsec because it is checked if the endpoint is the expected one by validating its certificate. Also, the data transport itself is protected. There are several things which can go wrong with https itself (weak ciphers, errors in validation process, too much trusted root CAs with same rights....) but if ...


7

Regular DNS responses are like business cards - while you can generally trust them when someone hands theirs to you, they're actually just ink and card stock, and anyone who is even a little motivated can get their own made by a print shop. And there's no way to enforce their validity; I can go to (for example) VistaPrint and they'll ship my "He-Man, Master ...


6

The CERT RR has been deprecated. The current proposal for putting public key material in DNS is called DANE. They have defined a TLSA record type which is documents in RFC 6698. This lets a domain administrator assert a specific certificate, or a CA for a particular service.


6

According to http://backreference.org/2010/11/17/dnssec-verification-with-dig/: Obtain root keys. You can do this with dig on an unpoisoned machine: dig . DNSKEY | grep -Ev '^($|;)' > root.keys Verify your target dns record: dig +sigchase +trusted-key=./root.keys www.eurid.eu. A | cat -n The other alternative is to set up a validating DNS resolver ...


6

"more", yes. But that's not meaningful if the threat you're trying to counter is not the vulnerability being used against you. MITM attacks are a strange thing to ask about in Tor hidden services. If you trust the hidden service (maybe you met somebody who handed you a .onion url?), and you trust your Tor client (i.e, the MITM is not feeding you tainted ...


6

Yes, DNSSEC is immune to this kind of attack. Starting at an anchor (usually the root, sometimes DLV), every delegation is either explicitly secure (presence of DS set on delegation): powerdns.com. 172800 IN NS powerdnssec1.ds9a.nl. powerdns.com. 172800 IN NS powerdnssec2.ds9a.nl. powerdns.com. 86400 IN DS 44030 8 3 ...


6

It solves integrity guarantee. It will no longer be possible to MITM a signed zone. Right now anyone could falsify DNS records, with DNSSEC they cannot. The client already knows the public key of the root zone and can verify the whole chain down to the zone. When you register a domain, you must tell the TLD zone where your nameservers live. At that point, ...


6

The idea of the DNS-based Authentication of Named Entities (DANE) protocol is that domain owners publish the fingerprint of a certificate that their server uses in a DNS resource record. It is a measure to prevent certificate forgery. Users that wish to connect to the server via TLS can look up the fingerprint of the presented certificate in the DNS record ...


6

There are several things which went wrong here and MyEtherWallet could have done things to reduce the risk. The issue was that the traffic to the DNS server was hijacked and thus queries for specific domains resulted in a spoofed response, thus directing the browser to the attackers IP address with a server impersonating the original site. There the user was ...


5

The only thing wrong with DNSSEC is that it's new, DNS is (obviously) important and people are reluctant to mess with their DNS setup. If your DNSSEC deployment goes wrong you could loose your entire internet presence. As to why you'd want to authenticate DNS lookups, read this paper on how the great firewall leaks onto users outside of China: http://www....


5

The main security-related concerns raised so far are attackers may use false infringement claims as a denial-of-service attack. ISPs may start doing deep packet inspection on their customer's traffic, to look for infringing content. it may interfere with the effectiveness of, or take-up of, DNSSEC.


Only top voted, non community-wiki answers of a minimum length are eligible