> 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 RF
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/ rec
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
> 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
>>>
> 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 D
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 clea
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 nam
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
> 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
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
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
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 co
"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 ad
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. W
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
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 w
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 fa
On Tue, Jul 25, 2017 at 02:58:29PM -0400, Roland C. Dowdeswell wrote:
> On Tue, Jul 25, 2017 at 08:45:44AM -0700, Russ Allbery wrote:
> > 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
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 expe
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 p
"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.m
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
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 reve
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.
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
Hello list,
Out of laziness I'll just copy & paste an issue I sent to a freebsd ml
(without responses):
-
I'm trying to mount a kerberized NFSv4 share on FreeBSD 11. It's an
experimental setup without DNS; only /etc/hosts base
26 matches
Mail list logo
