> 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
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/
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
> 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,
> 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
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
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
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
>
> 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
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
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
"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
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.
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
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
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
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
"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
>
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
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
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
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
23 matches
Mail list logo