On Wed, Jul 29, 2020 at 05:42:16PM +0200, Florian Obser wrote:
> > First you mention fallback to DHCP-learned resolvers. Those you should
> > probably not trust indeed, but it looks like unwind(8) attempts to use
> > them to perform its own validation. So the value of the AD flag in
> >
On Wed, Jul 29 2020, Florian Obser wrote:
> On Wed, Jul 29, 2020 at 03:51:55PM +0200, Jeremie Courreges-Anglas wrote:
>> So I did a few tests and read some unwind(8) code, and it *appears* safe
>> to use unwind(8) along with "options trust-ad".
>
> Yes.
>
>>
>> First you mention fallback to
On Wed, Jul 29, 2020 at 03:51:55PM +0200, Jeremie Courreges-Anglas wrote:
> So I did a few tests and read some unwind(8) code, and it *appears* safe
> to use unwind(8) along with "options trust-ad".
Yes.
>
> First you mention fallback to DHCP-learned resolvers. Those you should
> probably not
Florian Obser wrote:
> On Wed, Jul 29, 2020 at 03:51:17PM +0200, Sebastian Benoit wrote:
> > If i remember correctly, the fallout was caused by EDNS but i might be
> > wrong. The unbound commit caused a developer some headscratching, because
> > his upstream internet did not work with such
On Wed, Jul 29, 2020 at 03:51:17PM +0200, Sebastian Benoit wrote:
> If i remember correctly, the fallout was caused by EDNS but i might be
> wrong. The unbound commit caused a developer some headscratching, because
> his upstream internet did not work with such packets, which led to immediate
>
Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2020.07.29 15:51:55 +0200:
> On Sun, Jul 26 2020, Jeremie Courreges-Anglas wrote:
> > On Sat, Jul 25 2020, Sebastian Benoit wrote:
>
> [...]
>
> >> If you enable trust-ad on a system that moves around, e.g. your laptop, you
> >> will experience
On Sun, Jul 26 2020, Jeremie Courreges-Anglas wrote:
> On Sat, Jul 25 2020, Sebastian Benoit wrote:
[...]
>> If you enable trust-ad on a system that moves around, e.g. your laptop, you
>> will experience failures, which is why unwind tests for this and falls back
>> to non-trusting dhcp
Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2020.07.26 22:52:47 +0200:
> On Sat, Jul 25 2020, Sebastian Benoit wrote:
> > Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2020.07.25 14:01:06 +0200:
> >> On Fri, Jul 17 2020, Jesper Wallin wrote:
> >> > Hi all,
> >> >
> >> > I recently decided to add
On Wed, Jul 29, 2020 at 02:46:06PM +0200, Jeremie Courreges-Anglas wrote:
> On Mon, Jul 27 2020, Jesper Wallin wrote:
>
> [...]
>
> > I still think the RES_USE_AD option might be a useful though, for when
> > you want to decide on an application-level whether to trust AD or not?
>
>
On Mon, Jul 27 2020, Jesper Wallin wrote:
[...]
> I still think the RES_USE_AD option might be a useful though, for when
> you want to decide on an application-level whether to trust AD or not?
RES_TRUSTAD can also be used for this, but as the proposed documentation
points out it would be
On Mon, Jul 27, 2020 at 03:30:52AM +0200, Jeremie Courreges-Anglas wrote:
> On Sun, Jul 26 2020, Jesper Wallin wrote:
> > On Sat, Jul 25, 2020 at 02:01:06PM +0200, Jeremie Courreges-Anglas wrote:
> >>
> >> For those two reasons I think the feature should be opt-in.
> >
> > Yeah, I agree with
On Sun, Jul 26 2020, Jesper Wallin wrote:
> On Sat, Jul 25, 2020 at 02:01:06PM +0200, Jeremie Courreges-Anglas wrote:
>>
>> For those two reasons I think the feature should be opt-in.
>
> Yeah, I agree with you. My first approach was to have it check what
> kind of DNS record that was
On Sat, Jul 25 2020, Sebastian Benoit wrote:
> Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2020.07.25 14:01:06 +0200:
>> On Fri, Jul 17 2020, Jesper Wallin wrote:
>> > Hi all,
>> >
>> > I recently decided to add SSHFP records for my servers, since I never
>> > memorize or write down my key
On Sat, Jul 25, 2020 at 02:01:06PM +0200, Jeremie Courreges-Anglas wrote:
>
> For those two reasons I think the feature should be opt-in.
Yeah, I agree with you. My first approach was to have it check what
kind of DNS record that was requested, and add the AD-flag only if type
was SSHFP, but
Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2020.07.25 14:01:06 +0200:
> On Fri, Jul 17 2020, Jesper Wallin wrote:
> > Hi all,
> >
> > I recently decided to add SSHFP records for my servers, since I never
> > memorize or write down my key fingerprints. I learned that if I
> > want ssh(1) to
On Fri, Jul 17 2020, Jesper Wallin wrote:
> Hi all,
>
> I recently decided to add SSHFP records for my servers, since I never
> memorize or write down my key fingerprints. I learned that if I
> want ssh(1) to trust these records, DNSSEC needs to be enabled for my
> zone. To validate these
On Fri, Jul 17, 2020 at 11:45:22PM +0200, Jesper Wallin wrote:
> Thoughts?
>
>
> Yours,
> Jesper Wallin
I found this very interesting. Too bad you didn't quote any RFC's that
support this behaviour because RFC 4033 says you shouldn't set the AD bit
in a query, RFC 4035 says something similar,
On Fri, 17 Jul 2020, Jeremy C. Reed wrote:
> > To get a response with the AD flag set, the request itself also needs
> > to have the AD flag set.
I re-read your post again and see you already clarified this.
On Fri, 17 Jul 2020, Jesper Wallin wrote:
> To get a response with the AD flag set, the request itself also needs
> to have the AD flag set.
...
> -#define RES_DEFAULT(RES_RECURSE | RES_DEFNAMES | RES_DNSRCH)
> +#define RES_DEFAULT(RES_RECURSE | RES_DEFNAMES | RES_DNSRCH | RES_USE_AD)
Hi all,
I recently decided to add SSHFP records for my servers, since I never
memorize or write down my key fingerprints. I learned that if I
want ssh(1) to trust these records, DNSSEC needs to be enabled for my
zone. To validate these records, ssh(1) is using getrrsetbyname(3),
which checks if
20 matches
Mail list logo
