hat tip to .gov hostmasters
http://it.slashdot.org/article.pl?sid=08/09/22/1253201&from=rss nice to see a wholesale DNSSEC rollout underway (I must confess to being a little surprised at the source, too!). Granted, it's a much more manageable problem set than, say, .com - but if one US-controlled TLD can do it, hope is buoyed for a .com rollout sooner rather than later (although probably not much sooner :)). /sf
On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis <darkuncle@gmail.com> wrote:
nice to see a wholesale DNSSEC rollout underway (I must confess to being a little surprised at the source, too!). Granted, it's a much more manageable problem set than, say, .com - but if one US-controlled TLD can do it, hope is buoyed for a .com rollout sooner rather than later (although probably not much sooner :)).
I'm not much up on DNSSEC, but don't you need to be using a resolver that recognizes DNSSEC in order for this to be useful?
/sf
-- Jason 'XenoPhage' Frisvold XenoPhage0@gmail.com http://blog.godshell.com
* Jason Frisvold:
On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis <darkuncle@gmail.com> wrote:
nice to see a wholesale DNSSEC rollout underway (I must confess to being a little surprised at the source, too!). Granted, it's a much more manageable problem set than, say, .com - but if one US-controlled TLD can do it, hope is buoyed for a .com rollout sooner rather than later (although probably not much sooner :)).
I'm not much up on DNSSEC, but don't you need to be using a resolver that recognizes DNSSEC in order for this to be useful?
Correct, you need a validating, security-aware stub resolver, or the ISP needs to validate the records for you. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Florian Weimer wrote:
* Jason Frisvold:
nice to see a wholesale DNSSEC rollout underway (I must confess to being a little surprised at the source, too!). Granted, it's a much more manageable problem set than, say, .com - but if one US-controlled TLD can do it, hope is buoyed for a .com rollout sooner rather than later (although probably not much sooner :)). I'm not much up on DNSSEC, but don't you need to be using a resolver
On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis <darkuncle@gmail.com> wrote: that recognizes DNSSEC in order for this to be useful?
Correct, you need a validating, security-aware stub resolver, or the ISP needs to validate the records for you.
In public space like .com, don't you need some kind of central trustworthy CA?
* Colin Alston:
Correct, you need a validating, security-aware stub resolver, or the ISP needs to validate the records for you.
In public space like .com, don't you need some kind of central trustworthy CA?
No, why would you? You need to trust the zone operator, and you need some trustworthy channel to exchange trust anchors at one point in time (a significant improvement compared to classic DNS, where you need a trustworthy channel all the time). -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
DNSSEC is not a PKI. There are no CAs and no X.509 certificates. It's a chain of trust that can be validated using public/private key pairs. OK, that's oversimplification but you get the idea. While we wait for applications to become DNSSEC-aware, if your local DNS server can be trusted (a big "if" of course) then it can proxy the DNSSEC awareness for you. Since nearly everybody trusts a local DNS server to resolve queries, then making that server DNSSEC aware is an enormous step forward, even if the actual applications and operating systems on end-user computers are not fully DNSSEC-aware and won't be for many years to come. Marc -----Original Message----- From: Florian Weimer [mailto:fweimer@bfk.de] Sent: Monday, September 22, 2008 11:10 AM To: Colin Alston Cc: nanog@nanog.org Subject: Re: hat tip to .gov hostmasters * Colin Alston:
Correct, you need a validating, security-aware stub resolver, or the ISP needs to validate the records for you.
In public space like .com, don't you need some kind of central trustworthy CA?
No, why would you? You need to trust the zone operator, and you need some trustworthy channel to exchange trust anchors at one point in time (a significant improvement compared to classic DNS, where you need a trustworthy channel all the time). -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
* marcus sachs:
While we wait for applications to become DNSSEC-aware,
Uhm, applications shouldn't be DNSSEC-aware. Down that road lies madness. What should an end user do when the browser tells him, "Warning: Could not validate DNSSEC signature on www.example.com, signature has expired. Continue to connect?" -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Mon, Sep 22, 2008 at 05:24:00PM +0200, Florian Weimer wrote:
* marcus sachs:
While we wait for applications to become DNSSEC-aware,
Uhm, applications shouldn't be DNSSEC-aware. Down that road lies madness. What should an end user do when the browser tells him, "Warning: Could not validate DNSSEC signature on www.example.com, signature has expired. Continue to connect?"
-- Florian Weimer <fweimer@bfk.de>
actually, I am really hoping that at least one API is standardized so that applications can use DNSSEC data. We never finished the discussion on fail/open fail/closed wrt DNSSEC. --bill
At 15:30 +0000 9/22/08, bmanning@vacation.karoshi.com wrote:
data. We never finished the discussion on fail/open fail/closed wrt DNSSEC.
And I'd bet a dollar we never will finish that discussion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more.
On Mon, Sep 22, 2008 at 12:06:57PM -0400, Edward Lewis wrote:
At 15:30 +0000 9/22/08, bmanning@vacation.karoshi.com wrote:
data. We never finished the discussion on fail/open fail/closed wrt DNSSEC.
And I'd bet a dollar we never will finish that discussion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar
Never confuse activity with progress. Activity pays more.
taken. (never is a -very- long time) --bill
In article <82ljxkjjan.fsf@mid.bfk.de> you write:
* marcus sachs:
While we wait for applications to become DNSSEC-aware,
Uhm, applications shouldn't be DNSSEC-aware. Down that road lies madness. What should an end user do when the browser tells him, "Warning: Could not validate DNSSEC signature on www.example.com, signature has expired. Continue to connect?"
The application just rejects the answer. Trys again a couple of times then reports failure. This is no different to the application talking to the validating resolver a couple of time and then reporting failure. The advantage of having the application do it is that you don't need to secure the connection between the validating resolver and the application. Mark
Correct, you need a validating, security-aware stub resolver, or the ISP needs to validate the records for you.
That would defeat the entire purpose of using DNSSEC. In order for DNSSEC to actually provide any improvement in security whatsoever, the ROOT ZONE (.) needs to be signed, and every delegation up the chain needs to be signed. And EVERY resolver (whether recursive or local on host) needs to understand and enforce DNSSEC. If even one delegation is unsigned or even one resolver does not enforce DNSSEC, then, from an actual security perspective, you will be far worse off than you are now. Until such time as EVERY SINGLE DOMAIN including the root is signed and every single DNS Server and resolver (including the local host resolvers) understand and enforce DNSSEC you should realize that DNSSEC does nothing for you whatsoever except give the uneducated a false sense of "security". It is likely that IPv48 will be deployed long before DNSSEC is implemented.
* Keith Medcalf:
Correct, you need a validating, security-aware stub resolver, or the ISP needs to validate the records for you.
That would defeat the entire purpose of using DNSSEC. In order for DNSSEC to actually provide any improvement in security whatsoever, the ROOT ZONE (.) needs to be signed, and every delegation up the chain needs to be signed. And EVERY resolver (whether recursive or local on host) needs to understand and enforce DNSSEC.
Either the resolver needs to enforce, or the host. It's not necessary to do both. It's also not strictly necessary that the root is signed, provided that there is some way to manage the trust anchors (either through software updates, like it is done for the browser CA list, or through regular DNS management at the ISP resolver).
If even one delegation is unsigned or even one resolver does not enforce DNSSEC, then, from an actual security perspective, you will be far worse off than you are now.
Why?
Until such time as EVERY SINGLE DOMAIN including the root is signed and every single DNS Server and resolver (including the local host resolvers) understand and enforce DNSSEC you should realize that DNSSEC does nothing for you whatsoever except give the uneducated a false sense of "security".
DNSSEC is totally invisible to the end user. There won't be any browser icon that says "it's okay to enter your PII here because the zone is DNSSEC-signed". It's purely an infrastructure measure, like physically securing your routers. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
That would defeat the entire purpose of using DNSSEC. In order for DNSSEC to actually provide any improvement in security whatsoever, the ROOT ZONE (.) needs to be signed, and every delegation up the chain needs to be signed. And EVERY resolver (whether recursive or local on host) needs to understand and enforce DNSSEC.
Either the resolver needs to enforce, or the host. It's not necessary to do both. It's also not strictly necessary that the root is signed, provided that there is some way to manage the trust anchors (either through software updates, like it is done for the browser CA list, or through regular DNS management at the ISP resolver).
If even one delegation is unsigned or even one resolver does not enforce DNSSEC, then, from an actual security perspective, you will be far worse off than you are now.
Why?
If the local resolver does not perform DNSSEC validation, then I cannot validate that the response is correct. I certainly do not trust anyone else to verify that the information is correct and then, without any possible verification, simply believe that the third party did the validation. In fact, I have no way of knowing that the response even came from the "ISP" at all unless the client resolver supports DNSSEC. Just because YOU check the digital signature on an email and forward that email to me (either with or without the signature data), if I do not have the capability to verify the signature myself, I sure as hell am not going to trust your mere say-so that the signature is valid! If I cannot authenticate the data myself, then it is simply untrusted and untrustworthy -- exactly the same as it is now. The real problem is that the clueless (with a hidden self-aggrandizing and a primary motive of "lining my pockets with other peoples money" will convince the ignorant that it is more secure. Sort of like banning toothpaste from carry-on baggage "impoves" the security of air travel, when in fact it does nothing more than help the idiots in charge of promulgating such polies to rip off (rob) other people of their money by deliberate fraud and misrepresentation.
Until such time as EVERY SINGLE DOMAIN including the root is signed and every single DNS Server and resolver (including the local host resolvers) understand and enforce DNSSEC you should realize that DNSSEC does nothing for you whatsoever except give the uneducated a false sense of "security".
DNSSEC is totally invisible to the end user. There won't be any browser icon that says "it's okay to enter your PII here because the zone is DNSSEC-signed". It's purely an infrastructure measure, like physically securing your routers.
The end-stage is secure only if at that stage you also set all DNS infrastructure to refuse to talk to any DNS client/server/resolver that DOES NOT validate and enforce DNSSEC. Up until that point in time, there is NO CHANGE in the security posture from what we have today with no DNSSEC whatsoever. To hold forth otherwise is to participate in deliberate fraud and misrepresentation of material facts.
On Mon, Sep 22, 2008 at 8:49 AM, Keith Medcalf <kmedcalf@dessus.com> wrote:
If even one delegation is unsigned or even one resolver does not enforce DNSSEC, then, from an actual security perspective, you will be far worse off than you are now.
Why?
If the local resolver does not perform DNSSEC validation, then I cannot validate that the response is correct. I certainly do not trust anyone else to verify that the information is correct and then, without any possible verification, simply believe that the third party did the validation. In fact, I have no way of knowing that the response even came from the "ISP" at all unless the client resolver supports DNSSEC.
Just because YOU check the digital signature on an email and forward that email to me (either with or without the signature data), if I do not have the capability to verify the signature myself, I sure as hell am not going to trust your mere say-so that the signature is valid!
If I cannot authenticate the data myself, then it is simply untrusted and untrustworthy -- exactly the same as it is now.
so I guess PGP web of trust is right out, then? (in the real world, we rarely get boolean values on security questions) -- darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key
Just because YOU check the digital signature on an email and forward that email to me (either with or without the signature data), if I do not have the capability to verify the signature myself, I sure as hell am not going to trust your mere say-so that the signature is valid!
If I cannot authenticate the data myself, then it is simply untrusted and untrustworthy -- exactly the same as it is now.
so I guess PGP web of trust is right out, then?
You are confusing "validating signature" with "validating the holder of the keying material and the authorization of the holder to deploy it to create a non-repudiable signature", which are two entirely different and completely unreleated things. (This is quite common by the way, so maybe you can be excused your confusion). If there is a piece of data X signed with a cryptographically generated signature, and *I* verify that indeed the signature is valid, then the signature is valid -- that is, I can say with 100% absolute certainty that specific bit of keying material was used to generate a signature on something and that I have another bit of keying material which validates that signature. I am assured with very high certainty that THE DATA WAS SIGNED BY THE POSSESSOR OF THE SECRET KEYING MATERIAL. Nothing more can be determined from the signature. You now want to confuse the issue by associating the "keying material" with a "person" or "entity". That problem is entirely outside the purview of the exercize and completely irrelevant. (I certainly do not "trust" that any certificate issued by a so-called Certificate Authority (other than myself) was issued to the entity it is purported to be issued to, nor that the key is properly kept secret, nor anything else. The mathematical validity of the signature is beyond question. Associating that signature to anything other than a mere statement that "this data was signed by the possessor of the secret key corresponding to the public key that I have" is a personal judgement call.
On Mon, Sep 22, 2008 at 12:14:53PM -0400, Keith Medcalf wrote:
If I cannot authenticate the data myself, then it is simply untrusted and untrustworthy -- exactly the same as it is now.
so I guess PGP web of trust is right out, then?
[elided]
If there is a piece of data X signed with a cryptographically generated signature, and *I* verify that indeed the signature is valid, then the signature is valid -- that is, I can say with 100% absolute certainty that specific bit of keying material was used to generate a signature on something and that I have another bit of keying material which validates that signature. I am assured with very high certainty that THE DATA WAS SIGNED BY THE POSSESSOR OF THE SECRET KEYING MATERIAL.
Nothing more can be determined from the signature.
let me understand this ... your use of the pronoun "I" in these contexts is in reference to your corporal being i.e. meatspace and not a software application running on some computer. --bill
The end-stage is secure only if at that stage you also set all DNS infrastructure to refuse to talk to any DNS client/server/resolver that DOES NOT validate and enforce DNSSEC. Up until that point in time, there is NO CHANGE in the security posture from what we have today with no DNSSEC whatsoever.
To hold forth otherwise is to participate in deliberate fraud and misrepresentation of material facts.
so you are a "fail/closed" proponent. a fail/open approach would have failure of DNSSEC-based validation behave just like the DNS of today. The use of Trust Anchors and signed "islands" allow one to find "golden threads" of validated chains in the dns fabric ... e.g. incremental rollout vs flag day. --bill
On Mon, Sep 22, 2008 at 11:11:40AM -0400, Keith Medcalf wrote:
Correct, you need a validating, security-aware stub resolver, or the ISP needs to validate the records for you.
That would defeat the entire purpose of using DNSSEC. In order for DNSSEC to actually provide any improvement in security whatsoever, the ROOT ZONE (.) needs to be signed, and every delegation up the chain needs to be signed. And EVERY resolver (whether recursive or local on host) needs to understand and enforce DNSSEC.
er, no. the root zone does not need to be signed and not every delegation. and only the resolvers in the path from auth servers to validators need to ensure that the DNSSEC data is retained. if the only TA I have is for .SE (configured in my validator) and my resolver passes the DNSSEC data unchanged it received from the .SE servers, then I can securely trust the (short) validation chain when I look up axfr.se. even though -nothing else- is signed.
If even one delegation is unsigned or even one resolver does not enforce DNSSEC, then, from an actual security perspective, you will be far worse off than you are now.
depends on your POV of course...
Until such time as EVERY SINGLE DOMAIN including the root is signed and every single DNS Server and resolver (including the local host resolvers) understand and enforce DNSSEC you should realize that DNSSEC does nothing for you whatsoever except give the uneducated a false sense of "security".
I think you have unrealistic expectations. Time will tell.
It is likely that IPv48 will be deployed long before DNSSEC is implemented.
--bill
On Sep 22, 2008, at 8:11 AM, Keith Medcalf wrote:
Correct, you need a validating, security-aware stub resolver, or the ISP needs to validate the records for you.
That would defeat the entire purpose of using DNSSEC. In order for DNSSEC to actually provide any improvement in security whatsoever, the ROOT ZONE (.) needs to be signed, and every delegation up the chain needs to be signed.
The root does not need to be signed to provide security improvement. If you have configured the (say) .SE trust anchor in your validating resolver, you greatly reduce the chances that any lookup for a name in .SE can be spoofed. The downside of not having the root signed is that you need to maintain multiple trust anchors.
And EVERY resolver (whether recursive or local on host) needs to understand and enforce DNSSEC.
I personally believe it is more-or-less safe to trust communications local to the machine. As such, running a validating resolver on your local host would suffice. Having a stub resolver also validate in this scenario would be overkill.
If even one delegation is unsigned or even one resolver does not enforce DNSSEC, then, from an actual security perspective, you will be far worse off than you are now.
In what way? I'm running a validating resolver on my laptop (using the signed root zone and trust anchor available from ns.iana.org so I only have to deal with one trust anchor). If someone tries to spoof a name in the root, .SE, .BG, .PR, .BR, .CZ, their efforts will fail. How is this worse off than before I configured my resolver?
Until such time as EVERY SINGLE DOMAIN including the root is signed and every single DNS Server and resolver (including the local host resolvers) understand and enforce DNSSEC you should realize that DNSSEC does nothing for you whatsoever except give the uneducated a false sense of "security".
If this were true, DNSSEC would be a complete waste of time. Fortunately, it isn't true. Regards, -drc
On Sep 22, 2008, at 7:56 AM, Florian Weimer wrote:
I'm not much up on DNSSEC, but don't you need to be using a resolver that recognizes DNSSEC in order for this to be useful?
Yes, and you also need the trust anchors for the zones you want to validate configured.
Correct, you need a validating, security-aware stub resolver, or the ISP needs to validate the records for you.
Slight clarification: you need a validating, security-aware resolver, whether that resolver is local (e.g., running on the same machine issuing the DNS queries) or remote (e.g., your ISP's resolver). Note that, for good or ill, you are trusting the operator of the resolver and the communication channel between the resolver and the application making the DNS requests. A validating, security-aware _stub_ resolver, typically linked into the program issuing the DNS requests and thus would be the ultimate in 'local', would have the ability to validate the response and supply feedback to the application with minimum vulnerability to MITM attacks. The downside is the added complexity of the code to the validation and to handle validation failures. Regards, -drc
On Mon, 22 Sep 2008 10:52:42 -0400 "Jason Frisvold" <xenophage0@gmail.com> wrote:
I'm not much up on DNSSEC, but don't you need to be using a resolver that recognizes DNSSEC in order for this to be useful?
You do -- and last time I checked few native resolvers actually did : glibc doesn't, and I'd be surprised if the Windows resolver does Simon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 22, 2008, at 9:59 AM, Simon Vallet wrote:
On Mon, 22 Sep 2008 10:52:42 -0400 "Jason Frisvold" <xenophage0@gmail.com> wrote:
I'm not much up on DNSSEC, but don't you need to be using a resolver that recognizes DNSSEC in order for this to be useful?
You do -- and last time I checked few native resolvers actually did : glibc doesn't, and I'd be surprised if the Windows resolver does
Chicken, meet egg. I think the point of the original post is that one end or the other has to start things. At least we have one US zone doing something on the server end of things. Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Owen ~ Garden City (620) 275-1900 ~ Lottery (noun): President ~ Wichita (316) 858-3000 ~ A stupidity tax Hubris Communications Inc www.hubris.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iEYEARECAAYFAkjXs30ACgkQElUlCLUT2d0SfwCbB8FQ4izN061GoQQMl3fkq+NT ga0AoJnwGG8PfBs5PaziRB6m0NQBuZwc =68dm -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 22 Sep 2008 10:02:21 -0500 Chris Owen <owenc@hubris.net> wrote:
Chicken, meet egg.
I think the point of the original post is that one end or the other has to start things. At least we have one US zone doing something on the server end of things.
I totally agree on that, but wanted to point out that there still is some work be done. The folks at NLnet do have a nice DNSSEC implementation, though, as well as the BIND library. Simon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjXtWUACgkQccZs6oMJsYR5XQCbB6e92xTcaR2ijn0DcAALdswA 358AmQH36qg/fBRGxJIFS4Alm4sAKF9w =7JfR -----END PGP SIGNATURE-----
On Mon, Sep 22, 2008 at 11:02 AM, Chris Owen <owenc@hubris.net> wrote:
Chicken, meet egg.
I think the point of the original post is that one end or the other has to start things. At least we have one US zone doing something on the server end of things.
Oh, agreed, absolutely. And it's great to see. However, neither the slashdot blurb, nor the NetworkWorld article mention that without a valid resolver, there is no guarantee of security. Sure, they mention that vendors are rolling it out and that ISPs should be following suit, but no mention is made of the end-user's resolver at all...
Chris
-- Jason 'XenoPhage' Frisvold XenoPhage0@gmail.com http://blog.godshell.com
Jason Frisvold wrote:
On Mon, Sep 22, 2008 at 11:02 AM, Chris Owen <owenc@hubris.net> wrote:
Chicken, meet egg.
I think the point of the original post is that one end or the other has to start things. At least we have one US zone doing something on the server end of things.
Oh, agreed, absolutely. And it's great to see. However, neither the slashdot blurb, nor the NetworkWorld article mention that without a valid resolver, there is no guarantee of security. Sure, they mention that vendors are rolling it out and that ISPs should be following suit, but no mention is made of the end-user's resolver at all...
I dunno, a few very strategically placed validating resolvers could subject a huge amount of DNS traffic to a much higher bar were the senders so inclined to sign their zones. But I tend to view these kinds of things much more from an "epidemiology" point of view: you don't have to have 100% eradication to control an epidemic. Same thing pretty much goes with internet based attacks, IMO: when the barrier is set sufficiently high in one area, attackers don't spend their entire time trying to break that barrier, they find the next lowest barrier and move on. Mike
On Mon, Sep 22, 2008 at 8:16 AM, Jason Frisvold <xenophage0@gmail.com> wrote:
On Mon, Sep 22, 2008 at 11:02 AM, Chris Owen <owenc@hubris.net> wrote:
Chicken, meet egg.
I think the point of the original post is that one end or the other has to start things. At least we have one US zone doing something on the server end of things.
Oh, agreed, absolutely. And it's great to see. However, neither the slashdot blurb, nor the NetworkWorld article mention that without a valid resolver, there is no guarantee of security. Sure, they mention that vendors are rolling it out and that ISPs should be following suit, but no mention is made of the end-user's resolver at all...
the NetworkWorld article (in the printer-friendly version, at least) has a little table that shows the DNSSEC status of the major vendors. And support in the resolver library is not strictly necessary, as long as you trust _your_ (or your ISP's) nameservers. (not to say that it isn't a good idea, just that it's not requirement for initial rollout.) -- darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key
Pretty soon we'll have a blacklist of DNS servers that don't support DNSSEC for .gov. =) Frank -----Original Message----- From: Chris Owen [mailto:owenc@hubris.net] Sent: Monday, September 22, 2008 10:02 AM To: NANOG list Subject: Re: hat tip to .gov hostmasters -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 22, 2008, at 9:59 AM, Simon Vallet wrote:
On Mon, 22 Sep 2008 10:52:42 -0400 "Jason Frisvold" <xenophage0@gmail.com> wrote:
I'm not much up on DNSSEC, but don't you need to be using a resolver that recognizes DNSSEC in order for this to be useful?
You do -- and last time I checked few native resolvers actually did : glibc doesn't, and I'd be surprised if the Windows resolver does
Chicken, meet egg. I think the point of the original post is that one end or the other has to start things. At least we have one US zone doing something on the server end of things. Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Owen ~ Garden City (620) 275-1900 ~ Lottery (noun): President ~ Wichita (316) 858-3000 ~ A stupidity tax Hubris Communications Inc www.hubris.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iEYEARECAAYFAkjXs30ACgkQElUlCLUT2d0SfwCbB8FQ4izN061GoQQMl3fkq+NT ga0AoJnwGG8PfBs5PaziRB6m0NQBuZwc =68dm -----END PGP SIGNATURE-----
* Simon Vallet:
I'm not much up on DNSSEC, but don't you need to be using a resolver that recognizes DNSSEC in order for this to be useful?
You do -- and last time I checked few native resolvers actually did : glibc doesn't, and I'd be surprised if the Windows resolver does
Windows doesn't. To my knowledge, there aren't any deployed valdiating, security-aware stub resolvers. Your best bet is to run BIND or Unbound locally with appropriate trust anchors, and use that as the system's resolver. With modern LRU-based caches which are efficient even at smallish sizes, this isn't much of a problem. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Mon, Sep 22, 2008 at 10:52:42AM -0400, Jason Frisvold wrote:
On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis <darkuncle@gmail.com> wrote:
nice to see a wholesale DNSSEC rollout underway (I must confess to being a little surprised at the source, too!). Granted, it's a much more manageable problem set than, say, .com - but if one US-controlled TLD can do it, hope is buoyed for a .com rollout sooner rather than later (although probably not much sooner :)).
I'm not much up on DNSSEC, but don't you need to be using a resolver that recognizes DNSSEC in order for this to be useful?
/sf
-- Jason 'XenoPhage' Frisvold XenoPhage0@gmail.com http://blog.godshell.com
yes and no. to fully trust the data from the servers you need three things: ) signed data (this is what .gov is doing) ) a validator in the end system (this is mostly missing/not configured today) ) accurate trust anchors from a couple of places in the DNS namespace ## however, if all you start with is signed data - it becomes possible to verify the source of the data - independently of inline DNS validation. e.g. you can - with a high degree of certainty, be assured that the root zone you load is really the ORSN root and not that flaky root from DoC/ICANN/VSGN... :) so "naked" signed data, in the absence of TA's or validators is still useful. ## you'll need a couple of these - and how you get them and keep them up to date is still a mostly unsolved operational problem. --bill
nice to see a wholesale DNSSEC rollout underway (I must confess to being a little surprised at the source, too!). Granted, it's a much more manageable problem set than, say, .com - but if one US-controlled TLD can do it, hope is buoyed for a .com rollout sooner rather than later (although probably not much sooner :)).
It ain't done yet. I don't speak for the hostmasters of .gov or any subdomain thereof. But I'll believe it when I see it. Remember, they've also "mandated" IPv6 support on all backbones. -- Jim Goltz <jgoltz@mail.nih.gov> CIT/DCSS/HSB/ASIG 12/2216
Date: Mon, 22 Sep 2008 11:42:33 -0400 From: "Goltz, Jim (NIH/CIT) [E]" <jgoltz@mail.nih.gov>
nice to see a wholesale DNSSEC rollout underway (I must confess to being a little surprised at the source, too!). Granted, it's a much more manageable problem set than, say, .com - but if one US-controlled TLD can do it, hope is buoyed for a .com rollout sooner rather than later (although probably not much sooner :)).
It ain't done yet.
I don't speak for the hostmasters of .gov or any subdomain thereof. But I'll believe it when I see it.
I am pretty sure that you will see it. Unlike things like the IPv6 requirement, there are no waivers available for this. '.gov' must be signed early next year and all zones delegated from the '.gov' GTLD must be signed in early 2010. I doubt that many will sign until '.gov' is signed, so you won't see much change for a few months. Now, if the DOC people responsible for root would just catch a clue, we could get that signed and have DNSSEC actually usable (except for Mr. Metcalf) in a significant part of the US network before I retire.
Remember, they've also "mandated" IPv6 support on all backbones.
Yes, and the goal, relatively insignificant that it was, was met. It was not a requirement that anyone actually use IPv6, only that the agency backbone networks be able to carry IPv6. In fact, the wording was such that doing proper routing was not even really needed. Our backbone has offered IPv6 as a production service since 2002, so it was a non-effort for us. Most other agency backbones were pretty trivial to make "IPv6 capable". The problem is that only the backbone currently needs IPv6. No facility network or end host needs it, No network service needs it. No IPv6 packets, even routing updates, need to be delivered in any useful way. It was a pretty trivial goal and was met with very little effort. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Kevin Oberman wrote:
Date: Mon, 22 Sep 2008 11:42:33 -0400 From: "Goltz, Jim (NIH/CIT) [E]" <jgoltz@mail.nih.gov>
Remember, they've also "mandated" IPv6 support on all backbones.
Yes, and the goal, relatively insignificant that it was, was met. It was not a requirement that anyone actually use IPv6, only that the agency backbone networks be able to carry IPv6. In fact, the wording was such that doing proper routing was not even really needed.
Our backbone has offered IPv6 as a production service since 2002, so it was a non-effort for us. Most other agency backbones were pretty trivial to make "IPv6 capable".
The problem is that only the backbone currently needs IPv6. No facility network or end host needs it, No network service needs it. No IPv6 packets, even routing updates, need to be delivered in any useful way. It was a pretty trivial goal and was met with very little effort.
They mandated that all products, not just hardware, support IPv6. However, all that the requirement turned out to be, in practice, is that all products be "software upgradeable" to IPv6. My employer is still selling stuff by the truckload to the USG because the hardware itself is "IPv6 capable" (just like it's OSI or DECnet "capable"), but we haven't written a single line of IPv6 code yet because customers aren't actually demanding it and we have other, more profitable, things to spend developers' limited time on. For vendors whose hardware needs to change for IPv4, like core routers, this is a big deal; for the rest of us, it was a non-event once we read the fine print. S
To digress on IPv6 momentarily. The airline magazine engineering memorandum* from OMB left two terms undefined in the mandate; "backbone network" and "IPv6 compatible." The Intra-agency IPv6 Federal Working Group wisely defined "backbone network" as (paraphrasing) the wire exiting the first publicly-reachable network perimeter router and entering the router next in the line of traffic and all devices attached to that wire between those two points as follows: {Internet}->|router|<-connecting wire---IPV6-[firewall, IDS, etc.]-IPV6--connecting wire->|next router in line|->NO IPV6-----... NIST is still working on "compatible." *Airline Magazine Engineering Memorandum: a mandate issued by an executive who can. The memorandum has four characteristics; 1) It mandates a technology not well understood by either the issuer or the recipient of the memo, 2) it sets a date certain by which the technology must be implemented, 3) it provides no funding, and 4, it contains one or more undefined terms whose exact meanings are absolutely crucial to actual implementation of the mandate. Source of the inspiration that originally convinced the issuing executive that they actually understood the scope and technology of the mandate is inherent in the title of this paragraph. JimL James R Lindley Senior Computer Engineer Advanced Technical Analysis Team IT Security Architecture and Engineering Internal Revenue Service An unquenchable thirst for Pierian waters. -----Original Message----- From: Kevin Oberman [mailto:oberman@es.net] Sent: Monday, September 22, 2008 12:54 To: Goltz, Jim (NIH/CIT) [E] Cc: nanog@nanog.org Subject: Re: hat tip to .gov hostmasters
Date: Mon, 22 Sep 2008 11:42:33 -0400 From: "Goltz, Jim (NIH/CIT) [E]" <jgoltz@mail.nih.gov>
nice to see a wholesale DNSSEC rollout underway (I must confess to being a little surprised at the source, too!). Granted, it's a much more manageable problem set than, say, .com - but if one US-controlled TLD can do it, hope is buoyed for a .com rollout sooner rather than later (although probably not much sooner :)).
It ain't done yet.
I don't speak for the hostmasters of .gov or any subdomain thereof. But I'll believe it when I see it.
I am pretty sure that you will see it. Unlike things like the IPv6 requirement, there are no waivers available for this. '.gov' must be signed early next year and all zones delegated from the '.gov' GTLD must be signed in early 2010. I doubt that many will sign until '.gov' is signed, so you won't see much change for a few months. Now, if the DOC people responsible for root would just catch a clue, we could get that signed and have DNSSEC actually usable (except for Mr. Metcalf) in a significant part of the US network before I retire.
Remember, they've also "mandated" IPv6 support on all backbones.
Yes, and the goal, relatively insignificant that it was, was met. It was not a requirement that anyone actually use IPv6, only that the agency backbone networks be able to carry IPv6. In fact, the wording was such that doing proper routing was not even really needed. Our backbone has offered IPv6 as a production service since 2002, so it was a non-effort for us. Most other agency backbones were pretty trivial to make "IPv6 capable". The problem is that only the backbone currently needs IPv6. No facility network or end host needs it, No network service needs it. No IPv6 packets, even routing updates, need to be delivered in any useful way. It was a pretty trivial goal and was met with very little effort. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
participants (18)
-
bmanning＠vacation.karoshi.com -
Chris Owen -
Colin Alston -
David Conrad -
Edward Lewis -
Florian Weimer -
Frank Bulk -
Goltz, Jim (NIH/CIT) [E] -
Jason Frisvold -
Keith Medcalf -
Kevin Oberman -
Lindley James R -
marcus.sachs＠verizon.com -
Mark Andrews -
Michael Thomas -
Scott Francis -
Simon Vallet -
Stephen Sprunk