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