Tag Info

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 ...

DNS Zone transfer is the process where a DNS server passes a copy of part of it's database (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 Slave DNS servers, and the slave asks he master for a copy of the records for that zone. A basic DNS Zone ...

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 ...

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 ...

DNSSEC provides something rather different than IPSec, and either or both may meet your needs. IPSec can encrypt packets and sign them, providing evidence that they come from something you trust, IF you have a PKI (Public Key Infrastructure) you can trust. But that "IF" is a very tall order, especially given the presence these days in most common "trusted" ...

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.

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 ...

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 ...

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 ...

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

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 ...

Kaminsky isn't the first person to find a DNS cache poising vulnerablity. In fact many of these vulnerability have been found and that is why DNSSEC is important. DNSSEC is a defense in-depth strategy against this attack pattern. However responsible software vendors patch vulnerabilities, and when you find a DNS cache poisoning attack in BIND, it will be ...

Click the link in the header: this draft dated Mar 2012 replaces the one you linked, and expires in Sep 2012. See also the websec working group.

You may have to clarify what it is you mean when you say that your current nameserver doesn't support DNSSEC when you're speaking from the resolver perspective. You see, any nameserver (that will do recursive queries for you) will cache and forward any record set your request. That includes RRSIG records which are the foundation of DNSSEC. Examples: ...

What business/organisation(s) would have: Sufficient technical skill to evaluate technologies needed for safe, secure web browsing OWASP The capacity to publicly recommend a set of technologies to achieve the same not actually, still CERT as several nations have it Does not have conflicting goals of Certificate Authorities nor other goals ...

In terms of your question, I don't think there is any one organisation. OWASP gives good detail on the ten obvious things you should get right, but that should be a bare minimum - because there are so many aspects of security, and different browsers, OS'es, plugins, ways to access the Internet etc I'd be surprised if any single organisation could do it. I ...

According to the information on this page: Effectively, the digest is calculated over the following fields, concatenated: DNSKEY owner name: se. (0x 02736500) Flags: 257 (0x0101) Protocol: 3 (0x03) Algorithm: 5 (0x05) Public Key: Aw…… The first four fields, in hex are as follows: 02736500 0101 03 05, My question was how one can ...

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 ...

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 ...

They should still be vulnerable, since the wildcard record is signed as literally "*". The details of how wildcard results are handled are covered in RFC 2535 (DNSSEC), RFC 3845 (NSEC RDATA format), and RFC 5155 (NSEC3 hashed responses). This simple description was helpful to me in understanding how a wildcard response can be proven: "The receiving ...

Just use Tor and tunnel through an Internet SSL/TLS proxy. Just make sure the tunnels and DNS resolvers are configured properly on both sides. There's a lot to know about this stuff, and it's best if you can troubleshoot, verify, and understand every little detail. Some tools such as Qualys SSL Labs and sslstrip/ssldump are very helpful. Another, ...

@GrahamHill already explained a zone transfer pretty good already, but I'll try to fill inn 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 is accessible from the Internet, but that a search engine like Google ...

Technically that could have been an ARP cache poisoning attack which is much more likely to occur. I'd suggest using SSL (Secure Socket Layers) and TLS (Transport Layer Security) as well as only connecting to the sites with "HTTPS://" addresses to encrypt your connection. Using a proxy or VPN protects your IP address from users on the other side of the ...

Effective defenses against the Kaminsky attack. At risk of over-simplifying, the Kaminsky attack can be used to attack DNS clients that do not use source port randomization. The immediate defense against the Kaminsky attack is to turn on source port randomization. These days, most modern DNS software does perform source port randomization. (If you haven't ...

Does it need to use DNSSEC in combination with SSL/TLS to be secure? In theory, no. The whole point of SSL/TLS (and cryptography in general) is to guaranty that you talk to the right guy (no matter what, even if DNS is corrupted). Also, SSL/TLS is mostly useful where your connexion can easily be intercepted; in this case, someone does not need to mess ...