Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
The Internet

New DNS Software to Address Security Holes 80

Ben Galliart writes "The Internet Software Consortium released on Monday another patchlevel to their ever popular BIND software package. The ISC has recommended that everyone using BIND upgrade to this latest version (BIND v8.2.2 patchlevel 3) due to security holes existing in previous versions. If you are using a version previous to BIND 8.2.1 then pay special attention to the ISC configuration hints on a new required TTL setting which should be added to every zone file. More information on the TTL setting is also available in RFC 2038. On a side note, those who enjoy the bleeding edge should read the ISC future plans page which now has information on the thread-safe/multi-processor ready BIND version 9 (major rewrite) going beta in January. "
This discussion has been archived. No new comments can be posted.

New DNS Software to Address Security Holes

Comments Filter:
  • It would be nice if some of the real security people out there would work toward a standard of intersystem daemon security. An SSH [www.ssh.fi] (SECIP) style public-key with trust (signed keys -- like PGP/GPG [linuxsupportline.com]) system (in a library) that could be linked against by all those making daemons. BIND could link against it to authenticate messages it sends and receives, so could PING (for those of us who don't like pingfloods) and X.

    Each daemon is starting to add its own security (Cyrus IMAP has several options) and they aren't inter-compatible. If there were a common library they were based on, it could be improved upon by all parties involved.

    Hate to point out one of the greatest benefits of open source -- shared library code that you can modify -- and also one we are bad at actually doing.

    - Michael T. Babcock <homepage [linuxsupportline.com]>
  • BIND is less and less open in it's development, which can't be a good thing. If BIND is to compete with other name-servers, it can't afford to hide it's head in the sand and ignore the multitude of developers out there.

    Sure, it's not "prime time", yet! So? Give a bunch of computer phreaks the source, and they'll patch more bugs in a day than the entire BIND development team can find in a week. That's not to put the BIND team down, but a closed testbed network (typical for this kind of work) is not going to find bugs that'll crop up in the real world.

  • If there were a common library they were based on, it could be improved upon by all parties involved.

    This is going on in the OpenBSD community, but don't forget that because of stupid and worthless crypto-export laws and IP 'patents', developers and users in the US may not be able to use it.

    Sucks if you're a developer or user in the US, but it doesn't seem to be holding OBSD people back any...
    Your Working Boy,
  • by strabo ( 58457 ) on Wednesday November 10, 1999 @09:02AM (#1544874) Homepage
    There was a bug that made it into named-xfer that prevented AXFR from working properly. The change below will fix it... Hope this helps someone!

    - Strabo

    The following change should correct
    the problem.
    Index: src/bin/named-xfer/named-xfer.c
    ================================================ ===================
    RCS file: /proj/cvs/isc/bind/src/bin/named-xfer/named-xfer.c ,v
    retrieving revision 8.88
    retrieving revision 8.89
    diff -c -r8.88 -r8.89
    *** named-xfer.c 1999/11/08 23:01:39 8.88
    --- named-xfer.c 1999/11/09 20:36:54 8.89
    ***************
    *** 2195,2201 ****
    zp->z_origin, zp_finish.z_serial);
    }
    soa_cnt++;
    ! if ((methode == ISIXFR) || (soa_cnt > 2)) {
    return (result);
    }
    } else {
    --- 2195,2201 ----
    zp->z_origin, zp_finish.z_serial);
    }
    soa_cnt++;
    ! if ((methode == ISIXFR) || (soa_cnt >= 2)) {
    return (result);
    }
    } else {

  • by Effugas ( 2378 ) on Wednesday November 10, 1999 @09:02AM (#1544875) Homepage
    I'm no DNS Expert(though I do admin my own personal domain) so there's a sense of rummaging through something much larger than I've grokked at this point.

    Here's a useful chunk from the RFC:



    "Negative caching" - the storage of knowledge that something does not
    exist. We can store the knowledge that a record has a particular
    value. We can also do the reverse, that is, to store the knowledge
    that a record does not exist. It is the storage of knowledge that
    something does not exist, cannot or does not give an answer that we
    call negative caching.


    What's now mandatory--


    [RFC1034] provided a description of how to cache negative responses.
    It however had a fundamental flaw in that it did not allow a name
    server to hand out those cached responses to other resolvers, thereby
    greatly reducing the effect of the caching. This document addresses
    issues raise in the light of experience and replaces [RFC1034 Section
    4.3.4].

    Negative caching was an optional part of the DNS specification and
    deals with the caching of the non-existence of an RRset [RFC2181] or
    domain name.

    Negative caching is useful as it reduces the response time for
    negative answers. It also reduces the number of messages that have
    to be sent between resolvers and name servers hence overall network
    traffic. A large proportion of DNS traffic on the Internet could be
    eliminated if all resolvers implemented negative caching. With this
    in mind negative caching should no longer be seen as an optional part
    of a DNS resolver.


    HTH.

    Yours Truly,

    Dan Kaminsky
    DoxPara Research
    http://www.doxpara.com

  • by Knight ( 10458 ) on Wednesday November 10, 1999 @09:08AM (#1544877)
    While I'm encouraged that they are fixing the problems with the package, I wish there were an easy way to deal with the inherent problems with the protocol itself. It's still fairly trivial to poison DNS caches, and lookups are still not encrypted, which although not much of a security issue by itself, it's a bit of a privacy issue. We've come to a point where if a program relies on reverse DNS lookups, any DNS expoit used against it is considered a security problem with the program, not DNS. The truth is, however, that the DNS system should be reliable enough that these types of attacks wouldn't even exist. Don't get me wrong, I applaud their work for fixing the bugs that they have, but there is some basic protocol work that needs to be done before I'm happy with it. Here [insecure.org] is a interesting example of DNS quirks.

    If you need to point-and-click to administer a machine,
  • This is very bad, but I don't think we should be suprised.

    One of the *BSD project leaders said after the 4.9.? remote exploit that he doesn't trust the BIND code.

    It's possible to run the name server in a chroot jail as a non-root user. That won't solve the DoS problems, but at least you won't get "owned".

    Hmm... I had a URL with instructions but now I can't find it... Anyone have a link?

  • One of the issues floating around BIND lately has been it's use of RSA authentication. Of course, RSA is patented (yuck). Debian has dealt by redistributing BIND without the RSA stuff. Does this version follow suit? More non-free stuff?
  • by CheezH ( 5990 )
    I for one will be quite happy when Dents [dents.org] is a suitable replacement for BIND. BIND seems to be quite old and crufty at this point, and Dents has a very nice design so far. Modular everything, and CORBA for administration. No more overloading of signals and crap like that. Whee!
  • Correct me if I'm wrong, but what you're asking for seems to be an application-level IPSec-style connection.

    Now there -is- a definition for IPSec authentication, but for the machine as a whole. It doesn't work at a finer level than that.

    Then, there are X.509 certificates, and SSL. Plenty of libraries, there, and certificates are easy enough to roll. Problem there is that it would require more extensive work on the part of the maintainers. It -would- be possible, though.

    The question I'll ask is this - for the purpose of authentication, would it be sufficient to authenticate the machine, or would it be essential to authenticate the application?

    If the former, then simply install IPSec or SKIP on all the machines that use daemons, and use IPSec/SKIP connections between those machines.

    If the latter, get OpenSSL and modify the application to work through it.

  • by decaym ( 12155 ) on Wednesday November 10, 1999 @09:18AM (#1544882) Homepage
    Go to the future plans page and look for the list of contributors down at the bottom. Notice who is missing from the list? Of course, it's our old friend NSI. It's rather appalling that the company most dependent on the performance of BIND is one who sees no benefit in helping with it's development.
  • Wonder if the NSA will allow exports of this new "strong programming" version of the daemon. I mean, if American Nationalist Loyalists can't just hack into any system they want, this seems to me like a Bad Thing. Certainly a security threat :)
  • by MikeBabcock ( 65886 ) <mtb-slashdot@mikebabcock.ca> on Wednesday November 10, 1999 @09:23AM (#1544884) Homepage Journal
    As some have pointed out, there are many protocols that are "open" that could be updated to do something like what I've mentioned. Just to put a few more of my thoughts down on virtual paper (PS, the thoughts are GPL'd if that's possible; you can use them for any GPL project :).

    I'd like to see something along the lines of an authenticaed ident server as a necessary part of this protocol. It wouldn't be a daemon running (like ident) to identify callers, but the daemon (like BIND) connecting to the remote daemon would identify who it is (SSH2 style) and what machine it is running on (also SSH2 style).

    Why identify both the machine and the daemon? Because a daemon could be loaded up by a (bad) user and run on a different port, linked against the authentication library and attempt to send bad data "out there" to other machines. In this way, the daemon itself would have identity information either created at compile-time (and linked in via header) or some other method. Of course, the daemon would have to be unreadable by anyone but root (or its own username), but that's ok, right?

    Sending data over a secure connection works just fine if you don't want people snooping, but authenticating a daemon requires more than that. In the case of DNS, one of the big factors is authenticating that the DNS server you've connected to is indeed who it claims to be.

    XNTP3 does this as well (in a basic form) if you want to create time peers that authenticate off each other.

    RFC ideas anyone?

    - Michael T. Babcock <homepage [linuxsupportline.com]>
  • As per RFC 2308 (DNS NCACHE), the SOA minimum field now is the NCACHE TTL value. In the past, the SOA Minimum field had three meanings:

    1. The minimum TTL for that zone
    2. The default TTL for records without one specified
    3. The TTL of negative responses

    #1 was never used, #2 is only relevant on the master server (since TTL is explicit during a zone transfer), and #3 is now the ONLY meaning for the SOA Minimum field.

    What this means is that to fulfill #2 (default TTL), you will now have to add the $TTL directive to all zone files you are master of, and modify the SOA Minimum field to something more appropriate for the NCACHE TTL. Your zone file would look something like this:

    ; Example of $TTL and SOA
    $ORIGIN whatever.org.
    $TTL 86400 ; Default TTL (1 day)

    @ IN SOA ns1.whatever.org. postmaster.whatever.org. (
    1999111001 ; Serial
    10800 ; Refresh (3 hours)
    3600 ; Retry (1 hour)
    604800 ; Expire (1 week)
    1800 ) ; NCACHE TTL (30 minutes)

    These values are, of course, not set in stone - just an example. However, most people set their SOA Minimum field to somewhere around 1 day, give or take, to reduce load on queries to their server. This value is likely to be too high to cache NEGATIVE answers, so should probably be adjusted.

    As for the $TTL directive, just add it before the SOA record, usually with whatever was the previous value for the SOA Minimum. If it is not designated, BIND will issue a warning, but will use the SOA minimum instead. Annoying to see all the warnings if you have a large number of zones, but it doesn't cause problems other than the logging:

    Nov 10 12:15:12 thanatos named[14344]: Zone "whatever.org" (file whatever.org.db): No default TTL set using SOA minimum instead


    This information only pertains to BIND 8.2.0 and above (including 8.2.2-P3, obviously).

    - Strabo

  • ...something much larger than I've grokked at this point.

    This question isn't directed at you, but I'm curious...outside of posts to slashdot, or writing in general, does anyone actually use the term "grok" in conversation? I have yet to hear one person say it and I work with some serious geeks.

  • What do you mean by less and less open? They always provide the full source. Cut them some slack. They just don't want to release messy alpha software to the public.

    Please forgive ISC for choosing a smaller, dedicated development group over a mass of chaotic hobbyist whiners. Don't take that as a flame. It's sarcasm.

    Let them do the kickass job they always do and release a version when they're ready.
  • By authenticating the application you could guarantee that a certain daemon is actually THAT daemon and not a hacked telnetd for instance. Is that possible or does it make no sense at all?
    "We hope you find fun and laughter in the new millenium" - Top half of fastfood gamepiece
  • by VanL ( 7521 )
    Yep, I use it. But then again, I'm a Heinlein fan ...
  • by Anonymous Coward
    CERT should be telling admins about this. Where are you guys? No mention on bugtraq or securityfocus. According to strabo's post, 8.2.2p3 is broken. ISC, how 'bout releasing 8.2.2p4??
  • by Signal 11 ( 7608 ) on Wednesday November 10, 1999 @10:02AM (#1544892)

    This is the FBI. We've recently gotten word of a new kind of internet protocol called 'dns'. We require that you immediately install backdoors into the protocol so we can secretly monitor all dns communication. It is not relevant that information in dns servers are publically available. This will be done at once. We will not provide assistance to you to do this. Thank you for your continued compliance.

    Sorry.. given the proxmimity to the wiretapping article.. *somebody* had to do it! =)



    --
  • ...does anyone actually use the term "grok" in conversation?

    Sure, I hear/use it all of the time. It is not a geek thing per se, but a sci-fi thing. Not all geeks are sci-fi fans, and not all sci-fi fans have read Stranger in a Strange Land, hence, the paucity of grok usage in your vicinity.

    You grok?

  • I've heard a few people use it, but it is getting rare.
  • I didn't know that the term originated in that book. I just checked Amazon and it has over 200 reviews! I'm going to stop over at B&N, grab a cup of coffee and read a few pages to see what the commotion is all about.

    Slashdot is great. You ask a question and it gets answered...and quickly too. I thought I was going to get flamed for asking a "stupid" question, so thanks to everyone who responded kindly.
  • Oh, certainly. Netrek has had blessed clients for a long time, for much the same reason.

    It's possible, but it's not trivial to do well. What you need to do is embed some kind of certificate within the application, in such a way that it is not practical for a third-party to extract it and embed it into another application.

    Because the source for the application is going to be open, it will always be possible for a third-party to monitor what goes into and out from any decryption algorithm. This leaves two possibilities for protection:

    1. Make the relevent part of the source -so- obscure, and/or byte-length dependent that tampering with the code would be virtually impossible.
    2. Don't send the certificate at all, but rather use it as the basis for some VERY complex calculations, which are dependent on the compiled binary, which are then passed back. The idea here would be to make it difficult for someone to usefully insert the code into another application, by making the output sent to the requestor non-trivial.

    Both these methods have strengths and weaknesses. They both rely on obscuring the security, by putting it in plain sight, which is great for Open Source code, but both can be defeated, so they're not perfect.

  • I'm curious...outside of posts to slashdot, or writing in general, does anyone actually use the term "grok" in conversation? I have yet to hear one person say it and I work with some serious geeks.

    Oh yeah. I snarfed Win95 when it came out, and I've been glorkonzed ever since. Who could grok the sucker?

    ======
    "Rex unto my cleeb, and thou shalt have everlasting blort." - Zorp 3:16

  • Because the source for the application is going to be open, it will always be possible for a third-party to monitor what goes into and out from any decryption algorithm.

    That was the one of the two issues that came to mind after I thought about it.

    1. With the source being open of course, someone with enough skill would be able to hack a fake daemon and replace the true one. This would still knock out most of the lil scrpt kiddies who like to play until someone came up with an easy to use root kit.
    2. How do you handle authentication without making it too complicated to implement? This would certainly be easy for trusted sites but if that were the case you would use IPSEC and vpn the remote sites with you anyway.

    guess it was just wishful thinking on my part ;)
    "We hope you find fun and laughter in the new millenium" - Top half of fastfood gamepiece
  • I saw the thing about people testing bind for 'Y2K readiness' using the zone serial number.. they totally miss the point of zone serial numbers %)

    Either that or they're really scamming some companys big time fixing this 'bug.'

    In case people are confused about how others use dates in the serial number, it's just a little trick sys admins use so they can see when someone last updated the zone.. generally people use the YYYYMMDDR thing like it said.. the R is the number of times in the day that the zone file was updated. the only thing about doing this is that if you put '10' in R and then the next day you start at 1 again, the number will be smaller than the previous day, e.g. 1999032710 and 199903281.

    I prefer the simple 'increment the number' way personally.

  • Just went to the LISA conf yesterday for a tutorial on BIND given by Vixie himself. He spent a bit on the logistical/technical issues DNSSec. Just a quick run down.

    • If my key is compromised and I have to generate a new on who signs my key, internic, verisign?
    • 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.
    • 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.

    I have nameservers that can get well over a 1000 requests per second (not that they actually answer them all:). I'm not going to encrypt every response, it's just not that important. It is far more practical to use this as an internal security measure but for the internet - don't make me laugh.

  • by mattc ( 12417 )
    Does anyone have a mirror for this? My download is stuck on 1%
  • Let's say that the server includes the same library as a client. So, by taking the binary, and treating it as a number, you can, oh, XOR a randomly-selected chunk, with a randomly-selected segment of the certificate.

    You then pass the combined values over to the client, who XORs it with the same chunk of the same piece of compiled code. What's revealed is that fragment of the certificate.

    This is, of course, a very trivial method. To get something more tamper-proof, you'd want to extract discontinuous pieces of the code & certificate, using some complex function to determine which bytes you wanted.

    This would give you something that was sufficiently tamper-proof to resist script kiddies and novice crackers, whilst remaining very simple to implement.

    The pseudo-code would look something like:

    recv(client, random_gen_seed);
    seed_generator(random_gen_seed);
    for (i=0;i++;i offset = my_random_fn(i);
    value = *(lib_ptr + offset) xor *(cert_ptr + offset);
    *buffer++ = value;
    }
    xmit(client, buffer);

    From here, you can add further complexity, to your heart's content, but this should offer you enough security to block trivial cracks.

  • I'm curious if Microsoft DNS Server has this same problem? of is this one of those issues where no sophistication = no security holes. like the military using Apple web servers? please don't replay with endless ramblings about how Microsoft DNS is inferior, and how bill gates is an evil monster sent from the devil to destroy mankind. -Jon
  • ftp://ftp.isc.org/isc/bind/src/8.2.2-P3/patch4

  • I'd like to run two dns servers on the same machine, one for queries coming from the internet and the other for queries coming from the lan.


    Yeah, I know. The "right" way to do it is to run the internal dns somewhere besides on the firewall, but I've got a scarcity of Unix boxen (read ONE).


    Wondered if it was possible to configure BIND to bind to a specific address or port? Perhaps with tcpserver?

  • According to ISC's website:

    "ISC has discovered (or has been notified of) six bugs which can result in vulnerabilities of varying levels of severity in BIND as distributed by ISC. CERT has been notified of all of these issues."

    Also, "In addition to fetching the bind-src tarball, you will need to fetch and apply the following patch. If you do not apply this patch, your zone transfers may fail."

    - ftp://ftp.isc.org/isc/bind/src/8.2.2-P3/patch4

    This is from:

    http://www.isc.org/products/BIND/bind-security-1 9991108.html

    - Strabo
  • by Anonymous Coward
    Hmm... I had a URL with instructions but now I can't find it... Anyone have a link?

    http://www.psionic.com/papers/dns/ [psionic.com]

  • You of course realise that SSH2 is Open Sourced ... and that its very secure. The idea here is to generate keys at install time, not compile-time.

    If a key is generated at compile-time, it can be stolen ... the only time to do it that way is if you're not distributing binaries and you generate the key for inclusion in the compiled program yourself (with an included function) before compilation.

    ./configure
    make key
    .oOo.oOo.oO...
    src/keyfile.h completed

    make all
    make install

    ... tada ;-)

    The idea I had was to have these keys actually signed by an external program (that uses the same authentication toolkit library) so that you can say, "yes, I trust these keys to be from the daemons at the root servers" and if you geet root server replies from anyone else, you ignore or negative cache that they're bad ;).

    - Michael T. Babcock <homepage [linuxsupportline.com]>

  • Here is a possible protocol for an open-source program to authenticate itself.

    • Concatenate the binary of the program with the current time (in Universal Time), put in X
    • Hash X using a one-way hash function
    • Send hash value as certificate

    This protocol does not work, because if you have the source code for the hashing function and a copy of the "real" binary, you can spoof the authenticator. Is there a solution?

    If there is a kernel or library function that hashes the binary code of the calling process, it is possible. The hashing function could be open-source, but the compiled function would have to include an embedded constant known only to the authenticator.

    I don't know how feasible that is. The idea is if you hacked the source of the hash function and recompiled, you would lose the embedded constant. Of course if you hack the original program, when you call the hash function it will return the wrong value.

    Just some random thoughts.

    Nathan Whitehead

  • By authenticating the application you could guarantee that a certain daemon is actually THAT daemon and not a hacked telnetd for instance. Is that possible or does it make no sense at all?

    This is not a good idea in general.. as it slows inovation and really removes all the benifits of open source. The better approach is to simply desgn the protocolls so that it dose not matter if you hack the daemon. SSH is a perfect example. If I replace you sshd I can not obtain your password.. only your public key, which dose me no good and I could obtain anyway if I had access to replace the daemon.

    Also, remember that the person running the blessed binary controls it's enviroment and jsut because I'm taling to a blessed binary dose not mean that it can not be tricked into doing something nasty. Example: write a fake X server and a fake libc network interface which interacts with your blessed netrek client to make it do ubernasty things, but if the protocoll had been designed with appropriate constraints this woud not matter. Generally, it is much harder or imossible to design a program to be secure in a hostile eniroment.. so just do all you sensitive stuf in a frendly enviroment.

    Jeff
  • One of the major contributors to BIND development, Paul Vixie, runs a little service called The MAPS RBL [mail-abuse.org]. The RBL, if you don't know, is a service which maintains lists of servers from whence spam has originated and the admins didn't respond to requests to lock down their servers.

    According to this story [cnet.com], MAPS threatened to put NSI on the RBL list because of the unsolicited email NSI was/(is?) sending to its domain registrants.

    I think you've got your answer as to why NSI doesn't help with BIND. Buncha greedy bastards.

    --
    A host is a host from coast to coast...

  • (in Homer Simpson's voice)
  • ...the Slash code was enhanced such that any post within the first 50 per article which contained the words "first post", in that order, in the topic, was automatically deprecated to -2?
  • Yes, this situation was mishandled, however it was mishandled on ISC's part, not CERT's. The web page was released prematurely. The CERT advisory was originally planned to go out today (prior to the web page getting linked in), but was delayed until Monday at ISC's request. Unfortunately, the ISC page got updated according to the original schedule. CERT is _NOT_ to blame. I apologize to all who may have been negatively impacted by this issue. Rgds, -drc Executive Director, ISC.
  • At the request of several organizations (not just debian), ISC has modified the distribution so that you can type "make noesw" (no encumbered software) which will remove the encumbered sources from the distribution (specifically, the DNSSafe library from RSA and the DSS/DSA library from Cylink). Rgds, -drc Executive Director, ISC
  • > 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? :)
  • Well, I know that you've just wasted my time with your content-free posting. And, alas, I'm wasting someone else's time with this response. You see how destructive this kind of thing is? If you have nothing to say, consider shutting up.

    It doesn't take a genius to look up IETF working group names.

    BTW, there is only one 'Internet protocol' in the TCP/IP suite, I don't know of any 'supporting Internet protocols.' Perhaps you could enlighten us.

    Recommendation: Don't be so smug. If you don't like it, move on.
  • Bind 8.2.2 is introducing a serious problem - it can't be exported from the US thanks to the RSA code. That's why we can't release updated packages right now. (Anyone in non-US downloading bind from ISC is exporting weapons, by the way).
  • Can someone provide some pointers as to how to set up BIND securely if you are only aiming to run it as a primary or secondary name server? (I think that implies no zone transfers or forwarding). And should it be running chrooted (under FreeBSD) or does that provide additional implications?
  • by peter ( 3389 )
    check the jargon file [tuxedo.org]
    #define X(x,y) x##y
  • In case people are confused about how others use dates in the serial number, it's just a little trick sys admins use so they can see when someone last updated the zone.. generally people use the YYYYMMDDR thing like it said.. the R is the number of times in the day that the zone file was updated. the only thing about doing this is that if you put '10' in R and then the next day you start at 1 again, the number will be smaller than the previous day, e.g. 1999032710 and 199903281.

    Yeah, we use that scheme here, and I like it a lot. But you can actually use two digits for the increment, which gets around the problem you mention. That's what we do - YYYYMMDDRR. But then again, I've never seen RR get above 05.

    Dave

  • If my key is compromised and I have to generate a new on who signs my key, internic, verisign?


    I envisioned (I thought clearly) something more along the "web of trust [linuxsupportline.com]" lines. Smaller ISPs have their keys signed by their larger ISPs (arranged somehow -- not too hard) and larger ISPs can do the same between each other for the sake of most protocols. This would be easier than what DNSSEC is going to require in some circumstances.

    Since I envisioned a generic library for any type of daemon (with several options, of course, but one underlying security model), many of these systems don't have to be signed by many people at all -- security is desired, so those who want it arrange it.

    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.


    I'm not sure what you're trying to say here. That if I encrypt data it grows? This isn't very true (except for the need for headers, etc.). If the stream is encrypted before being packaged (UDP, TCP), the encryption negotiation would be a packet or two every hour or so and the actual encrypted communications would be the same size, just encrypted. The only added data would be hashes for authentication.

    You'd want to precompress (to a small degree) of course, seeing as compression is less CPU intensive (in some cases!) than encryption. You end up encrypting less data then and the hash is tacked on to that.

    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, I don't care if BIND can (currently) make use of SMP or not; my ideal would be it taking advantage of a library which itself could be SMP capable. I don't buy the CPU intesity argument though because with the exception of high end routers, most machines aren't processing enough data of the type discussed here for the encryption to be significant.

    I may be wrong ... but in my experience (quite a bit, but I'm not a cryptographer or an NSA guy, just an implementer), there are cyphers sufficient for burst transmissions of this kind that are quite CPU non-intensive.

    For instance, consider a system where a new session key is negotiated by two time servers every hour. The encryption needs to be such that it can't be broken in under an hour or two (a week would be a nice goal here). Simple DES would be sufficient for most cases (although not necessarily best).

    Of course, the whole point here is that I had not intended to fully flesh out how such a system would run. I do not consider myself fully capable of doing such without heavily referring to how others have already done it (ahem, patents).

    Mind you, in the case of DNS and your mention of 1000 requests per second, I don't buy that convenience is more important than security in the long run. Computers are becoming much much faster every year. Put a pair of SMP Athlon 700's on a network to handle DNS and caching for a company where previously there were quad P-Pro 200's. Makes for a significant upgrade at about the same cost as the original investment but with significant head room, especially to handle the amount of encryption I'm talking about.

    My concept of a good system for this would be to have multiple cyphers chosen based on the amount of data being sent to a given location (whether a "stream" can/will be held open to them) and the length of time needed for security.

    I don't see a DNS packet needing to be authentic for more than an hour or so ... ditto for NTP and ICP requests.

    SMTP and IMAP would need much stronger hashes to make sure E-mail was authentic (especially large companies who go to trial ;-) ) ... etc.

    I think it's "doable" and I'd love to see someone like NAI, SSH or Bruce S. fiddle with it seriously.

    - Michael T. Babcock <homepage [linuxsupportline.com]>

"It's ten o'clock... Do you know where your AI programs are?" -- Peter Oakley

Working...