Re: How to disable DNS lookups?

2017-07-27 Thread Henry B (Hank) Hotz, CISSP

> On Jul 26, 2017, at 4:12 PM, Viktor Dukhovni  
> wrote:
> 
>> The RR is guaranteed to return a name which has an A/ record.
> 
> It is not.  SRV RRs can and sometimes do reference names that don't exist.
> Ditto with MX records, ...  Even when the name exists a lookup can
> time out.

Per RFC 2782:

   Target
The domain name of the target host.  There MUST be one or more
address records for this name, the name MUST NOT be an alias (in
the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
not required, to return the address record(s) in the Additional
Data section.  Unless and until permitted by future standards
action, name compression is not to be used for this field.

My interpretation of this matches what I said. Nit picking aside, obviously 
Heimdal should be robustto incorrect DNS configuration where possible. 
However, if it winds up having to do a search because DNS is incorrectly 
configured, that strikes me as better than failing outright.

I guess I’m back to not understanding what the problem is. If the SRV RR is 
right, then it’s moot. If the record is wrong, then we’re off the reservation 
and it’s just a question of whether there is anything plausible we can do that 
will address the most likely failures.

Personal email.  hbh...@oxy.edu





Re: How to disable DNS lookups?

2017-07-26 Thread Viktor Dukhovni
On Wed, Jul 26, 2017 at 03:08:30PM -0700, Henry B (Hank) Hotz, CISSP wrote:

> > Then the explicit trailing dots in /etc/hosts look indeed
> > like a reasonable trade-off.
> 
> Actually, isn’t the trailing dot just a red herring?

No.

> The RR is guaranteed to return a name which has an A/ record.

It is not.  SRV RRs can and sometimes do reference names that don't exist.
Ditto with MX records, ...  Even when the name exists a lookup can
time out.

> therefore no search list will be exercised. period! The first
> lookup must succeed, by design.

Whether the first lookup is absolute or uses the search list depends on
"ndots" (which Heimdal does not control and has no knowledge of), and
in any case that lookup can fail.

-- 
Viktor.


Re: How to disable DNS lookups?

2017-07-26 Thread Henry B (Hank) Hotz, CISSP
I disagree. 

While you are technically correct, in my experience most SAs know very well 
what services are provided and where, but don’t know enough about DNS to know 
what a RR is. For that level of knowledge, having /etc/hosts take precedence is 
exactly the “least surprise” behavior.

> On Jul 26, 2017, at 11:25 AM, Thor Lancelot Simon  wrote:
> 
> On Wed, Jul 26, 2017 at 08:45:17AM -0700, Russ Allbery wrote:
>> 
>> Right, the point is not that you can't override with /etc/krb5.conf, the
>> point is that /etc/hosts normally overrides everything without having to
>> hunt down software-specific configuration files.
> 
> But in this case /etc/hosts clearly *can't* "override everything".  It
> cannot override the SRV records that are used to find the KDC via DNS,
> because there is no syntax to express a SRV record in /etc/hosts; and
> because of that, it is *a priori impossible* to know what hostname
> you would have to "override" in /etc/hosts (were that supported) to
> redirect Kerberos queries for a given realm to a particular IP address.
> 
> You can't even know whether DNS is used to look up the KDC or not without
> looking at krb5.conf.
> 
> Despite the expectation which seems reasonable at first glance that
> /etc/hosts could correctly be used to override a KDC in this way, in
> fact it works only in a few special cases - the ones where DNS is
> in use to find the KDC via SRV record *and* you can be 100% certain
> that SRV record won't change.  Not so useful.
> 
> Rather than relying on this, if you want to hardcode your KDC address,
> far better to turn off DNS lookup of the KDC, use krb5.conf, and be
> entirely manual and predictable, instead of half-manual, half-predictable,
> and half...donkeyed.
> 
> Thor

Personal email.  hbh...@oxy.edu





Re: How to disable DNS lookups?

2017-07-26 Thread Henry B (Hank) Hotz, CISSP

> On Jul 26, 2017, at 10:29 AM, u-hd-p...@aetey.se wrote:
> 
> On Wed, Jul 26, 2017 at 08:45:17AM -0700, Russ Allbery wrote:
>> Viktor Dukhovni  writes:
>>> 2. Look up same name in DNS, return address(es) if found
>> 
>>> instead, in step 2, we may get undesirable, incorrect and/or costly
>>> interactions with the stub resolver's domain search list.  The name in
>>> the SRV record is an FQDN and MUST NOT be subject to RES_DEFNAMES or
>>> RES_DNSRCH.  The getaddrinfo(3) API provides no means to signal that a
>>> name should not be subjected to the DNS search list.
>> 
>> Ah!  Thank you.  That helps me understand the problem you're trying to
>> solve.
> 
> +1
> 
> Then the explicit trailing dots in /etc/hosts look indeed
> like a reasonable trade-off.
> 
> Rune

Actually, isn’t the trailing dot just a red herring?

The RR is guaranteed to return a name which has an A/ record, therefore no 
search list will be exercised. period! The first lookup must 
succeed, by design.

Personal email.  hbh...@oxy.edu





Re: How to disable DNS lookups?

2017-07-26 Thread Henry B (Hank) Hotz, CISSP

> On Jul 25, 2017, at 6:30 PM, Roland C. Dowdeswell 
>  wrote:
> 
> And there are no KDCs configured in /etc/krb5.conf for the realm that
> you are querying, you will use DNS SRV RRs.  And, we think that once you
> have retrieved hostnames from DNS SRV RRs that they should be looked up
> only in DNS and not subjected to search lists and the like.

I’ll grant that this is a level of detail which standards don’t address, and 
where consensus may legitimately be impossible. FWIW my opinion is that an SA 
responsible for deploying/testing a machine may know nothing about krb5 config 
files, but need to point at a different infrastructure. 

For the scenario you describe where RRs are necessary, the poor SA will be very 
surprised if his entries in /etc/hosts are ignored. He will be especially 
surprised if the OS has an nsswitch.conf and he has put hosts before DNS.  (I 
might even have run into a scenario like that on Solaris 9, but I never 
completely debugged it so I’m not sure.)



I assume you at least have code in there to sort the RR entries by 
priority/weight before using the optimistically-provided A/ records.

Personal email.  hbh...@oxy.edu





Re: How to disable DNS lookups?

2017-07-26 Thread Thor Lancelot Simon
On Wed, Jul 26, 2017 at 08:45:17AM -0700, Russ Allbery wrote:
> 
> Right, the point is not that you can't override with /etc/krb5.conf, the
> point is that /etc/hosts normally overrides everything without having to
> hunt down software-specific configuration files.

But in this case /etc/hosts clearly *can't* "override everything".  It
cannot override the SRV records that are used to find the KDC via DNS,
because there is no syntax to express a SRV record in /etc/hosts; and
because of that, it is *a priori impossible* to know what hostname
you would have to "override" in /etc/hosts (were that supported) to
redirect Kerberos queries for a given realm to a particular IP address.

You can't even know whether DNS is used to look up the KDC or not without
looking at krb5.conf.

Despite the expectation which seems reasonable at first glance that
/etc/hosts could correctly be used to override a KDC in this way, in
fact it works only in a few special cases - the ones where DNS is
in use to find the KDC via SRV record *and* you can be 100% certain
that SRV record won't change.  Not so useful.

Rather than relying on this, if you want to hardcode your KDC address,
far better to turn off DNS lookup of the KDC, use krb5.conf, and be
entirely manual and predictable, instead of half-manual, half-predictable,
and half...donkeyed.

Thor


Re: How to disable DNS lookups?

2017-07-26 Thread u-hd-phes
On Wed, Jul 26, 2017 at 08:45:17AM -0700, Russ Allbery wrote:
> Viktor Dukhovni  writes:
> > 2. Look up same name in DNS, return address(es) if found
> 
> > instead, in step 2, we may get undesirable, incorrect and/or costly
> > interactions with the stub resolver's domain search list.  The name in
> > the SRV record is an FQDN and MUST NOT be subject to RES_DEFNAMES or
> > RES_DNSRCH.  The getaddrinfo(3) API provides no means to signal that a
> > name should not be subjected to the DNS search list.
> 
> Ah!  Thank you.  That helps me understand the problem you're trying to
> solve.

+1

Then the explicit trailing dots in /etc/hosts look indeed
like a reasonable trade-off.

Rune



Re: How to disable DNS lookups?

2017-07-26 Thread Russ Allbery
Viktor Dukhovni  writes:

> The problem is that we don't get:

>   1. Look up name from SRV in /etc/hosts, return address(es) if found
>   2. Look up same name in DNS, return address(es) if found

> instead, in step 2, we may get undesirable, incorrect and/or costly
> interactions with the stub resolver's domain search list.  The name in
> the SRV record is an FQDN and MUST NOT be subject to RES_DEFNAMES or
> RES_DNSRCH.  The getaddrinfo(3) API provides no means to signal that a
> name should not be subjected to the DNS search list.

Ah!  Thank you.  That helps me understand the problem you're trying to
solve.

How often does this actually come up, though?  My understanding of how
domain search works is that the record returned by the SRV record would
have to not exist *and* some record formed by appending the local domain
to the name would have to exist.  That seems *extremely* unlikely,
although I guess the latter could match local wildcard entries if someone
was doing something weird.

> Furthermore, if a domain's KDC list is not locally administered, and
> you're delegating the KDC names to remotely administered DNS, local
> overrides of the address resolution are no less costly than just putting
> override kdcs in the [realms] section.  Indeed the latter is much less
> fragile.

Right, the point is not that you can't override with /etc/krb5.conf, the
point is that /etc/hosts normally overrides everything without having to
hunt down software-specific configuration files.

-- 
Russ Allbery (ea...@eyrie.org)  


Re: How to disable DNS lookups?

2017-07-26 Thread Viktor Dukhovni

> On Jul 26, 2017, at 5:37 AM, u-hd-p...@aetey.se wrote:
> 
> As Russ already pointed out, the DNS standard is not an authority
> which defines the behaviour of the applicable APIs. Of course widely used
> implementations may create "de-facto standards" but this discussion shows
> that there is no apparent consensus about how name lookup is supposed
> to happen.

The problem is that we don't get:

1. Look up name from SRV in /etc/hosts, return address(es) if found
2. Look up same name in DNS, return address(es) if found

instead, in step 2, we may get undesirable, incorrect and/or costly
interactions with the stub resolver's domain search list.  The name
in the SRV record is an FQDN and MUST NOT be subject to RES_DEFNAMES
or RES_DNSRCH.  The getaddrinfo(3) API provides no means to signal
that a name should not be subjected to the DNS search list.

Furthermore, if a domain's KDC list is not locally administered, and
you're delegating the KDC names to remotely administered DNS, local
overrides of the address resolution are no less costly than just
putting override kdcs in the [realms] section.  Indeed the latter
is much less fragile.

Heimdal should be optimized for correct and reliable operation in normal
use first, and debugging hooks second.  Thus I plan to partly revert the
changes in the "master" branch to ensure that names that are obtained
from SRV records are resolved without search list suffixes, by appending
"." in the getaddrinfo(3) hostname argument for such names.  This will
match the behaviour of the MIT implementation.

-- 
Viktor.



Re: How to disable DNS lookups?

2017-07-26 Thread u-hd-phes
On Tue, Jul 25, 2017 at 09:48:11PM -0400, Roland C. Dowdeswell wrote:
> On Tue, Jul 25, 2017 at 11:20:57PM +0200, u-hd-p...@aetey.se wrote:
> > > As you can see, getaddrinfo(3) will only use DNS to chase the CNAME
> > > defined in DNS and does not consult /etc/hosts in the middle of a
> > 
> > You refer to a certain implementation which is not a specification
> > by itself. What do the applicable standards say?
> 
> Since we are discussing our processing of SRVs rather than CNAMEs, I'll
> limit my conversation to the relevant stanards for SRVs.

As Russ already pointed out, the DNS standard is not an authority
which defines the behaviour of the applicable APIs. Of course widely used
implementations may create "de-facto standards" but this discussion shows
that there is no apparent consensus about how name lookup is supposed
to happen.

So unless we find a relevant standard reference saying otherwise,
the least surprise approach should reflect the practice of treating
/etc/hosts as a part of service name resolution.

Note, it is "service names to endpoints resolution" which I mean,
irrespectively of which technologies (DNS/non-DNS) are being used
for the purpose and possibly behind the scenes.

Name-to-endpoint mapping data is traditionally spread across multiple
local and more or less global databases like /etc/hosts, /etc/services,
various DNS servers and more.

Is there an API specification which says "if a lookup implies
multiple steps and begins against a certain database instance, then
all of the possibly needed additional lookups must use the same
database instance (or the same technology/protocol/implementation?)"?
I may be wrong but I doubt this.

Regards,
Rune



Re: How to disable DNS lookups?

2017-07-25 Thread Russ Allbery
Russ Allbery  writes:

> My mental model of how an implementation that uses SRV records works is
> that it does a SRV query to find the list of hosts and weights, and then,
> for each host in weight order, does a gethostinfo(3) call on that
> hostname.

Apologies, that of course was supposed to be getnameinfo(3).

-- 
Russ Allbery (ea...@eyrie.org)  


Re: How to disable DNS lookups?

2017-07-25 Thread Roland C. Dowdeswell
On Tue, Jul 25, 2017 at 11:20:57PM +0200, u-hd-p...@aetey.se wrote:
>

> Given that SRV records as a matter of fact are defined via A[AAA] records,
> (and given that A lookups historically _are_ interposed by /etc/hosts)
> what says that /etc/hosts are to be ignored if an A lookup happens as
> a consequence of an SRV one?

Actually, I do not think that A lookups historically are interposed by
/etc/hosts.

I think that it is more accurate to say that historically there have been
functions called gethostbyname(3) and getaddrinfo(3) which mediated by
the definitions in /etc/nsswitch.conf choose whether to do files, DNS,
LDAP, YP, etc.  In all of the implementations that I've seen, once you
call into one of those modules, it will either return an entire answer
back up or fail which allows the NSS framework to pass control to the
next module.  In some cases, mostly with YP there are ways to mix the
modules a bit but those are mostly used for the passwd and group maps
rather than the host map.

-- 
Roland C. Dowdeswell


Re: How to disable DNS lookups?

2017-07-25 Thread Russ Allbery
"Roland C. Dowdeswell"  writes:

> Note that it states "the domain name of the target host".  /etc/hosts
> doesn't contain domain names but rather host names.

The "hostname" in /etc/hosts can contain periods, and it functions like an
FQDN in practice.

> It also urges implementors to return the address records in the
> Additional Data section.  This implies, I think, the addresses are to be
> obtained by the implementor probably on the domain name server.

My understanding is that Additional Data is a performance optimization in
DNS that allows a cache to make fewer queries by anticipating some of the
questions it's likely to ask next and letting it pre-cache that data.
This information is not used by clients under normal circumstances (dig is
not a normal client); in fact, some quick searching seems to indicate that
it's often not even exposed by DNS libraries.  It's used by the cache to
answer subsequent queries (or not if you don't bother to make them).

Anyway, I think the standard question is a red herring.  You cannot look
at DNS standards to figure out whether /etc/hosts should override, because
of course /etc/hosts isn't mentioned in DNS standards because it's not
part of DNS.

I think this is pretty clearly implementation-defined.  Nothing in any
standard is going to tell you that you MUST connect to an address
specified in an A or  record or you're not doing Kerberos; that's not
how standards work.  They're going to tell you that, for interop with a
site specifying Kerberos KDCs in DNS, this is the IP that the SRV record
points to and that you should connect to if you want to honor their DNS
records, which is fine; that's not what we're discussing.  What we're
discussing is whether to maintain what has become a valuable UNIX
*debugging and override* tool, which of course isn't in the scope of a
Kerberos or DNS standard for the same reason that LD_PRELOAD isn't in the
scope of a Kerberos or DNS standard.

I do see the point that people can override their /etc/krb5.conf instead,
and now that I know about this I suspect I will be able to make my systems
do the right thing, but /etc/hosts is convenient because it overrides *all
software* (as opposed to making you go hunt down some specific config file
for each piece of software).  I think not honoring it would be
unpleasantly surprising.

-- 
Russ Allbery (ea...@eyrie.org)  


Re: How to disable DNS lookups?

2017-07-25 Thread Roland C. Dowdeswell
On Tue, Jul 25, 2017 at 11:20:57PM +0200, u-hd-p...@aetey.se wrote:
>

> > As you can see, getaddrinfo(3) will only use DNS to chase the CNAME
> > defined in DNS and does not consult /etc/hosts in the middle of a
> 
> You refer to a certain implementation which is not a specification
> by itself. What do the applicable standards say?

Since we are discussing our processing of SRVs rather than CNAMEs, I'll
limit my conversation to the relevant stanards for SRVs.

>From RFC2782[1] page 4, the target of a SRV RR:

   Target
The domain name of the target host.  There MUST be one or more
address records for this name, the name MUST NOT be an alias (in
the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
not required, to return the address record(s) in the Additional
Data section.  Unless and until permitted by future standards
action, name compression is not to be used for this field.

A Target of "." means that the service is decidedly not
available at this domain.

Note that it states "the domain name of the target host".  /etc/hosts
doesn't contain domain names but rather host names.  It also urges
implementors to return the address records in the Additional Data section.
This implies, I think, the addresses are to be obtained by the implementor
probably on the domain name server.

Later in RFC2782, on page 6 (according to the below URL), there is
a section entitled "Usage rules" which again clearly states that a
SRV-cognisant client SHOULD use a procedure which includes querying DNS
for the results of the SRV RR targets:

For each element in the new list

query the DNS for address records for the Target or
use any such records found in the Additional Data
section of the earlier SRV response.

Later in the "Notes:" section, the RFC states:

   - If the Additional Data section doesn't contain address records
 for all the SRV RR's and the client may want to connect to the
 target host(s) involved, the client MUST look up the address
 record(s).  (This happens quite often when the address record
 has shorter TTL than the SRV or NS RR's.)

An "address record" in the context of an RFC about DNS is clearly a DNS
A or  RR and not an entry in /etc/hosts.
 
[1] https://tools.ietf.org/html/rfc2782

-- 
Roland C. Dowdeswell


Re: How to disable DNS lookups?

2017-07-25 Thread Roland C. Dowdeswell
On Tue, Jul 25, 2017 at 06:14:36PM -0700, Henry B (Hank) Hotz, CISSP wrote:
>

> I???m with Russ on this one, too. I???ve done /etc/hosts based
> deployments for robustness against DNS-failure scenarios.
> 
> POXIX getaddrinfo() does not require DNS. It???s an interface to
> the system and whatever it uses. The system should be configurable to
> use whatever name resolution is appropriate with as little surprise
> as possible.

I use /etc/hosts based deployments as well and note that there are many
advantages.  We are not suggesting that we break this.  If you specify
hosts in /etc/krb5.conf, then we will continue to use getaddrinfo(3)
to look them up.  In fact, we have recently fixed this because Heimdal
used to unconditionally add a trailing dot to kdc names which makes
using /etc/hosts difficult unless you know this [undocumented] piece
of information.

But, if you specify:

[libdefaults]
dns_lookup_kdc = true

And there are no KDCs configured in /etc/krb5.conf for the realm that
you are querying, you will use DNS SRV RRs.  And, we think that once you
have retrieved hostnames from DNS SRV RRs that they should be looked up
only in DNS and not subjected to search lists and the like.

-- 
Roland C. Dowdeswell


Re: How to disable DNS lookups?

2017-07-25 Thread Henry B (Hank) Hotz, CISSP
I’m with Russ on this one, too. I’ve done /etc/hosts based deployments for 
robustness against DNS-failure scenarios.

POXIX getaddrinfo() does not require DNS. It’s an interface to the system and 
whatever it uses. The system should be configurable to use whatever name 
resolution is appropriate with as little surprise as possible.

> On Jul 25, 2017, at 11:58 AM, Roland C. Dowdeswell 
>  wrote:
> 
> On Tue, Jul 25, 2017 at 08:45:44AM -0700, Russ Allbery wrote:
>> "Roland C. Dowdeswell"  writes:
>> 
>>> In the longer term, we should likely stop using getaddrinfo(3) for names
>>> obtained from DNS SRV RRs and directly query DNS for them as this matches
>>> expectations.  That is: you wouldn't expect that if you find
>> 
>>> _kerberos._udp.my.realm IN SRV 0 0 88 foo.my.realm
>> 
>>> that an entry for foo.my.realm in /etc/hosts would then override the
>>> DNS for it.
>> 
>> Eh?  I *absolutely* would expect that and would consider it a bug if it
>> did not.  It is incredibly useful for testing to be able to temporarily
>> override the IP address of a host in /etc/hosts, and I expect all software
>> to honor that.
> 
> SRV RRs are essentially a generalisation of CNAMEs or perhaps MX records.
> It is counter-intuitive to expect that /etc/hosts will interpose in the
> middle of a lookup.

. . .


Personal email.  hbh...@oxy.edu





Re: How to disable DNS lookups?

2017-07-25 Thread Russ Allbery
u-hd-p...@aetey.se writes:
> On Tue, Jul 25, 2017 at 02:58:29PM -0400, Roland C. Dowdeswell wrote:

>> It is counter-intuitive to expect that /etc/hosts will interpose in the
>> middle of a lookup.

> I second Russ and do not agree with you on this point.

> Given that SRV records as a matter of fact are defined via A[AAA]
> records, (and given that A lookups historically _are_ interposed by
> /etc/hosts) what says that /etc/hosts are to be ignored if an A lookup
> happens as a consequence of an SRV one?

Yup, agreed.  I'm unconvinced by the argument that this is confusing.

My mental model of how an implementation that uses SRV records works is
that it does a SRV query to find the list of hosts and weights, and then,
for each host in weight order, does a gethostinfo(3) call on that
hostname.  This will, in fact, interpose /etc/hosts with a standard
nsswitch configuration.  Now, perhaps my mental model is wrong for a given
implementation, but (a) the resulting behavior is very useful for testing
and something I've used for years, and (b) it's not an *unreasonable*
mental model, or particularly confusing.

-- 
Russ Allbery (ea...@eyrie.org)  


Re: How to disable DNS lookups?

2017-07-25 Thread Heikki Lindholm

On 25.07.2017 17:00, Roland C. Dowdeswell wrote:

On Tue, Jul 25, 2017 at 09:47:18AM +0300, Heikki Lindholm wrote:





On 24.07.2017 19:40, Roland C. Dowdeswell wrote:

On Sun, Jul 23, 2017 at 08:23:52AM +0300, Heikki Lindholm wrote:





The Heimdal version identifies itself as 1.5.2. The main problem is that
Heimdal doesn't appear to use /etc/hosts for looking up the KDC's IP
address, but goes to DNS, and fails.


1.5.2 is quite old and, IIRC, I've seen this before.  You can work
around it by adding the kdc name with a dot at the end as an alias in
the hosts file.


Thank you very much. That trick did it. It's weird, though. I would have
likely never arrived at the same solution by myself.


It's a work-around in the Heimdal code which appends a trailing dot to
hostnames when looking them up to avoid the DNS search path specified
in /etc/resolv.conf.  Viktor and I discussed relaxing this yesterday
because we believe that it is counter-intuitive.  It certainly confused
me, but I worked it out by reading the code rather than the documentation.
The approach that we think will work in the short term is to append the
trailing dot iff the hostname came from DNS SRV RRs as they should not
honour the DNS search path.  The existing behaviour will be able to be
replicated by those who are using /etc/krb5.conf by appending their own
trailing dot to the configured names.

In the longer term, we should likely stop using getaddrinfo(3) for names
obtained from DNS SRV RRs and directly query DNS for them as this matches
expectations.  That is: you wouldn't expect that if you find


Isn't nsswitch.conf there to let the user specify which lookup to prefer 
for getaddrinfo() and others?


MIT krb5's behaviour at least was exactly what I expected, i.e. if 
there's a "kdc = kdc.foo.bar" in krb5.conf, kinit does the same kind of 
lookup as "ping kdc.foo.bar" does (= in my case takes it from /etc/hosts 
without DNS involvement).


Re: How to disable DNS lookups?

2017-07-25 Thread Russ Allbery
"Roland C. Dowdeswell"  writes:

> In the longer term, we should likely stop using getaddrinfo(3) for names
> obtained from DNS SRV RRs and directly query DNS for them as this matches
> expectations.  That is: you wouldn't expect that if you find

> _kerberos._udp.my.realm   IN SRV 0 0 88 foo.my.realm

> that an entry for foo.my.realm in /etc/hosts would then override the
> DNS for it.

Eh?  I *absolutely* would expect that and would consider it a bug if it
did not.  It is incredibly useful for testing to be able to temporarily
override the IP address of a host in /etc/hosts, and I expect all software
to honor that.

-- 
Russ Allbery (ea...@eyrie.org)  


Re: How to disable DNS lookups?

2017-07-25 Thread Roland C. Dowdeswell
On Tue, Jul 25, 2017 at 09:47:18AM +0300, Heikki Lindholm wrote:
>

> On 24.07.2017 19:40, Roland C. Dowdeswell wrote:
> >On Sun, Jul 23, 2017 at 08:23:52AM +0300, Heikki Lindholm wrote:
> >>
> >
> >>The Heimdal version identifies itself as 1.5.2. The main problem is that
> >>Heimdal doesn't appear to use /etc/hosts for looking up the KDC's IP
> >>address, but goes to DNS, and fails.
> >
> >1.5.2 is quite old and, IIRC, I've seen this before.  You can work
> >around it by adding the kdc name with a dot at the end as an alias in
> >the hosts file.
> 
> Thank you very much. That trick did it. It's weird, though. I would have
> likely never arrived at the same solution by myself.

It's a work-around in the Heimdal code which appends a trailing dot to
hostnames when looking them up to avoid the DNS search path specified
in /etc/resolv.conf.  Viktor and I discussed relaxing this yesterday
because we believe that it is counter-intuitive.  It certainly confused
me, but I worked it out by reading the code rather than the documentation.
The approach that we think will work in the short term is to append the
trailing dot iff the hostname came from DNS SRV RRs as they should not
honour the DNS search path.  The existing behaviour will be able to be
replicated by those who are using /etc/krb5.conf by appending their own
trailing dot to the configured names.

In the longer term, we should likely stop using getaddrinfo(3) for names
obtained from DNS SRV RRs and directly query DNS for them as this matches
expectations.  That is: you wouldn't expect that if you find

_kerberos._udp.my.realm IN SRV 0 0 88 foo.my.realm

that an entry for foo.my.realm in /etc/hosts would then override the
DNS for it.

-- 
Roland C. Dowdeswell


Re: How to disable DNS lookups?

2017-07-25 Thread Benjamin Kaduk
On Tue, Jul 25, 2017 at 09:47:18AM +0300, Heikki Lindholm wrote:
> 
> Thank you very much. That trick did it. It's weird, though. I would have 
> likely never arrived at the same solution by myself.

I'll second the thanks, as I've run into this same issue many times
(and usually ended up just reverting to MIT kerberos, which I know better).

> FreeBSD appears unwilling to update the base system heimdal as it has 
> been the same for several releases already. I have no idea why.

It is relatively recent that there was a newer actual heimdal release 
that FreeBSD could even consider upgrading to.  Given how importing
a development snapshot worked for Debian, I don't blame FreeBSD for
choosing to wait for official releases.

There is some effort underway to modernize the Kerberos offerings for
FreeBSD, though there is not much concrete to show for it, yet.

-Ben


Re: How to disable DNS lookups?

2017-07-25 Thread Heikki Lindholm

On 24.07.2017 19:40, Roland C. Dowdeswell wrote:

On Sun, Jul 23, 2017 at 08:23:52AM +0300, Heikki Lindholm wrote:





The Heimdal version identifies itself as 1.5.2. The main problem is that
Heimdal doesn't appear to use /etc/hosts for looking up the KDC's IP
address, but goes to DNS, and fails.


1.5.2 is quite old and, IIRC, I've seen this before.  You can work
around it by adding the kdc name with a dot at the end as an alias in
the hosts file.


Thank you very much. That trick did it. It's weird, though. I would have 
likely never arrived at the same solution by myself.


FreeBSD appears unwilling to update the base system heimdal as it has 
been the same for several releases already. I have no idea why.


Re: How to disable DNS lookups?

2017-07-24 Thread Roland C. Dowdeswell
On Sun, Jul 23, 2017 at 08:23:52AM +0300, Heikki Lindholm wrote:
>

> The Heimdal version identifies itself as 1.5.2. The main problem is that
> Heimdal doesn't appear to use /etc/hosts for looking up the KDC's IP
> address, but goes to DNS, and fails.

1.5.2 is quite old and, IIRC, I've seen this before.  You can work
around it by adding the kdc name with a dot at the end as an alias in
the hosts file.

So, if your kdc is kdc1.example.com, then your /etc/hosts line should
look like this:

1.2.3.4 kdc1.example.com kdc1.example.com. kdc1

or something quite like that.

-- 
Roland C. Dowdeswell