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
13 matches
Mail list logo
