On Sat, Oct 30, 2010 at 07:26:00PM +0200, Peter J. Philipp wrote:
> I had a look at the pack.c file where the DNS compression is being handled.
> It looks good to me. But I have one concern that needs to be confirmed.
> In function dname_expand() on lines:
>
> 54 ptr
On Sat, Oct 30, 2010 at 05:28:42PM +0200, Gilles Chehade wrote:
> It was a typo indeed, tarball has been updated and also contains a fix for
> a crash experienced by todd@ when using "relay via"
>
> Gilles
I had a look at the pack.c file where the DNS compression is being handled.
It looks good t
On 10/30/10 17:23, Peter J. Philipp wrote:
On Sat, Oct 30, 2010 at 04:55:36PM +0200, Gilles Chehade wrote:
Hi tech@,
A new tarball with all reported issues fixed is available at:
http://www.poolp.org/~gilles/smtpd-asyncdns.tar.gz
smtpd now catches changes in /etc/resolv.conf and should
On Sat, Oct 30, 2010 at 04:55:36PM +0200, Gilles Chehade wrote:
> Hi tech@,
>
> A new tarball with all reported issues fixed is available at:
>
> http://www.poolp.org/~gilles/smtpd-asyncdns.tar.gz
>
> smtpd now catches changes in /etc/resolv.conf and should work fine with
> inet6 records.
>
On 10/15/10 10:50, Gilles Chehade wrote:
Hi tech@,
A new tarball has been uploaded yesterday, it contains the fixes eric@ wrote
for the issues reported on asr.
For now, only two issues have been reported on smtpd:
1- smtpd does not catch up changes to /etc/resolv.conf;
2- smtpd does not look
On Thu, 14 Oct 2010, Christian Weisgerber wrote:
> Ted Unangst wrote:
>
> > Why not use the evdns resolver in libevent?
>
> (1) It isn't part of the base system libevent.
> (2) It doesn't understand all of our resolv.conf(5) syntax and it
> can't talk to a nameserver over IPv6.
(3) it does
On Thu, Oct 14, 2010 at 04:47:26PM +0200, Gilles Chehade wrote:
> Dear tech@,
>
> eric@ has written an (awesome :p) asynchronous resolver that allows us to do
> non-blocking DNS lookups.
>
> As of today, smtpd implements non-blocking lookups through a fork+imsg hack,
> creating a socketpair() and
On Thu, Oct 14, 2010 at 03:20:06PM -0600, Theo de Raadt wrote:
> > On Thu, Oct 14, 2010 at 11:57 AM, Mike Belopuhov wrote:
> > > this dns code has a serious flaw. you use arc4random to allocate request
> > > IDs. this is a bad decision, as you actually want a non-repeating
> > property.
> >
> >
> On Thu, Oct 14, 2010 at 11:57 AM, Mike Belopuhov wrote:
> > this dns code has a serious flaw. you use arc4random to allocate request
> > IDs. this is a bad decision, as you actually want a non-repeating
> property.
>
> Why? Each query transmission uses a newly allocated socket with a
> uniqu
On Thu, Oct 14, 2010 at 11:57 AM, Mike Belopuhov wrote:
> this dns code has a serious flaw. you use arc4random to allocate request
> IDs. this is a bad decision, as you actually want a non-repeating
property.
Why? Each query transmission uses a newly allocated socket with a
unique (random) sou
On Thu, Oct 14, 2010 at 4:47 PM, Gilles Chehade wrote:
> Dear tech@,
>
> eric@ has written an (awesome :p) asynchronous resolver that allows us to do
> non-blocking DNS lookups.
>
this dns code has a serious flaw. you use arc4random to allocate request
IDs. this is a bad decision, as you actual
On Thu, Oct 14, 2010 at 04:47:26PM +0200, Gilles Chehade wrote:
> A tarball to test: http://www.poolp.org/~gilles/smtpd-asyncdns.tar.gz
>
> This is smtpd-current, queue is unchanged, please test as it is experimental
> code. I will run it for a few days and commit if I see no drawbacks and I do
>
Ted Unangst wrote:
> Why not use the evdns resolver in libevent?
(1) It isn't part of the base system libevent.
(2) It doesn't understand all of our resolv.conf(5) syntax and it
can't talk to a nameserver over IPv6.
--
Christian "naddy" Weisgerber na...@mips.inka.d
On 10/14/10 17:30, Ted Unangst wrote:
On Thu, Oct 14, 2010 at 11:17 AM, Gilles Chehade wrote:
we don't have evdns in our libevent and I'm pretty confident it's not going
to happen any time soon given how many times I heard "no fucking way" by
different hackers :p
In that case, here's
OS X routed all dns lookups to a daemon (both unicast and multicast),
they can do local cashing and probably async lookups, maybe thats a
future solution ?
just my two cents.
On Thu, Oct 14, 2010 at 11:17 AM, Gilles Chehade wrote:
> we don't have evdns in our libevent and I'm pretty confident it's not going
> to happen any time soon given how many times I heard "no fucking way" by
> different hackers :p
In that case, here's some more constructive feedback from a quick
On 10/14/10 17:06, Ted Unangst wrote:
On Thu, Oct 14, 2010 at 10:47 AM, Gilles Chehade wrote:
eric@ has written an (awesome :p) asynchronous resolver that allows us to do
non-blocking DNS lookups.
Why not use the evdns resolver in libevent? If you're already using
libevent, wouldn't
On Thu, Oct 14, 2010 at 5:06 PM, Ted Unangst wrote:
> On Thu, Oct 14, 2010 at 10:47 AM, Gilles Chehade
wrote:
>> eric@ has written an (awesome :p) asynchronous resolver that allows us to
do
>> non-blocking DNS lookups.
>
> Why not use the evdns resolver in libevent? If you're already using
> lib
> On Thu, Oct 14, 2010 at 10:47 AM, Gilles Chehade wrote:
> > eric@ has written an (awesome :p) asynchronous resolver that allows us to do
> > non-blocking DNS lookups.
>
> Why not use the evdns resolver in libevent? If you're already using
> libevent, wouldn't that be a good fit? DNS resolvers
On Thu, Oct 14, 2010 at 10:47 AM, Gilles Chehade wrote:
> eric@ has written an (awesome :p) asynchronous resolver that allows us to do
> non-blocking DNS lookups.
Why not use the evdns resolver in libevent? If you're already using
libevent, wouldn't that be a good fit? DNS resolvers are histori
Dear tech@,
eric@ has written an (awesome :p) asynchronous resolver that allows us to do
non-blocking DNS lookups.
As of today, smtpd implements non-blocking lookups through a fork+imsg hack,
creating a socketpair() and a new process for each lookup. It kind of worked
ok but recently a bug report
21 matches
Mail list logo
