Full_Name: Geert Jansen Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/geert-jansen-081115.patch Submission from: (NULL) (12.230.186.195) This is a resubmission of my earlier patch in [1]. I'm asking for this patch to be included into OpenLDAP. The patch adds an LDAP option called LDAP_OPT_X_SASL_NOCANON to disable host name canonicalization using reverse DNS for the host name that is passed into SASL. Instead, it passes verbatim the host name part from the LDAP URI and lets SASL do the canonicalization. The option is disabled by default. Kerberos requires a canonical host name to work. Traditionally, host name canonicalization has been done using reverse DNS. However, this is problematic. See the comment below from the MIT Kerberos source on this subject: /* XXX: This is *so* bogus. There are several cases where this won't get us the canonical name of the host, but this is what we've trained people to expect. We'll probably fix it at some point, but let's try to preserve the current behavior and only shake things up once when it comes time to fix this lossage. */ Since some time MIT Kerberos has support for server-side canonicalization which is an alternative for the DNS based scheme. By default it uses both, but with an option "rdns = no", reverse DNS can be disabled. The use case for this is environments that do not have reverse DNS set up correctly. Especially in Windows Active Directory environments this is very common. Administrators are afraid to enable scavenging for their zones, and therefore any server IP change will leave a stale PTR record in place. This breaks reverse DNS based canonicalization if the IP adress is reassigned. The behaviour enabled by this patch should remain optional and cannot become the default. It breaks the use case when multiple LDAP servers are load balanced using a CNAME record. [1] http://www.openldap.org/lists/openldap-devel/200710/msg00071.html
geert@boskant.nl wrote: > Full_Name: Geert Jansen > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/geert-jansen-081115.patch > Submission from: (NULL) (12.230.186.195) > > > This is a resubmission of my earlier patch in [1]. I'm asking for this patch to > be included into OpenLDAP. > > The patch adds an LDAP option called LDAP_OPT_X_SASL_NOCANON to disable host > name canonicalization using reverse DNS for the host name that is passed into > SASL. Instead, it passes verbatim the host name part from the LDAP URI and lets > SASL do the canonicalization. The option is disabled by default. > > Kerberos requires a canonical host name to work. Traditionally, host name > canonicalization has been done using reverse DNS. However, this is problematic. > See the comment below from the MIT Kerberos source on this subject: > > /* XXX: This is *so* bogus. There are several cases where > this won't get us the canonical name of the host, but > this is what we've trained people to expect. We'll > probably fix it at some point, but let's try to > preserve the current behavior and only shake things up > once when it comes time to fix this lossage. */ > > Since some time MIT Kerberos has support for server-side canonicalization which > is an alternative for the DNS based scheme. By default it uses both, but with an > option "rdns = no", reverse DNS can be disabled. > > The use case for this is environments that do not have reverse DNS set up > correctly. Especially in Windows Active Directory environments this is very > common. Administrators are afraid to enable scavenging for their zones, and > therefore any server IP change will leave a stale PTR record in place. This > breaks reverse DNS based canonicalization if the IP adress is reassigned. Breaking more software to use it with already broken software is, in a word, stupid. The standard practice for Kerberos requires you to have consistent forward and reverse DNS lookups. Sysadmins who are afraid to administer their software should either change their software or change their jobs. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Sat, Nov 15, 2008 at 6:20 PM, Howard Chu <hyc@symas.com> wrote: > > Breaking more software to use it with already broken software is, in a > word, stupid. The standard practice for Kerberos requires you to have > consistent forward and reverse DNS lookups. Sysadmins who are afraid to > administer their software should either change their software or change > their jobs. Well .. I don't think my patch qualifies as breaking software to work with broken software. The patch allows OpenLDAP applications to use alternative ways for name canonicalization. At this moment this is not possible because OpenLDAP is hard coded to canonicalize names with reverse DNS. This means I cannot use the option that MIT Kerberos provides me to disable this (rdns = no), as host names have already been reverse mapped by OpenLDAP before they are passed into Kerberos. I agree with you that reverse DNS should be correct. I just mentioned the fact that many reverse DNS setups are broken as an example of why it can be problematic. Another reason why canonicalization based on reverse DNS is problematic is that it requires secure DNS to be secure. RFC4120 mentions this: Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names (i.e., they MUST NOT use insecure DNS queries to map one name to another to determine the host part of the principal name with which one is to communicate). The same RFC recommends in fact that applications do not canonicalize host names at all: To maximize interoperability and security, applications SHOULD provide security mechanisms with names that result from folding the user- entered name to lowercase without performing any other modifications or canonicalization. My patch implements this behaviour, as an option. Regards, Geert
Geert Jansen wrote: > Well .. I don't think my patch qualifies as breaking software to work > with broken software. The patch allows OpenLDAP applications to use > alternative ways for name canonicalization. At this moment this is not > possible because OpenLDAP is hard coded to canonicalize names with > reverse DNS. This means I cannot use the option that MIT Kerberos > provides me to disable this (rdns = no), as host names have already been > reverse mapped by OpenLDAP before they are passed into Kerberos. > > I agree with you that reverse DNS should be correct. I just mentioned > the fact that many reverse DNS setups are broken as an example of why it > can be problematic. The fact that many environments are misconfigured is not a good reason to change the current behavior. > Another reason why canonicalization based on reverse > DNS is problematic is that it requires secure DNS to be secure. RFC4120 > mentions this: That is completely irrelevant. If a given site has a misconfigured DNS, whether or not it uses integrity or privacy checks on the DNS service, it is still misconfigured. > Implementations of Kerberos and protocols based on Kerberos MUST NOT > use insecure DNS queries to canonicalize the hostname components of > the service principal names (i.e., they MUST NOT use insecure DNS > queries to map one name to another to determine the host part of the > principal name with which one is to communicate). > The same RFC recommends in fact that applications do not canonicalize > host names at all: > > To maximize interoperability and security, applications SHOULD provide security > mechanisms with names that result from folding the user- entered name to > lowercase without performing any other modifications or canonicalization. Wishful thinking; that recommendation is at least 15 years too late and the majority of Kerberized software isn't going to change to accommodate it. In the meantime, the arguments about secure DNS are pure red herrings: 1. if your DNS has been hijacked, it's most likely that you'll be directed to a rogue KDC first, so the question of which service you're talking to is moot. 2. there's nothing to gain from directing you to a rogue service, since if you managed to contact the legitimate KDC, you're going to have a service ticket that can only be decoded by the legitimate service principal. On the other hand, if the rogue service is actually a valid principal in your trusted KDC's database, then you clearly have an administrative problem in your KDC. This patch attempts to provide a band-aid without actually solving the real problem. It merely masks the problem temporarily, until it gets even worse. This request is akin to asking for "schemachecking off" to be resurrected. This sort of feature is always requested because of an existing mistake, and allowing it only compounds the mistake further. We should never make it easier for admins to make and ignore mistakes. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Sun, Nov 16, 2008 at 2:25 AM, Howard Chu <hyc@symas.com> wrote: > That is completely irrelevant. If a given site has a misconfigured DNS, > whether or not it uses integrity or privacy checks on the DNS service, it is > still misconfigured. My point was that even if your reverse DNS mappings are correct, this is not a sufficient base for canonicalization. as it would have to be secure too. Or would you consider a DNS setup without DNSSEC to be broken too? In that case 99% of all setups would be broken. To maximize interoperability and security, applications SHOULD provide > security > mechanisms with names that result from folding the user- entered name to > lowercase without performing any other modifications or canonicalization. > Wishful thinking; that recommendation is at least 15 years too late and the > majority of Kerberized software isn't going to change to accommodate it. Not everybody needs to do this at once. MIT Kerberos already supports multiple ways of canonicalizing, including reverse DNS and the Canonicalize bit. Applications can start supporting this one by one. > In the meantime, the arguments about secure DNS are pure red herrings: > 1. if your DNS has been hijacked, it's most likely that you'll be directed > to a rogue KDC first, so the question of which service you're talking to is > moot. Wrong. Kerberos protects against that. A rogue KDC would not have your secret key and therefore is unable to generate a correct ticket for you. This would get noticed immediately by the library and the handshake would be aborted. > 2. there's nothing to gain from directing you to a rogue service, since > if you managed to contact the legitimate KDC, you're going to have a service > ticket that can only be decoded by the legitimate service principal. > On the other hand, if the rogue service is actually a valid principal in > your trusted KDC's database, then you clearly have an administrative problem > in your KDC. > Ok, so let me show you a real attack scenario as it indeed requires one copromised server. Supose an attacker has compromised one system in a Kerberos realm that was running a Kerberos service. The attacker can now spoof reverse DNS based on any of the available methods, and use it to redirect any internal service to a service on his server. He now puts up a mock up of the original service on the comprimised server, and coaxes users into entering any data that he would only enter in the real service. He can use this data to expand his compromised systems. If you would use secure canonicalization, the above cannot happen. It limits the scope of a compromise to that server. Without security canonicalization this is basically all-or-nothing security which is bad. This patch attempts to provide a band-aid without actually solving the real > problem. It merely masks the problem temporarily, until it gets even worse. No. From a security point it limits the impact of a comprimise of one server in your environment. From other point of views it helps environments that use the current best practise albeit broken method of canonicalizing host name. > This request is akin to asking for "schemachecking off" to be resurrected. > This sort of feature is always requested because of an existing mistake, and > allowing it only compounds the mistake further. We should never make it > easier for admins to make and ignore mistakes. This analogy does not work. The proposed option provides the possibility to implement a recommendation from the Kerberos RFC. Where in the LDAP RFCs does it say that it is recommended to turn schemachecking off? Regards,Geert
hyc@symas.com writes: > In the meantime, the arguments about secure DNS are pure red herrings: > 1. if your DNS has been hijacked, it's most likely that you'll be > directed to a rogue KDC first, so the question of which service you're > talking to is moot. > 2. there's nothing to gain from directing you to a rogue service, since if > you managed to contact the legitimate KDC, you're going to have a service > ticket that can only be decoded by the legitimate service principal. > On the other hand, if the rogue service is actually a valid principal in > your trusted KDC's database, then you clearly have an administrative problem > in your KDC. > > This patch attempts to provide a band-aid without actually solving the > real problem. It merely masks the problem temporarily, until it gets > even worse. My impression is that the broader Kerberos community is increasingly leaning towards not doing DNS canonicalization. That Kerberos libraries have been canonicalizing hostnames using DNS for quite some time is certainly true, but it's considered an unfortunate bug that needs to be supported for backward compatibility but that is clearly not the right way to do things. This is the reason why Kerberos implementations are increasingly adding options to disable DNS canonicalization. (1) is a vulnerability that Kerberos can protect against if you use it properly. It's called the Zanarotti attack, and the way that you defend against it is by obtaining a service ticket for a principal in a local keytab after initial authentication and verifying that the service ticket matches. This uses your shared secret with the KDC to verify that you're talking to the right KDC. Software such as PAM modules that do Kerberos authentications do this check as a matter of course. Once you've done that, further communication with the KDC is done using the session keys in your TGT, and a hijacked KDC won't be able to complete the protocol exchange because it can't decrypt the TGT. kinit and similar programs currently don't do this check by default, but there's no reason why they couldn't if an appropriate keytab is available. Your analysis of (2) assumes that every ldap principal in your KDC is created by someone you trust not to spoof any other ldap principal in your KDC. That's a high bar to meet and many sites are not going to meet that bar, nor want to given a competing desire for distributed administration. For example, Stanford allows students to run Kerberized services on their personal computers if they wish, and therefore allows them to download keytabs (and hence create ldap principals) for those computers. If they can use DNS hijacking to return a CNAME for an LDAP server pointing to their computer instead, they can obtain a legitimate keytab for the ldap principal for that computer, and can successfully trick a client that trusts DNS canonicalization. Another, possibly more obvious case where (2) doesn't hold is in the presence of cross-realm trust. If I can use DNS spoofing to return a CNAME of ldap.stanford.edu to dorm-machine.mit.edu, and stanford.edu and ATHENA.MIT.EDU have cross-realm trust, I can perform the same attack. So you not only have to trust everyone who can create ldap principals in your local realm, but everyone who can create ldap principals in any realm with which you have cross-realm trust. There are a lot of nasty things that you can do with DNS spoofing, and this almost certainly isn't the most likely attack, but it is a potential vulnerability that's been widely discussed within the Kerberos community, including transition plans for how to get away from always doing canonicalization. You can, for example, see part of the opinion of the MIT developers in the comments around the relevant segment of code: if (maybe_use_reverse_dns(context, DEFAULT_RDNS_LOOKUP)) { /* * Do a reverse resolution to get the full name, just in * case there's some funny business going on. If there * isn't an in-addr record, give up. */ /* XXX: This is *so* bogus. There are several cases where this won't get us the canonical name of the host, but this is what we've trained people to expect. We'll probably fix it at some point, but let's try to preserve the current behavior and only shake things up once when it comes time to fix this lossage. */ This is the reason why there's an rdns option in krb5.conf to disable this code. There has been other discussion of it on krbdev and kerberos@mit.edu in the past. I would agree that there's no way that you can change the default; too much stuff would break. That's also why the Kerberos libraries continue to do this by default. But I think the original bug reporter isn't unreasonable for wanting a way to disable canonicalization if they know that their code and environment will handle that appropriately. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
rra@stanford.edu writes: > (1) is a vulnerability that Kerberos can protect against if you use it > properly. It's called the Zanarotti attack, and the way that you defend > against it is by obtaining a service ticket for a principal in a local > keytab after initial authentication and verifying that the service > ticket matches. I'm sorry -- this is wrong. I overthought this. The scenario discussed here is not the Zanarotti attack. The Zanarotti attack involves spoofing the KDC so that you don't have to know the correct key for a principal; you instead use a key that you know and fool the system into talking to a KDC that uses the same key. It's an attack on login or a screen saver to allow someone to use a bogus password to authenticate. The protection against the scenario (1) listed here is integral into the Kerberos protocol. The Kerberos authentication process involves requesting a TGT from the KDC that's encrypted in your private key and then decrypting the return with your private key. You cannot spoof Kerberos initial authentication from a keytab or a correct password by using DNS to redirect the authentication to a bogus KDC because the bogus KDC won't know your correct private key and hence won't be able to return a TGT that you can decrypt. Similarly, you can't successfully redirect a TGS_REQ to a bogus KDC because that KDC doesn't have the private key and can't complete the protocol exchange. This is why kinit doesn't bother to protect against the Zanarotti attack; there's no need, since kinit doesn't provide increased local privileges and the Zanarotti attack is an attack only on the local system, not against a network service. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Russ Allbery wrote: > My impression is that the broader Kerberos community is increasingly > leaning towards not doing DNS canonicalization. That Kerberos libraries > have been canonicalizing hostnames using DNS for quite some time is > certainly true, but it's considered an unfortunate bug that needs to be > supported for backward compatibility but that is clearly not the right way > to do things. This is the reason why Kerberos implementations are > increasingly adding options to disable DNS canonicalization. > > (1) is a vulnerability that Kerberos can protect against if you use it > properly. It's called the Zanarotti attack, and the way that you defend > against it is by obtaining a service ticket for a principal in a local > keytab after initial authentication and verifying that the service ticket > matches. This uses your shared secret with the KDC to verify that you're > talking to the right KDC. Leaving aside your followup which clarified this clause: the obvious point is that a Kerberos client needs to have trusted *local* data to protect against this attack. Delegating the trust to the KDC obviously doesn't solve this problem. (Not to mention that again, a KDC is by definition a trusted 3rd party. If you can't trust it, then the entire Kerberos framework is compromised.) > Your analysis of (2) assumes that every ldap principal in your KDC is > created by someone you trust not to spoof any other ldap principal in your > KDC. Yes, again, that is implicit in the fact that the KDC is a trusted 3rd party. > That's a high bar to meet and many sites are not going to meet that > bar, nor want to given a competing desire for distributed administration. Delegating administration authority still implies that you trust whoever you delegated it to. Again, if you can't trust everyone then your administrative procedures are broken and your framework has already been compromised. > For example, Stanford allows students to run Kerberized services on their > personal computers if they wish, and therefore allows them to download > keytabs (and hence create ldap principals) for those computers. If they > can use DNS hijacking to return a CNAME for an LDAP server pointing to > their computer instead, they can obtain a legitimate keytab for the ldap > principal for that computer, and can successfully trick a client that > trusts DNS canonicalization. Trust within a realm is all-or-nothing. And of course, Kerberos trust is transitive... But the right way to handle regions under different administrative control is to place them in separate realms. For your example of students creating their own principals, independently from the centrally administered realm, you should be using a separate realm (and setup a cross-realm trust if that's appropriate.) That at least gives you consistent accountability, and you can uniformly limit the privileges granted to tickets from non-default realms. > Another, possibly more obvious case where (2) doesn't hold is in the > presence of cross-realm trust. If I can use DNS spoofing to return a > CNAME of ldap.stanford.edu to dorm-machine.mit.edu, and stanford.edu and > ATHENA.MIT.EDU have cross-realm trust, I can perform the same attack. So > you not only have to trust everyone who can create ldap principals in your > local realm, but everyone who can create ldap principals in any realm with > which you have cross-realm trust. Yes, and again, that is basic to the definition of Kerberos. If you don't actually trust everyone, then you should not be adding them into your KDC, because their presence in the KDC is a declaration of trust. Garbage-in-garbage-out applies here. > There are a lot of nasty things that you can do with DNS spoofing, and > this almost certainly isn't the most likely attack, but it is a potential > vulnerability that's been widely discussed within the Kerberos community, > including transition plans for how to get away from always doing > canonicalization. You can, for example, see part of the opinion of the > MIT developers in the comments around the relevant segment of code: > > if (maybe_use_reverse_dns(context, DEFAULT_RDNS_LOOKUP)) { > /* > * Do a reverse resolution to get the full name, just in > * case there's some funny business going on. If there > * isn't an in-addr record, give up. > */ > /* XXX: This is *so* bogus. There are several cases where > this won't get us the canonical name of the host, but > this is what we've trained people to expect. We'll > probably fix it at some point, but let's try to > preserve the current behavior and only shake things up > once when it comes time to fix this lossage. */ > > This is the reason why there's an rdns option in krb5.conf to disable this > code. There has been other discussion of it on krbdev and > kerberos@mit.edu in the past. > > I would agree that there's no way that you can change the default; too > much stuff would break. That's also why the Kerberos libraries continue > to do this by default. But I think the original bug reporter isn't > unreasonable for wanting a way to disable canonicalization if they know > that their code and environment will handle that appropriately. You've already proven that the option being discussed here is *not appropriate* because a non-local KDC cannot be trusted. So once again, solve the real problem. What's been proposed here is not a solution. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard Chu <hyc@symas.com> writes: > Leaving aside your followup which clarified this clause: the obvious > point is that a Kerberos client needs to have trusted *local* data to > protect against this attack. All Kerberos clients have trusted local data. It's required by the Kerberos protocol; the server gives you a TGT that you can only decrypt using your trusted local data. So I'm not sure what you're getting at here. The problem with DNS canonicalization is that it allows you to attack clients even if those clients have trusted local data to establish mutual authentication with the KDC. > Delegating administration authority still implies that you trust whoever > you delegated it to. Again, if you can't trust everyone then your > administrative procedures are broken and your framework has already been > compromised. Yes, it implies that you trust them to take the actions that you delegated to them. However, it *doesn't* imply that you trust them universally. You can delegate control of some principals and not others. That's a meaningful operation that is entirely valid within the Kerberos protocol trust model. Control of one principal in a realm should not imply an ability to spoof authentications to other principals in the same realm. Kerberos as a protocol can and is designed to be robust against attackers who have control over principals within your local realm provided that a client and a server agree on principal naming for a service. Kerberos clients are specifically cautioned in the Kerberos protocol specification against using insecure DNS to establish that agreement naming. Section 1.3 of RFC 4120, particularly the two paragraphs starting with: Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names (i.e., they MUST NOT use insecure DNS queries to map one name to another to determine the host part of the principal name with which one is to communicate). and the security considerations section of RFC 4752, namely: When constructing the input_name_string, the client SHOULD NOT canonicalize the server's fully qualified domain name using an insecure or untrusted directory service. are relevant here. The delegated administrative model that I describe is in widespread use; in fact, I don't know of any of my colleagues who *don't* do something similar to that. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
geert@boskant.nl wrote: > Full_Name: Geert Jansen > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/geert-jansen-081115.patch > Submission from: (NULL) (12.230.186.195) > > > This is a resubmission of my earlier patch in [1]. I'm asking for this patch to > be included into OpenLDAP. > > The patch adds an LDAP option called LDAP_OPT_X_SASL_NOCANON to disable host > name canonicalization using reverse DNS for the host name that is passed into > SASL. Instead, it passes verbatim the host name part from the LDAP URI and lets > SASL do the canonicalization. The option is disabled by default. > Since some time MIT Kerberos has support for server-side canonicalization which > is an alternative for the DNS based scheme. By default it uses both, but with an > option "rdns = no", reverse DNS can be disabled. > > The use case for this is environments that do not have reverse DNS set up > correctly. Especially in Windows Active Directory environments this is very > common. Administrators are afraid to enable scavenging for their zones, and > therefore any server IP change will leave a stale PTR record in place. This > breaks reverse DNS based canonicalization if the IP adress is reassigned. > > The behaviour enabled by this patch should remain optional and cannot become the > default. It breaks the use case when multiple LDAP servers are load balanced > using a CNAME record. In reviewing this patch, I see some technical issues to resolve: 1) You seem to be making the ldap_set_option "arg" parameter optional; there appears to be no justification for this (significant) behavioral change. 2) If you're dealing with a KDC that supports this feature, then it would make the most sense for this to be a site-wide option. As such, it should be possible for the setting to become the default, and an ldap.conf keyword should exist to control that setting. 3) Your addition of the option to the command line tools is boolean; if the command line option is present the option will be turned on, otherwise it will be turned off. This requires too much knowledge on the part of the user running the tool, to decide whether they need the option or not. Again, it should allow a system-wide setting, and the command-line option should be tri-state: on / off / default. Users should not be required to learn about this option before using the commandline tools, the sysadmin should set it site-wide when the KDC is known to support it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
My apologies for completely failing reading comprehension and including so much material that had already been mentioned in this ITS. I hadn't realized until I reviewed the whole ITS log just how much I'd duplicated of what people had already said. :/ -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
rra@stanford.edu wrote: > Howard Chu<hyc@symas.com> writes: > >> Leaving aside your followup which clarified this clause: the obvious >> point is that a Kerberos client needs to have trusted *local* data to >> protect against this attack. > > All Kerberos clients have trusted local data. It's required by the > Kerberos protocol; the server gives you a TGT that you can only decrypt > using your trusted local data. So I'm not sure what you're getting at > here. The problem with DNS canonicalization is that it allows you to > attack clients even if those clients have trusted local data to establish > mutual authentication with the KDC. This is going way beyond off topic but... The real problem is that the standard POSIX gethost/getaddr* APIs don't tell you the confidence level of the information they return. Nor do they let you specify a minimum acceptable confidence level when you make a query. (Analogous to the SSFs we use in OpenLDAP.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard Chu <hyc@symas.com> writes: > The real problem is that the standard POSIX gethost/getaddr* APIs don't > tell you the confidence level of the information they return. Nor do > they let you specify a minimum acceptable confidence level when you make > a query. (Analogous to the SSFs we use in OpenLDAP.) Yeah, that would be great. There are, unfortunately, a bunch of problems with those interfaces. Blocking behavior is another problem with them. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
changed notes changed state Open to Test moved from Incoming to Software Enhancements
moved from Software Enhancements to Development
changed notes changed state Test to Release
changed notes changed state Release to Closed
alternate patch in HEAD alternate patch in RE24