How to disable DNS lookups?

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: How to disable DNS lookups?

Thor Lancelot Simon-2
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
Reply | Threaded
Open this post in threaded view
|

Re: How to disable DNS lookups?

Henry B Hotz
In reply to this post by Roland C. Dowdeswell-2

> On Jul 25, 2017, at 6:30 PM, Roland C. Dowdeswell <[hidden email]> 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/AAAA records.

Personal email.  [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: How to disable DNS lookups?

Henry B Hotz
In reply to this post by u-hd-phes

> On Jul 26, 2017, at 10:29 AM, [hidden email] wrote:
>
> On Wed, Jul 26, 2017 at 08:45:17AM -0700, Russ Allbery wrote:
>> Viktor Dukhovni <[hidden email]> 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/AAAA record, therefore no search list will be exercised. <pun>period!</pun> The first lookup must succeed, by design.

Personal email.  [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: How to disable DNS lookups?

Henry B Hotz
In reply to this post by Thor Lancelot Simon-2
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 <[hidden email]> 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.  [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: How to disable DNS lookups?

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/AAAA 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. <pun>period!</pun> 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.
Reply | Threaded
Open this post in threaded view
|

Re: How to disable DNS lookups?

Henry B Hotz

> On Jul 26, 2017, at 4:12 PM, Viktor Dukhovni <[hidden email]> wrote:
>
>> The RR is guaranteed to return a name which has an A/AAAA 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 robust to 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.  [hidden email]



12