LinuxThreads aren't different, but under 2.4, capabilities can be retained across setuid(). So, named can call setuid() early (that is, before threads start), while retaining the ability to later bind port 53.
The port is bound after starting threads because it can't be bound until after the config file is read, since the config file specifies the ports to listen on. The config file is read after threads are started for several reasons, not the least of which is that it's also read with threads active in the reload case.
With bind 9 on linux, a chroot jail cannot be broken out of using those steps, since the CAP_SYS_CHROOT capability is dropped.
If you want setuid on a 2.4 kernel, compile with --disable-threads.
Yeah. In less than 2 years since I wrote that paper, NAI has changed the URL about 6 times, without ever leaving a redirect in place.
You're right, currently, a bind 9 server cannot handle DDNS from an MS client. We hope to have that working at some point in the future. Another possibility (which doesn't always work, of course), is to let the DHCP server send updates for clients, which means that only the DHCP server needs to authenticate to the server. I know this doesn't work in all cases, but I'd also never advocate using an MS client:)
Win2K doesn't support DNSSEC at all, at least not in the traditional sense. It supports transaction security (mostly used to authenticate dynamic updates), using a method incompatible with IETF standards (including their own spec, interestingly). If MS actually documents what they're doing, bind will support it (at some point).
DNSSEC authentication is fully dependent on clients. Servers can give out digital signatures, but clients must be configured to authenticate them for them to be useful. So, if MS doesn't implement DNSSEC, that means that MS clients wouldn't notice spoofing, but others might.
> *One* Server holds the master file? > No load balancing/[obligatory beowulf]/Round Robin? > I would like to think there is some redundancy in there... Yes, one server holds the master file, and distributes it to the other 12 top-level servers. Queries are load balanced between all of the top-level servers.
> If my key is compromised and I have to generate a new on who signs my key, internic, verisign?
Your parent zone. The root key signs the.com key, which signs the foo.com key, and so on.
> Meaningful encryption would push the 512 byte limit of dns udp packet to a much smaller payload, making the use of tcp for common dns activities necessary thereby tremendously reducing dns performance.
DNSSEC doesn't include encryption, only authentication. Yes, the 512 byte UDP limit is an issue, but there is a proposed solution (EDNS).
> Meaningful encryption would cause CPU load - period. Imagine the com root servers having to encrypt every answer. This would probably end up requiring an Origin 2000 and remember that 8.2.2 isn't able to take advantage of SMP.
Again, there is no encryption. Digital signatures are precomputed, so there's no additional CPU power required on root servers at runtime. Caching servers, which will verify DNSSEC signatures on incoming data, will require more CPU power.
There's no reason to encrypt DNS data - it's all public anyway. Authentication is far more important, so that connections can be made to a verifiably correct site.
Are you sure you listened to Paul Vixie's presentation?:)
Yes, RSA does encryption. It also can be used for authentication, but not exactly in the way you describe.
An entity holds a public/private key pair. When sending a message, it generates a hash or digest(MD5, SHA1, etc), and applies the algorithm to the hash using its private key. This creates a digital signature which is sent along with the message. The public key is widely disseminated. Therefore, when the message and signature are received, the receiver can compute the message digest and use the RSA public key to prove that the signature is valid.
This is not useful for encryption, since the message is sent in the clear, and cannot be obtained from the digital signature alone. This is how DNS Security works - KEY records store public keys in DNS, and SIG records contain digital signatures.
Authentication is authentication (well, there are two methods - the standard and Microsoft's:) ). The same authentication mechanisms can be applied to a zone transfer or an update (or even a normal query), since the authentication applies to the full DNS message and is based on the identity that sent the request.
RSA is not used for encryption; DNS doesn't do encryption. RSA is not used for securing zone transfers, it's used for generic data authentication, as specified in the DNS Security RFCs. The other alternative is DSA, which is the required algorithm, but RSA verifications are approximately 60x faster, which makes a pretty big difference. A different implementation of RSA cannot be used, because of patent issues. Export control is not an issue, since RSA is only used for authentication.
It looks like the only option is to optionally remove RSA support, which (fortunately) wouldn't be too difficult.
Slashdot Mirror
Huh? README.Ports mentions that it had been ported to a Mac long ago, but it definitely wasn't written on a Mac. I think I should know...
That's the problem, isn't it?
If only I had the time...
LinuxThreads aren't different, but under 2.4, capabilities can be retained across setuid(). So, named can call setuid() early (that is, before threads start), while retaining the ability to later bind port 53.
The port is bound after starting threads because it can't be bound until after the config file is read, since the config file specifies the ports to listen on. The config file is read after threads are started for several reasons, not the least of which is that it's also read with threads active in the reload case.
With bind 9 on linux, a chroot jail cannot be broken out of using those steps, since the CAP_SYS_CHROOT capability is dropped.
If you want setuid on a 2.4 kernel, compile with --disable-threads.
No link to www.xbill.org. I wonder if I should be offended.
Nope, xbill was started before WinG existed :)
Yeah. In less than 2 years since I wrote that paper, NAI has changed the URL about 6 times, without ever leaving a redirect in place.
:)
You're right, currently, a bind 9 server cannot handle DDNS from an MS client. We hope to have that working at some point in the future. Another possibility (which doesn't always work, of course), is to let the DHCP server send updates for clients, which means that only the DHCP server needs to authenticate to the server. I know this doesn't work in all cases, but I'd also never advocate using an MS client
Win2K doesn't support DNSSEC at all, at least not in the traditional sense. It supports transaction security (mostly used to authenticate dynamic updates), using a method incompatible with IETF standards (including their own spec, interestingly). If MS actually documents what they're doing, bind will support it (at some point).
DNSSEC authentication is fully dependent on clients. Servers can give out digital signatures, but clients must be configured to authenticate them for them to be useful. So, if MS doesn't implement DNSSEC, that means that MS clients wouldn't notice spoofing, but others might.
> *One* Server holds the master file? > No load balancing/[obligatory beowulf]/Round Robin? > I would like to think there is some redundancy in there... Yes, one server holds the master file, and distributes it to the other 12 top-level servers. Queries are load balanced between all of the top-level servers.
> XBill 3D would be cool.
:)
Yeah, it would. I wish I had the time to learn about 3D game programming, and the artistic talent to create the models
> If my key is compromised and I have to generate a new on who signs my key, internic, verisign?
.com key, which signs the foo.com key, and so on.
:)
Your parent zone. The root key signs the
> Meaningful encryption would push the 512 byte limit of dns udp packet to a much smaller payload, making the use of tcp for common dns activities necessary thereby tremendously reducing dns performance.
DNSSEC doesn't include encryption, only authentication. Yes, the 512 byte UDP limit is an issue, but there is a proposed solution (EDNS).
> Meaningful encryption would cause CPU load - period. Imagine the com root servers having to encrypt every answer. This would probably end up requiring an Origin 2000 and remember that 8.2.2 isn't able to take advantage of SMP.
Again, there is no encryption. Digital signatures are precomputed, so there's no additional CPU power required on root servers at runtime. Caching servers, which will verify DNSSEC signatures on incoming data, will require more CPU power.
There's no reason to encrypt DNS data - it's all public anyway. Authentication is far more important, so that connections can be made to a verifiably correct site.
Are you sure you listened to Paul Vixie's presentation?
> if DSA is considerably slower than RSA, it shouldn't be that big of a deal -- they only need be signed once.
Signing's not a problem - RSA and DSA are about the same speed. When verifying, though, RSA is much faster (22x faster in the test I just ran).
Yes, RSA does encryption. It also can be used for authentication, but not exactly in the way you describe.
An entity holds a public/private key pair. When sending a message, it generates a hash or digest(MD5, SHA1, etc), and applies the algorithm to the hash using its private key. This creates a digital signature which is sent along with the message. The public key is widely disseminated. Therefore, when the message and signature are received, the receiver can compute the message digest and use the RSA public key to prove that the signature is valid.
This is not useful for encryption, since the message is sent in the clear, and cannot be obtained from the digital signature alone. This is how DNS Security works - KEY records store public keys in DNS, and SIG records contain digital signatures.
Authentication is authentication (well, there are two methods - the standard and Microsoft's :) ). The same authentication mechanisms can be applied to a zone transfer or an update (or even a normal query), since the authentication applies to the full DNS message and is based on the identity that sent the request.
RSA is not used for encryption; DNS doesn't do encryption. RSA is not used for securing zone transfers, it's used for generic data authentication, as specified in the DNS Security RFCs. The other alternative is DSA, which is the required algorithm, but RSA verifications are approximately 60x faster, which makes a pretty big difference. A different implementation of RSA cannot be used, because of patent issues. Export control is not an issue, since RSA is only used for authentication.
It looks like the only option is to optionally remove RSA support, which (fortunately) wouldn't be too difficult.