Actually DNSSEC solves the problem of assuring the data associated with the domain name is that which was entered. DNSSEC can sign CERT records which match the CERTS used by your http server. It just requires the browsers to accept this trust path in addition to the traditional trust path using CA's.
DNSSEC actually does a much better job of this association than any CA can because the CA is outside of the normal trust path associated with DNS delgations.
It's pretty hard to implement right now.. a bunch of shell scripts and editing with vi, and even then I've never got it to work. One key thing is it's incompatible with dynamic DNS so you can only use it on static zones.
It most definitely not incompatible with dynamic zones. I've got plenty of signed dynamic zones and have for years.
The other thing is for it to work it has to be signed by a parent zone.. or in other words, more excuses for verisign to charge $$$ per year for doing almost nothing. This, of course, is why it's being pushed so much.. there's money in it.
Yet another conspiracy theorist. I know this is/., but really do some research and find out how much the existing TLD's are charging. $0.
Actually NAT64 won't help them. They need NAT46 to get to the IPv6 only sites and that is actually a much harder problem than NAT64 which allows IPv6 hosts to initiate a connection to a IPv4 host.
For NAT64 you just reserve a/96 and map the A records into the/96. As it is a known mapping the DNS and NAT64 box don't have to talk to each other.
For NAT46 you need to tightly integrate the DNS and NAT46 functionality by having the DNS establish/request mappings in the NAT46 in response to DNS queries.
Which is then NAT'd to a globally routable IPv4 address which are running out.
Most ISP's I speak to are actually worried about how they are going to be able to supply their customers with access to a globally routable IPv4 addresses in the near future for all the legacy IPv4 equipment and software out there which needs such addresses. Every customer who currently forwards a port/protocol needs access to such a address which may or may not be easily shared with another customer. Double NAT does not work for such customers.
What makes you think people are going to be able to run home servers? IPv6 wil make it easir for ISPOs to find and block home server.
What a load of howash. It's just as easy to discover servers with IPv4 as it is with IPv6. The ISP just need to look for the incoming TCP SYN packets to find a server.
ISP generally say no servers because it is simpler than describing the conditions where a server at the end of a asymmetric would be ok and where it would not be ok. Remember a lot of the infrastructure is shared and you should play fair.
If you run a server and do it in a manner that draws attention to you they have a excuse to shut you down. Run on in a manner that doesn't draw attention to you and they generally turn a blind eye.
I've been running a tunneled IPv6 connection to HE for over 5 years now. The local end is a cable connection that gets re-numbered, without notice, around twice a year. I just configure the dhcp client to re-configure the tunnel on based on what dhcp returns. This gives me stable IPv6 addresses.
# Configure local end of tunnel ifconfig gif0 create >/dev/null 2>&1 ifconfig gif0 tunnel $new_ip_address 64.71.128.82 ifconfig gif0 up ifconfig gif0 inet6 2001:470:1F00:FFFF::XXXX 2001:470:1F00:FFFF::XXXX prefixlen 128 route add -inet6 default 2001:470:1F00:FFFF::XXXX
# Configure remote end of tunnel over IPv4. # md5 hash of password pass=xxxxxxxxxxxxxxxxxxxxxxxx # user id from main page user_id=xxxxxxxxxxxxxxxxxxxxxxxxx # global tunnel id. tunnel_id=XXX args="ipv4b=$new_ip_address&pass=$pass&user_id=$user_id&tunnel_id=$tunnel_id" tunnel=`/usr/bin/fetch -q -o - "https://ipv4.tunnelbroker.net/ipv4_end.php?$args"` $LOGGER "IPv6 TUNNEL $tunnel"
Work has has native IPv6 for years now. Most of my home to work traffic flows over the tunnel. More and more of my general traffic flows over the tunnel.
When I started with HE they only gave out/64's. they now give out/48's which lets you support multiple networks at home without having to bridge the IPv6 networks together.
HE support has also been wonderful the few times things have broken, especially as this is a free service.
Over 10 years ago it was realised that eventually
random transaction ids would not be good enough. That someone would come up with a novel way to attack the DNS.
DNSSEC was the counter measure that was designed to beat this attack scenario as well as lots of other threats. It still is the only real solution to this problem.
It defeats both on path and off path attacks.
It is a enabler of other security measures.
e.g. SMTP security depends, in part, on getting valid answers out of the DNS. You need to know which certificate names to trust and without a secure DNS you don't have that.
What I really want to know is, how many of the people who had computers at that conference were users who had no clue what IPv6 even was, much less how to configure their computer to use it.
It's one thing to say IPv6 is ready because a conference filled with engineers could download their pron with IPv4 turned off. It's entirely another thing to say that IPv6 is ready because it works without my mother even knowing the difference.
I works for my father without him noticing that he was using IPv6 (6to4). I had to run netstat to see which protocol he was using.
Well, that and my ISP doesn't route IPv6 traffic, so if I wanted to use it I'd have to tunnel over IPv4, and that's just pointless complexity I don't really need in my network. If my ISP supported IPv6 I'd turn it on even though, as mentioned in the article, trying to use IPv6 on the current internet tends to break stuff and add delays to other things.
Actually once you have globally reachable IPv6 you don't get delays and you don't have the breakages. I really have not noticed
problems in may years of using IPv6 all day, everyday. I use a tunnel from home to Hurricane Electric, and from
there connect into work's machines.
For the record I was sitting on the IPv6 only network at IETF for most of the week.
named uses/dev/random for DSA signature generation. dnssec-keygen and dnssec-signzone also use/dev/random, when available.
The only secure method to prevent cache poisoning with any name server is to use DNSSEC [RFC 403[345]] as the DNS infrastructure could not cope with switching to TCP for all transactions.
Slashdot Mirror
Actually DNSSEC solves the problem of assuring the data associated with the domain name is that which was entered. DNSSEC can sign CERT records which match the CERTS used by your http server. It just requires the browsers to accept this trust path in addition to the traditional trust path using CA's.
DNSSEC actually does a much better job of this association than any CA can because the CA is outside of the normal trust path associated with DNS delgations.
It's pretty hard to implement right now.. a bunch of shell scripts and editing with vi, and even then I've never got it to work. One key thing is it's incompatible with dynamic DNS so you can only use it on static zones.
It most definitely not incompatible with dynamic zones. I've got plenty of signed dynamic zones and have for years.
The other thing is for it to work it has to be signed by a parent zone.. or in other words, more excuses for verisign to charge $$$ per year for doing almost nothing. This, of course, is why it's being pushed so much.. there's money in it.
Yet another conspiracy theorist. I know this is /., but really do some research and find out how much the existing TLD's are charging. $0.
The best you can do is make sure your ISP is deploying BCP 38 measure to prevent them being a source of these spoofed packets.
If you are a ISP you should be including BCP 38 deployment as a pre-condition for
peering.
If you are a transit provider you should be make BCP 38 deployment a pre-condition to accepting traffic.
It's not like this is new problem.
Even with EDNS 4k is the largest response current nameservers will emit.
None of this 50k garbage.
The response to this query will be = 512 bytes as they use plain DNS.
With EDNS it would be a little larger but not much.
Actually NAT64 won't help them. They need NAT46 to get to the IPv6 only sites and that is actually a much harder problem than NAT64 which allows IPv6 hosts to initiate a connection to a IPv4 host.
For NAT64 you just reserve a /96 and map the A records into the /96. As it is a known mapping the DNS and NAT64 box don't have to talk to each other.
For NAT46 you need to tightly integrate the DNS and NAT46 functionality by having the DNS establish/request mappings in the NAT46 in response to DNS queries.
Which is then NAT'd to a globally routable IPv4 address which are running out.
Most ISP's I speak to are actually worried about how they are going to be able to supply their customers with access to a globally routable IPv4 addresses in the near future for all the legacy IPv4 equipment and software out there which needs
such addresses. Every customer who currently forwards a port/protocol needs access to such a address which may or may not be easily shared with another customer. Double NAT does not work for such customers.
Actually www.google.com does have a IPv6 addresses. You just have to ask for them to be returned to you at the moment.
% host -t aaaa www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com has IPv6 address 2001:4860:0:1001::68
%
This is a logical next step in the transition from ipv6.google.com to providing IPv6 addresses for everyone on www.google.com.
What makes you think people are going to be able to run home servers? IPv6 wil make it easir for ISPOs to find and block home server.
What a load of howash. It's just as easy to discover servers with IPv4 as it is with IPv6. The ISP just need to look for the incoming TCP SYN packets to find a server.
ISP generally say no servers because it is simpler than describing the conditions where a server at the end of a asymmetric would be ok and where it would not be ok. Remember a lot of the infrastructure is shared and you should play fair.
If you run a server and do it in a manner that draws attention to you they have a excuse to shut you down. Run on in a manner that doesn't draw attention to you and they generally turn a blind eye.
I've been running a tunneled IPv6 connection to HE for over 5 years now. The local end is a cable connection that gets re-numbered, without notice, around twice a year. I just configure the dhcp client to re-configure the tunnel on based on what dhcp returns. This gives me stable IPv6 addresses.
# Configure local end of tunnel
ifconfig gif0 create >/dev/null 2>&1
ifconfig gif0 tunnel $new_ip_address 64.71.128.82
ifconfig gif0 up
ifconfig gif0 inet6 2001:470:1F00:FFFF::XXXX 2001:470:1F00:FFFF::XXXX prefixlen 128
route add -inet6 default 2001:470:1F00:FFFF::XXXX
# Configure remote end of tunnel over IPv4.
# md5 hash of password
pass=xxxxxxxxxxxxxxxxxxxxxxxx
# user id from main page
user_id=xxxxxxxxxxxxxxxxxxxxxxxxx
# global tunnel id.
tunnel_id=XXX
args="ipv4b=$new_ip_address&pass=$pass&user_id=$user_id&tunnel_id=$tunnel_id"
tunnel=`/usr/bin/fetch -q -o - "https://ipv4.tunnelbroker.net/ipv4_end.php?$args"`
$LOGGER "IPv6 TUNNEL $tunnel"
Work has has native IPv6 for years now. Most of my home to work traffic flows over the tunnel. More and more of my general traffic flows over the tunnel.
When I started with HE they only gave out /64's. they now give out /48's which lets you support multiple networks at home without having to bridge the IPv6 networks together.
HE support has also been wonderful the few times things have broken, especially as this is a free service.
Thanks HE.
DNSSEC was the counter measure that was designed to beat this attack scenario as well as lots of other threats. It still is the only real solution to this problem.
It defeats both on path and off path attacks.
It is a enabler of other security measures.
e.g. SMTP security depends, in part, on getting valid answers out of the DNS. You need to know which certificate names to trust and without a secure DNS you don't have that.
It's one thing to say IPv6 is ready because a conference filled with engineers could download their pron with IPv4 turned off. It's entirely another thing to say that IPv6 is ready because it works without my mother even knowing the difference.
I works for my father without him noticing that he was using IPv6 (6to4). I had to run netstat to see which protocol he was using.
Actually once you have globally reachable IPv6 you don't get delays and you don't have the breakages. I really have not noticed problems in may years of using IPv6 all day, everyday. I use a tunnel from home to Hurricane Electric, and from there connect into work's machines.
For the record I was sitting on the IPv6 only network at IETF for most of the week.
If you have 300 ms between the broker and you then you have choosen the wrong tunnel broker. There are tunnel brokers on just about every continent.
named does not use /dev/random for ID generation.
/dev/random for DSA signature generation. dnssec-keygen and dnssec-signzone also use /dev/random, when available.
named uses
The only secure method to prevent cache poisoning with any name server is to use DNSSEC [RFC 403[345]] as the DNS infrastructure could not cope with switching to TCP for all transactions.