Your message dated Tue, 17 Jul 2007 13:32:23 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#242278: ping considered harmful (pdnsd bugreport #242278)
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: pdnsd
Version: 1.1.8b1par7-1.1
Severity: wishlist
Friendly replies to feature requests prompt more feature requests. So
here's one more.
Currently, when using the uptest=ping option, pdnsd appears to do the
following:
- use ICMP echo request to find out if the server is accessible;
- determine its not as soon as one ping fails.
IMHO, both are wrong.
An ICMP echo request only tells you that the machine is up; it doesn't
tell you whether the name server is up, and it also doesn't tell you
whether you are firewalled from the server.
A better solution would be to use an application-level ping: send a
query to the server, and see whether it replies. With the name
protocol, an application-level ping is very easy to implement: just
send a query with qdcount = 0. If the server is accessible, it will
reply with either a reply with qdcount = ancount = 0, or else with a
FormErr; in either case, that's enough for your information.
If the server is not accessible, you'll most probably get an ICMP
``destination inaccessible'' reply (one of ``network inaccessible'',
``host inaccessible'' or ``destination administratively prohibited'');
in that case, if you're using a connected socket, you'll get an error
in recv. It is also possible (but less likely) that you'll get
nothing, in which case you'll timeout just like you do know.
A further refinement is to reset the ping timer whenever you receive a
reply from the server: when you get a reply from the server, you know
it's up, no need to ping it. Pdnsd does not appear to do that.
A more serious problem is that pdnsd supposes a server is down
whenever a ping is lost. That's a serious problem for me, as my line
is often congested, and ping packets get lost; hence, the server goes
spuriously offline and I have to pdnsd-ctl it by hand. Pdnsd should
use a few pings, and only put a server offline if it's failed a few.
And here's one that's more of a detail: the user should have no need
to set ping_timeout: pdnsd should start with a large ping timeout, and
use the results of previous pings to determine the right timeout to
use. You could simply set the timeout to 5 times the rtt of the
previous ping, or be more refined and use the TCP RTO-estimation
algorithm (which you'll find in RFC 793).
Thanks,
Juliusz
--- End Message ---
--- Begin Message ---
Version: 1.1.11
On Fri, Apr 30, 2004 at 03:45:20PM +0200, Paul A. Rombouts wrote:
> Hi Juliusz,
>
> In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=242278 , you wrote:
> >Currently, when using the uptest=ping option, pdnsd appears to do the
> >following:
> > - use ICMP echo request to find out if the server is accessible;
> > - determine its not as soon as one ping fails.
> >IMHO, both are wrong.
>
> Actually, it takes more than one ping timeout before pdnsd considers a
> server down, but I'll explain more fully below.
>
> >An ICMP echo request only tells you that the machine is up; it doesn't
> >tell you whether the name server is up, and it also doesn't tell you
> >whether you are firewalled from the server.
> >A better solution would be to use an application-level ping: send a
> >query to the server, and see whether it replies. With the name
> >protocol, an application-level ping is very easy to implement: just
> >send a query with qdcount = 0. If the server is accessible, it will
> >reply with either a reply with qdcount = ancount = 0, or else with a
> >FormErr; in either case, that's enough for your information.
>
> Interesting idea. The actual implementation will need some careful
> thought and could take some time. I want to release 1.1.11 shortly, so it
> will have to wait until a later version.
>
> >If the server is not accessible, you'll most probably get an ICMP
> >``destination inaccessible'' reply (one of ``network inaccessible'',
> >``host inaccessible'' or ``destination administratively prohibited'');
> >in that case, if you're using a connected socket, you'll get an error
> >in recv. It is also possible (but less likely) that you'll get
> >nothing, in which case you'll timeout just like you do know.
>
> My experience is that a TCP connection failure will quickly result result
> in one of the error replies you mentioned, but a UDP connection will not
> (in which case you time out).
>
> >A further refinement is to reset the ping timer whenever you receive a
> >reply from the server: when you get a reply from the server, you know
> >it's up, no need to ping it. Pdnsd does not appear to do that.
>
> Good idea. This has been implemented for the upcoming 1.1.11 release.
>
> >A more serious problem is that pdnsd supposes a server is down
> >whenever a ping is lost. That's a serious problem for me, as my line
> >is often congested, and ping packets get lost; hence, the server goes
> >spuriously offline and I have to pdnsd-ctl it by hand. Pdnsd should
> >use a few pings, and only put a server offline if it's failed a few.
>
> Actually, in case of no reply, pdnsd will send 2 ping packets before
> considering the ping test as failed. But I did notice something else in
> the code that could explain the problem you have. When a query to a
> server times out, a server with uptest=ping will be immediately marked
> down and will stay down until the next periodic up test by the server
> status thread.
> This was implemented by Thomas Moestl. But now you have set me thinking
> about it, this doesn't seem such a great idea. I think he was afraid that
> doing a ping test could take a long time and hold up the query thread.
> I have solved this by moving the responsibility for doing the ping test
> (or any other uptest) to the server status thread. The query thread can
> simply set the timestamp to zero and send a condition signal to wake up
> the server status thread.
> I have implemented this for the upcoming 1.1.11 release. Now when a query
> to a remote server times out, pdnsd will immediately schedule an uptest
> but will wait until the uptest has definitively failed before marking a
> server down.
>
> >And here's one that's more of a detail: the user should have no need
> >to set ping_timeout: pdnsd should start with a large ping timeout, and
> >use the results of previous pings to determine the right timeout to
> >use. You could simply set the timeout to 5 times the rtt of the
> >previous ping, or be more refined and use the TCP RTO-estimation
> >algorithm (which you'll find in RFC 793).
>
> Also an interesting idea. But it will have to wait until after the 1.1.11
> release.
>
> Thanks for your suggestions,
> --
> Paul Rombouts
>
>
--
·O· Pierre Habouzit
··O [EMAIL PROTECTED]
OOO http://www.madism.org
pgpMSfoRorsE6.pgp
Description: PGP signature
--- End Message ---
