+ return sysctl_int(oldp, oldlenp, newp, newlen, &dnsjacking);
+int dnsjacking = 0;
+ sin.sin_port = htons(dnsjacking);
How about using u_int16_t or in_port_t; and maybe error out if high
bits are set rather than ignoring them but still displaying them.
Ted Unangst wrote:
> Ted Unangst wrote:
> > So the plan is for rebound to be the 'system' resolver, with libc talking to
> > rbeound and rebound talking to the cloud. The main wrinkle is how does
> > rebound
> > find the cloud? rebound.conf, but dhclient doesn't know anything about
> > rebound.con
On 2016-09-15, "Ted Unangst" wrote:
> Particular edge case: if resolv.conf has no nameservers, then the localhost
> default is not prepended. So libc won't try talking to rebound if it's
> specifically configured not to (chroot).
Huh? If resolv.conf has no nameservers, libc already falls back t
Theo de Raadt [dera...@openbsd.org] wrote:
> > That rebound acts like a nameserver is what prompted the idea to
> > hijack the resolver. But it's really a tool that takes over certain
> > duties from the libc resolver, so the libc resolver should be properly
> > configurable to hand over duties, or
Ted Unangst wrote:
> So the plan is for rebound to be the 'system' resolver, with libc talking to
> rbeound and rebound talking to the cloud. The main wrinkle is how does rebound
> find the cloud? rebound.conf, but dhclient doesn't know anything about
> rebound.conf, preferring to edit resolv.conf.
> That rebound acts like a nameserver is what prompted the idea to
> hijack the resolver. But it's really a tool that takes over certain
> duties from the libc resolver, so the libc resolver should be properly
> configurable to hand over duties, or not. 'search' is the logical
> place for this.
So
On Thu, 15 Sep 2016, Chris Cappuccio wrote:
> That rebound acts like a nameserver is what prompted the idea to
> hijack the resolver. But it's really a tool that takes over certain
> duties from the libc resolver, so the libc resolver should be properly
> configurable to hand over duties, or not.
Bryan Steele [bry...@gmail.com] wrote:
> On Thu, Sep 15, 2016 at 10:14:51AM -0400, Ted Unangst wrote:
> > Florian Obser wrote:
> > > Not everything listening on localhost port 53 is a recursive resolver.
> > > nsd(8) per defaults listens on 0.0.0.0 and will respond with REFUSED for
> > > almost eve
On 2016/09/15 06:23, Jiri B wrote:
> On Thu, Sep 15, 2016 at 10:04:00AM +0100, Stuart Henderson wrote:
> > > What about this:
> > >
> > > Add "rebound" as possible value to the lookup keyword in resolv.conf.
> > > If this is set the libc resolver sends dns requests to the unix socket
> > > /var/ru
On Thu, Sep 15, 2016 at 10:14:51AM -0400, Ted Unangst wrote:
> Florian Obser wrote:
> > Not everything listening on localhost port 53 is a recursive resolver.
> > nsd(8) per defaults listens on 0.0.0.0 and will respond with REFUSED for
> > almost every query. asr stops in that case and does not try
* Ted Unangst [2016-09-15 16:15]:
> The good news is I think we can still bind to
> localhost:53 if nsd is on *:53 (right?).
right.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS. Virtual & Dedicated Serve
Florian Obser wrote:
> Not everything listening on localhost port 53 is a recursive resolver.
> nsd(8) per defaults listens on 0.0.0.0 and will respond with REFUSED for
> almost every query. asr stops in that case and does not try the next
> resolver in the list.
Ah! There's the catch. The good ne
On Wed, Sep 14, 2016 at 09:19:07PM -0400, Ted Unangst wrote:
> So the plan is for rebound to be the 'system' resolver, with libc talking to
> rbeound and rebound talking to the cloud. The main wrinkle is how does rebound
> find the cloud? rebound.conf, but dhclient doesn't know anything about
> reb
On Thu, Sep 15, 2016 at 10:04:00AM +0100, Stuart Henderson wrote:
> On 2016/09/15 10:39, Remi Locherer wrote:
> > On Wed, Sep 14, 2016 at 08:10:29PM -0600, Theo de Raadt wrote:
> > > > > wont this also mean if it is not running i have to wait for the
> > > > > localhost
> > > > > attempt to fail b
On 2016/09/15 10:39, Remi Locherer wrote:
> On Wed, Sep 14, 2016 at 08:10:29PM -0600, Theo de Raadt wrote:
> > > > wont this also mean if it is not running i have to wait for the
> > > > localhost
> > > > attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc)
> > > > so i
> > > >
On Wed, Sep 14, 2016 at 08:10:29PM -0600, Theo de Raadt wrote:
> > > wont this also mean if it is not running i have to wait for the localhost
> > > attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so
> > > i
> > > slow everything down for a timeout?
> >
> > Not if he connec
On Wed, Sep 14, 2016 at 09:19:07PM -0400, Ted Unangst wrote:
> And so I present the following diff to enable a smooth transition. It's
> 'quantum' because it works whether or not rebound is running. No need to open
> the box.
I'm sure there's a cat(ch)...
--
Erling Westenvik
BTW I'm not picking on you.. my DNS setup blew up this week for local
resolution and I've been dealing with the fallout - so the topic
is relatively near and dear to my heart.
On Wed, Sep 14, 2016 at 10:07 PM, Bob Beck wrote:
>
> Yep. and now you need to solve the problem that when prepending
>
Yep. and now you need to solve the problem that when prepending 127.0.0.1,
and hitting rebound, which in turn is going to only grab the first dns
server from my resolv.conf instead of all of them, that it now doubles my
failure time when the first dns server doesn't respond (once for libc
asking r
Ted Unangst wrote:
> Bob Beck wrote:
> > how is rebound going to handle a change in resolv.conf? thats still a
> > problem here
>
> oh, that's easy. it watches the file for changes. i never quite got around to
> that, but it's another five lines.
ok, so it's a net +15 lines, including blanks.
In
Bob Beck wrote:
> wont this also mean if it is not running i have to wait for the localhost
> attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so i
> slow everything down for a timeout?
you get back unreachable and move on. it's fast. you can try it. :)
> > wont this also mean if it is not running i have to wait for the localhost
> > attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so i
> > slow everything down for a timeout?
>
> Not if he connects to the TCP port 53 instead of the UDP; it looks like
> rebound binds to both.
On Wed, 14 Sep 2016 20:00:32 -0600, Bob Beck wrote:
> wont this also mean if it is not running i have to wait for the localhost
> attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so i
> slow everything down for a timeout?
Not if he connects to the TCP port 53 instead of the
> wont this also mean if it is not running i have to wait for the localhost
> attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so i
> slow everything down for a timeout?
i think that is right.
ktrace would show what is going on.
if it stalls, this is not enough.
wont this also mean if it is not running i have to wait for the localhost
attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so i
slow everything down for a timeout?
dont get me wrong, it is an interesting direction, but I think maybe get
the rest of the five line changes into
Bob Beck wrote:
> how is rebound going to handle a change in resolv.conf? thats still a
> problem here
oh, that's easy. it watches the file for changes. i never quite got around to
that, but it's another five lines.
how is rebound going to handle a change in resolv.conf? thats still a
problem here
On Wednesday, 14 September 2016, Ted Unangst wrote:
> So the plan is for rebound to be the 'system' resolver, with libc talking
> to
> rbeound and rebound talking to the cloud. The main wrinkle is how does
> rebou
So the plan is for rebound to be the 'system' resolver, with libc talking to
rbeound and rebound talking to the cloud. The main wrinkle is how does rebound
find the cloud? rebound.conf, but dhclient doesn't know anything about
rebound.conf, preferring to edit resolv.conf. But if rebound reads
resol
28 matches
Mail list logo
