I am certainly not a DNSSEC expert so take my explanation with a grain of
salt.
Short answer www.paypal.com is a cname for an akamai box. That cname record is
secure:
$ unbound-host -v -t cname www.paypal.com www.paypal.com has CNAME record
www.paypal.com.akadns.net. (secure)
Everything falls apart when your resolver finishes the rest of the required
lookups to get an IP address from akadns/akamaiedge.
As I have been experimenting/researching dnssec I have often found it
is useful to use verisign's tool AND sandia's dnsviz[1] tool. For the
moment forget what I said about paypal's cname and compare sandia's[2] and
verisign's[3] results for www.paypal.com and see if you can spot the issue.
You are correct that it is a relief that verisign uses DNSSEC but if I may be
so bold I think you may be wrong about why it is a relief. (I am trying to be
helpful, i apologize if that sounds dickish it is not my intent) With DNSSEC
(just like DNS) everything flows from the root. Verisign manages the .com
tld so if they did not sign the .com you could not verify anyhost.com. The
same thing can be said for DISA, GSA and PIR for .mil, .gov and .org zones
respectively.
As far as NIST goes they are the second least surprising DNSSEC adopter as
far as the federal government goes. Because of NIST's standards function
within the government they are normally at the forefront for things like
this. Moreover DNSSEC is heavily reliant on accurate time and NIST is the home
of the government's truechimer. However if you go down this rabbit hole you
start to have some serious chicken and egg problems.
Short answer www.paypal.com is a cname for an akamai box. That cname record is secure:
Everything falls apart when your resolver finishes the rest of the required lookups to get an IP address from akadns/akamaiedge.As I have been experimenting/researching dnssec I have often found it is useful to use verisign's tool AND sandia's dnsviz[1] tool. For the moment forget what I said about paypal's cname and compare sandia's[2] and verisign's[3] results for www.paypal.com and see if you can spot the issue.
You are correct that it is a relief that verisign uses DNSSEC but if I may be so bold I think you may be wrong about why it is a relief. (I am trying to be helpful, i apologize if that sounds dickish it is not my intent) With DNSSEC (just like DNS) everything flows from the root. Verisign manages the .com tld so if they did not sign the .com you could not verify anyhost.com. The same thing can be said for DISA, GSA and PIR for .mil, .gov and .org zones respectively.
As far as NIST goes they are the second least surprising DNSSEC adopter as far as the federal government goes. Because of NIST's standards function within the government they are normally at the forefront for things like this. Moreover DNSSEC is heavily reliant on accurate time and NIST is the home of the government's truechimer. However if you go down this rabbit hole you start to have some serious chicken and egg problems.
[1] http://dnsviz.net/ (NB: sandia's is so slow that its painful)
[2] http://dnsviz.net/d/www.paypal.com/dnssec/
[3] http://dnssec-debugger.verisignlabs.com/www.paypal.com