Opportunistic DoT for unwind(8)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Opportunistic DoT for unwind(8)

Remi Locherer
On Fri, Nov 01, 2019 at 09:53:28PM +0100, Florian Obser wrote:

> On Fri, Nov 01, 2019 at 09:45:37PM +0100, Florian Obser wrote:
> > On Fri, Nov 01, 2019 at 09:35:07PM +0100, Remi Locherer wrote:
> > > On Thu, Oct 31, 2019 at 08:14:04PM +0100, Otto Moerbeek wrote:
> > > > Hi,
> > > >
> > > > So here's a new diff that incorporates the bug fix mentioned plus
> > > > debug printf line changes suggested by Stuart.
> > > >
> > > > Please note that this is a diff on top of very recent current, i.e.
> > > > florian's work he committed today. That means that you need to be
> > > > up-to-date (including a recent libc update that was committed a few
> > > > days ago) to be able to test this version.
> > >
> > > I upgraded to a snapshot from today, updated the source and applied
> > > your diff. Then I did the same test as last time using pf to block port 53
> > > (block return out log inet proto {tcp udp} to !9.9.9.9 port 53).
> > >
> > > Result: the non functional type asr is selected instead of the forwarder.
> > >
> > > $ doas unwindctl status
> > > captive portal is unknown
> > >
> > > selected             type status
> > >                  recursor dead
> > >                 forwarder validating (OppDoT)
> > >                      dhcp unknown (OppDoT)
> > >        *              asr dead
> > > $
> > > $ getent hosts undeadly.org
> > > $ echo $?
> > > 2
> > > $ dig +short undeadly.org @9.9.9.9
> > > 94.142.241.173
> > > $
> > >
> > > Without your patch unwind behaves similar regarding the type selection:
> > >
> > > $ doas unwindctl status
> > > captive portal is unknown
> >
> > ^ you are creating a not supported configuration.
> >
> > When we are behind a captive portal or don't know yet if we are behind
> > a captive portal resolving is forced to asr.
> >
> > That might not be very wise if asr is dead but I currently don't see
> > how this can happen in practice except with a well aimed foot-gun.
>
> Actually, I have an idea how this can happen in practice, please try this:
>
> diff --git resolver.c resolver.c
> index f59860a5e98..5bbc63f60fa 100644
> --- resolver.c
> +++ resolver.c
> @@ -1282,7 +1282,8 @@ best_resolver(void)
>  
>   if (captive_portal_state == PORTAL_UNKNOWN || captive_portal_state ==
>      BEHIND) {
> - if (resolvers[UW_RES_ASR] != NULL) {
> + if (resolvers[UW_RES_ASR] != NULL && resolvers[UW_RES_ASR]->
> +                    state != DEAD) {
>   res = resolvers[UW_RES_ASR];
>   goto out;
>   }
>
>

Yes, this makes unwind cope with this situation:

$ unwindctl status
not behind captive portal

selected             type status
                 recursor dead
       *        forwarder validating
                     dhcp dead
                      asr dead
$

OK remi@

Reply | Threaded
Open this post in threaded view
|

Re: Opportunistic DoT for unwind(8)

Otto Moerbeek
On Fri, Nov 01, 2019 at 10:43:27PM +0100, Remi Locherer wrote:

> On Fri, Nov 01, 2019 at 09:53:28PM +0100, Florian Obser wrote:
> > On Fri, Nov 01, 2019 at 09:45:37PM +0100, Florian Obser wrote:
> > > On Fri, Nov 01, 2019 at 09:35:07PM +0100, Remi Locherer wrote:
> > > > On Thu, Oct 31, 2019 at 08:14:04PM +0100, Otto Moerbeek wrote:
> > > > > Hi,
> > > > >
> > > > > So here's a new diff that incorporates the bug fix mentioned plus
> > > > > debug printf line changes suggested by Stuart.
> > > > >
> > > > > Please note that this is a diff on top of very recent current, i.e.
> > > > > florian's work he committed today. That means that you need to be
> > > > > up-to-date (including a recent libc update that was committed a few
> > > > > days ago) to be able to test this version.
> > > >
> > > > I upgraded to a snapshot from today, updated the source and applied
> > > > your diff. Then I did the same test as last time using pf to block port 53
> > > > (block return out log inet proto {tcp udp} to !9.9.9.9 port 53).
> > > >
> > > > Result: the non functional type asr is selected instead of the forwarder.
> > > >
> > > > $ doas unwindctl status
> > > > captive portal is unknown
> > > >
> > > > selected             type status
> > > >                  recursor dead
> > > >                 forwarder validating (OppDoT)
> > > >                      dhcp unknown (OppDoT)
> > > >        *              asr dead
> > > > $
> > > > $ getent hosts undeadly.org
> > > > $ echo $?
> > > > 2
> > > > $ dig +short undeadly.org @9.9.9.9
> > > > 94.142.241.173
> > > > $
> > > >
> > > > Without your patch unwind behaves similar regarding the type selection:
> > > >
> > > > $ doas unwindctl status
> > > > captive portal is unknown
> > >
> > > ^ you are creating a not supported configuration.
> > >
> > > When we are behind a captive portal or don't know yet if we are behind
> > > a captive portal resolving is forced to asr.
> > >
> > > That might not be very wise if asr is dead but I currently don't see
> > > how this can happen in practice except with a well aimed foot-gun.
> >
> > Actually, I have an idea how this can happen in practice, please try this:
> >
> > diff --git resolver.c resolver.c
> > index f59860a5e98..5bbc63f60fa 100644
> > --- resolver.c
> > +++ resolver.c
> > @@ -1282,7 +1282,8 @@ best_resolver(void)
> >  
> >   if (captive_portal_state == PORTAL_UNKNOWN || captive_portal_state ==
> >      BEHIND) {
> > - if (resolvers[UW_RES_ASR] != NULL) {
> > + if (resolvers[UW_RES_ASR] != NULL && resolvers[UW_RES_ASR]->
> > +                    state != DEAD) {
> >   res = resolvers[UW_RES_ASR];
> >   goto out;
> >   }
> >
> >
>
> Yes, this makes unwind cope with this situation:
>
> $ unwindctl status
> not behind captive portal
>
> selected             type status
>                  recursor dead
>        *        forwarder validating
>                      dhcp dead
>                       asr dead
> $
>
> OK remi@
>

And with my diff on top of that?

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: Opportunistic DoT for unwind(8)

Remi Locherer
On Sat, Nov 02, 2019 at 08:20:08AM +0100, Otto Moerbeek wrote:

> On Fri, Nov 01, 2019 at 10:43:27PM +0100, Remi Locherer wrote:
>
> > On Fri, Nov 01, 2019 at 09:53:28PM +0100, Florian Obser wrote:
> > > On Fri, Nov 01, 2019 at 09:45:37PM +0100, Florian Obser wrote:
> > > > On Fri, Nov 01, 2019 at 09:35:07PM +0100, Remi Locherer wrote:
> > > > > On Thu, Oct 31, 2019 at 08:14:04PM +0100, Otto Moerbeek wrote:
> > > > > > Hi,
> > > > > >
> > > > > > So here's a new diff that incorporates the bug fix mentioned plus
> > > > > > debug printf line changes suggested by Stuart.
> > > > > >
> > > > > > Please note that this is a diff on top of very recent current, i.e.
> > > > > > florian's work he committed today. That means that you need to be
> > > > > > up-to-date (including a recent libc update that was committed a few
> > > > > > days ago) to be able to test this version.
> > > > >
> > > > > I upgraded to a snapshot from today, updated the source and applied
> > > > > your diff. Then I did the same test as last time using pf to block port 53
> > > > > (block return out log inet proto {tcp udp} to !9.9.9.9 port 53).
> > > > >
> > > > > Result: the non functional type asr is selected instead of the forwarder.
> > > > >
> > > > > $ doas unwindctl status
> > > > > captive portal is unknown
> > > > >
> > > > > selected             type status
> > > > >                  recursor dead
> > > > >                 forwarder validating (OppDoT)
> > > > >                      dhcp unknown (OppDoT)
> > > > >        *              asr dead
> > > > > $
> > > > > $ getent hosts undeadly.org
> > > > > $ echo $?
> > > > > 2
> > > > > $ dig +short undeadly.org @9.9.9.9
> > > > > 94.142.241.173
> > > > > $
> > > > >
> > > > > Without your patch unwind behaves similar regarding the type selection:
> > > > >
> > > > > $ doas unwindctl status
> > > > > captive portal is unknown
> > > >
> > > > ^ you are creating a not supported configuration.
> > > >
> > > > When we are behind a captive portal or don't know yet if we are behind
> > > > a captive portal resolving is forced to asr.
> > > >
> > > > That might not be very wise if asr is dead but I currently don't see
> > > > how this can happen in practice except with a well aimed foot-gun.
> > >
> > > Actually, I have an idea how this can happen in practice, please try this:
> > >
> > > diff --git resolver.c resolver.c
> > > index f59860a5e98..5bbc63f60fa 100644
> > > --- resolver.c
> > > +++ resolver.c
> > > @@ -1282,7 +1282,8 @@ best_resolver(void)
> > >  
> > >   if (captive_portal_state == PORTAL_UNKNOWN || captive_portal_state ==
> > >      BEHIND) {
> > > - if (resolvers[UW_RES_ASR] != NULL) {
> > > + if (resolvers[UW_RES_ASR] != NULL && resolvers[UW_RES_ASR]->
> > > +                    state != DEAD) {
> > >   res = resolvers[UW_RES_ASR];
> > >   goto out;
> > >   }
> > >
> > >
> >
> > Yes, this makes unwind cope with this situation:
> >
> > $ unwindctl status
> > not behind captive portal
> >
> > selected             type status
> >                  recursor dead
> >        *        forwarder validating
> >                      dhcp dead
> >                       asr dead
> > $
> >
> > OK remi@
> >
>
> And with my diff on top of that?

Yes, now it works as expected.

OK remi@
 

12