Board index » delphi » DNSResolver bug

DNSResolver bug

I have found a bug in TIdDnsResolver. Sorry for my bad English I'll try to
describe it.

Launch DNSResolver demo, set dns host name and very small ReceiveTimeout
(for example 1 msec). And perform any query. You will get an exception
'Receive packet too small'. It's normal. Then increase ReceiveTimeout value
(30000 msec) and perform next query. You will get exception 'Invalid header
Id XXXX'. Really DNSResolver gets the answer from previous query. Any next
queries will get the same exception.
Possible workaround for this problem is to add a line to ResolveDNS
procedure TIdDNSResolver.ResolveDNS;
begin
  try
    fRPacket := ReceiveString;    //VV add this line
    CreateQueryPacket;
    Send(QPacket);
    fRPacket := ReceiveString;
  finally DecodeReplyPacket; end;
end;

This situation can occur on slow connections or busy DNS servers.

By the way why do you use try-finally in this procedure. It hides the real
exception (for example 'host not found' ) that may occur in try-finally
block. I'd like to propose some changes:
procedure TIdDNSResolver.ResolveDNS;
begin
  try
    fRPacket := ReceiveString;
    CreateQueryPacket;
    Send(QPacket);
    fRPacket := ReceiveString;
  except        //VV
   ClearVars;   //VV
   raise;       //VV
  end;
//  finally
  DecodeReplyPacket;
//  end;
end;

--
Best Regards,
Vladimir Vassiliev
http://voldemarv.virtualave.net

 

Re:DNSResolver bug


"Vladimir Vassiliev" <volde...@mkb.mari.ru> wrote in
<96g1ii$n...@bornews.inprise.com>:

Quote
>Possible workaround for this problem is to add a line to ResolveDNS
>procedure TIdDNSResolver.ResolveDNS;
>begin
>  try
>    fRPacket := ReceiveString;    //VV add this line

Another approach is to wait up to the timeout for a match, discarding any
replies that don't match the query. After all, you can't know ahead how
many abandoned replies are in flight when you make a new query, and you
should be willing to accept one if it matches your current query.

Re:DNSResolver bug


Quote
"Kenneth Porter" <kenneth_por...@kensingtonlabs.com> wrote in message

news:Xns9049BF72F869Ekpkl@207.105.83.62...
Quote
> >Possible workaround for this problem is to add a line to ResolveDNS
> >procedure TIdDNSResolver.ResolveDNS;
> >begin
> >  try
> >    fRPacket := ReceiveString;    //VV add this line

> Another approach is to wait up to the timeout for a match, discarding any
> replies that don't match the query. After all, you can't know ahead how
> many abandoned replies are in flight when you make a new query, and you
> should be willing to accept one if it matches your current query.

And how can I determine that there was a timeout in last response with Indy
UDP? As I see in TIdUDPBase.ReceiveBuffer there isn't an exception that
informs about timeout.

--
Best Regards,
Vladimir Vassiliev
http://voldemarv.virtualave.net

Re:DNSResolver bug


"Vladimir Vassiliev" <volde...@mkb.mari.ru> wrote in
<96ii7j$hl...@bornews.inprise.com>:

Quote
>And how can I determine that there was a timeout in last response with
>Indy UDP? As I see in TIdUDPBase.ReceiveBuffer there isn't an exception
>that informs about timeout.

Does Indy have something like a select() call? (I haven't looked in detail
at Indy, and mainly know the Berkeley sockets style of programming, where
select() is what you'd use to accomplish this.)

Re:DNSResolver bug


"Vladimir Vassiliev" <volde...@mkb.mari.ru> wrote in
<96ii7j$hl...@bornews.inprise.com>:

Quote
>And how can I determine that there was a timeout in last response with
>Indy UDP? As I see in TIdUDPBase.ReceiveBuffer there isn't an exception
>that informs about timeout.

Looked it up. It's not an exception. ReceiveBuffer returns zero (ie. a
zero-length buffer) if it times out. Just keep calling it and reducing the
timeout by the elapsed time until either you get the packet you were
waiting for or the API returns zero.

Re:DNSResolver bug


I'm getting the "Invalid header Id XXXX" error every now and then.

Try doing an SOA on 202.95.107.55 or 202.95.107.30, I get that error every
time.

Or try looking up the domain for 213.24.225.70, I get that error every time.

Once I get the error, I have to restart my app because any further attempts
to use the DNSResolver results in the same error. Your suggested fix doesn't
seem to do anything.

Is there a way to reset the component?

--
Henri Fournier
Check WebBrowser & DHTMLEdit FAQ @ http://members.home.com/hfournier/
Check WebBrowser newsgroup @
http://groups.yahoo.com/group/delphi-webbrowser/
Check DHTMLEdit newsgroup @ http://groups.yahoo.com/group/delphi-dhtmledit/

Quote
"Vladimir Vassiliev" <volde...@mkb.mari.ru> wrote in message

news:96g1ii$nr29@bornews.inprise.com...
Quote
> I have found a bug in TIdDnsResolver. Sorry for my bad English I'll try to
> describe it.

> Launch DNSResolver demo, set dns host name and very small ReceiveTimeout
> (for example 1 msec). And perform any query. You will get an exception
> 'Receive packet too small'. It's normal. Then increase ReceiveTimeout
value
> (30000 msec) and perform next query. You will get exception 'Invalid
header
> Id XXXX'. Really DNSResolver gets the answer from previous query. Any next
> queries will get the same exception.
> Possible workaround for this problem is to add a line to ResolveDNS
> procedure TIdDNSResolver.ResolveDNS;
> begin
>   try
>     fRPacket := ReceiveString;    file://VV add this line
>     CreateQueryPacket;
>     Send(QPacket);
>     fRPacket := ReceiveString;
>   finally DecodeReplyPacket; end;
> end;

> This situation can occur on slow connections or busy DNS servers.

> By the way why do you use try-finally in this procedure. It hides the real
> exception (for example 'host not found' ) that may occur in try-finally
> block. I'd like to propose some changes:
> procedure TIdDNSResolver.ResolveDNS;
> begin
>   try
>     fRPacket := ReceiveString;
>     CreateQueryPacket;
>     Send(QPacket);
>     fRPacket := ReceiveString;
>   except        file://VV
>    ClearVars;   file://VV
>    raise;       file://VV
>   end;
> //  finally
>   DecodeReplyPacket;
> //  end;
> end;

> --
> Best Regards,
> Vladimir Vassiliev
> http://voldemarv.virtualave.net

Re:DNSResolver bug


"Henri Fournier" <hfourn...@home.com> wrote in
<974tbq$...@bornews.inprise.com>:

Quote
>Try doing an SOA on 202.95.107.55 or 202.95.107.30, I get that error
>every time.

>Or try looking up the domain for 213.24.225.70, I get that error every
>time.

Do you mean look up the SOA for the domain responsible for
55.107.95.202.in-addr.arpa.? You do know that you have to reverse the
address and append in-addr.arpa before issuing reverse queries, don't you?

Re:DNSResolver bug


Quote
"Henri Fournier" <hfourn...@home.com> wrote in message

news:974tbq$r33@bornews.inprise.com...
Quote
> I'm getting the "Invalid header Id XXXX" error every now and then.

> Try doing an SOA on 202.95.107.55 or 202.95.107.30, I get that error every
> time.

> Or try looking up the domain for 213.24.225.70, I get that error every
time.

Can't reproduce your bug. My DNS server reports 'Query Name error' on such
queries.
Can you advice public DNS server to test this query?

--
Best Regards,
Vladimir Vassiliev
http://voldemarv.virtualave.net

Re:DNSResolver bug


Quote
"Kenneth Porter" <kenneth_por...@kensingtonlabs.com> wrote in message

news:Xns904FE3ACC2B04kpkl@207.105.83.62...
Quote
> "Vladimir Vassiliev" <volde...@mkb.mari.ru> wrote in
> <96ii7j$hl...@bornews.inprise.com>:

> >And how can I determine that there was a timeout in last response with
> >Indy UDP? As I see in TIdUDPBase.ReceiveBuffer there isn't an exception
> >that informs about timeout.

> Looked it up. It's not an exception. ReceiveBuffer returns zero (ie. a
> zero-length buffer) if it times out. Just keep calling it and reducing the
> timeout by the elapsed time until either you get the packet you were
> waiting for or the API returns zero.

I don't want to keep calling it if there was a timeout. I want to receive an
error and show this error to user that there was a timeout. And when perform
next query I want to clear ReceiveBuffer before making query because on this
step I don' know that there was a timeout in previous query.
Possible workaround to check for EIdDnsResolverError and compare Error
string with RSQueryInvalidHeaderID and then try to ReceiveBuffer and
DecodeReplyPacket once more.

--
Best Regards,
Vladimir Vassiliev
http://voldemarv.virtualave.net

Re:DNSResolver bug


Yes I do and it works most of the time.

But some IPs always cause a "Query Name error" (as Vladimir said). After
that happens any other attempts to use the DNSResolver fails with the
"Invalid header Id XXXX" error.

Like I said, I get the same problem when doing domain lookups (PTR) on
certain IPs as well.
Sounds like Vladimir is trying to solve the same problem.

--
Henri Fournier
Check WebBrowser & DHTMLEdit FAQ @ http://members.home.com/hfournier/
Check WebBrowser newsgroup @
http://groups.yahoo.com/group/delphi-webbrowser/
Check DHTMLEdit newsgroup @ http://groups.yahoo.com/group/delphi-dhtmledit/

Quote
"Kenneth Porter" <kenneth_por...@kensingtonlabs.com> wrote in message

news:Xns9050E381FE83Dkpkl@207.105.83.62...
Quote
> "Henri Fournier" <hfourn...@home.com> wrote in
> <974tbq$...@bornews.inprise.com>:

> >Try doing an SOA on 202.95.107.55 or 202.95.107.30, I get that error
> >every time.

> >Or try looking up the domain for 213.24.225.70, I get that error every
> >time.

> Do you mean look up the SOA for the domain responsible for
> 55.107.95.202.in-addr.arpa.? You do know that you have to reverse the
> address and append in-addr.arpa before issuing reverse queries, don't you?

Re:DNSResolver bug


I get "Query Name error" too, but any attempts to use the DNSResolver after
that results in "Invalid header Id XXXX" error.

--
Henri Fournier
Check WebBrowser & DHTMLEdit FAQ @ http://members.home.com/hfournier/
Check WebBrowser newsgroup @
http://groups.yahoo.com/group/delphi-webbrowser/
Check DHTMLEdit newsgroup @ http://groups.yahoo.com/group/delphi-dhtmledit/

Quote
"Vladimir Vassiliev" <volde...@mkb.mari.ru> wrote in message

news:9756qi$r93@bornews.inprise.com...
Quote

> "Henri Fournier" <hfourn...@home.com> wrote in message
> news:974tbq$r33@bornews.inprise.com...
> > I'm getting the "Invalid header Id XXXX" error every now and then.

> > Try doing an SOA on 202.95.107.55 or 202.95.107.30, I get that error
every
> > time.

> > Or try looking up the domain for 213.24.225.70, I get that error every
> time.

> Can't reproduce your bug. My DNS server reports 'Query Name error' on such
> queries.
> Can you advice public DNS server to test this query?

> --
> Best Regards,
> Vladimir Vassiliev
> http://voldemarv.virtualave.net

Re:DNSResolver bug


Please let me know if this workaround solves the problem. I'll be happy to
test it for you.
--
Henri Fournier
Check WebBrowser & DHTMLEdit FAQ @ http://members.home.com/hfournier/
Check WebBrowser newsgroup @
http://groups.yahoo.com/group/delphi-webbrowser/
Check DHTMLEdit newsgroup @ http://groups.yahoo.com/group/delphi-dhtmledit/

Quote
"Vladimir Vassiliev" <volde...@mkb.mari.ru> wrote in message

news:9756fr$r87@bornews.inprise.com...
Quote

> "Kenneth Porter" <kenneth_por...@kensingtonlabs.com> wrote in message
> news:Xns904FE3ACC2B04kpkl@207.105.83.62...
> > "Vladimir Vassiliev" <volde...@mkb.mari.ru> wrote in
> > <96ii7j$hl...@bornews.inprise.com>:

> > >And how can I determine that there was a timeout in last response with
> > >Indy UDP? As I see in TIdUDPBase.ReceiveBuffer there isn't an exception
> > >that informs about timeout.

> > Looked it up. It's not an exception. ReceiveBuffer returns zero (ie. a
> > zero-length buffer) if it times out. Just keep calling it and reducing
the
> > timeout by the elapsed time until either you get the packet you were
> > waiting for or the API returns zero.
> I don't want to keep calling it if there was a timeout. I want to receive
an
> error and show this error to user that there was a timeout. And when
perform
> next query I want to clear ReceiveBuffer before making query because on
this
> step I don' know that there was a timeout in previous query.
> Possible workaround to check for EIdDnsResolverError and compare Error
> string with RSQueryInvalidHeaderID and then try to ReceiveBuffer and
> DecodeReplyPacket once more.

> --
> Best Regards,
> Vladimir Vassiliev
> http://voldemarv.virtualave.net

Re:DNSResolver bug


I can resolve other hosts after getting such error. Did you reinstall Indy
after applying my patch?

--
Best Regards,
Vladimir Vassiliev
http://voldemarv.virtualave.net

Quote
"Henri Fournier" <hfourn...@home.com> wrote in message

news:975m2q$jcc10@bornews.inprise.com...
Quote
> I get "Query Name error" too, but any attempts to use the DNSResolver
after
> that results in "Invalid header Id XXXX" error.

> --
> Henri Fournier
> Check WebBrowser & DHTMLEdit FAQ @ http://members.home.com/hfournier/
> Check WebBrowser newsgroup @
> http://groups.yahoo.com/group/delphi-webbrowser/
> Check DHTMLEdit newsgroup @

http://groups.yahoo.com/group/delphi-dhtmledit/

Re:DNSResolver bug


I applied your patch, removed Indy, and then installed Indy. No difference.

When I do an SOA on 202.95.107.32, I get "DNS Server Reports Query Name
Error".

Then I try to do an SOA on 202.95.107, and I get the "Invalid Header Id"
Then I try to do an SOA on 202.95, and I get the "Invalid Header Id"

Then I try a domain lookup (A) on www.t2mail.com, and I get the "Invalid
Header Id"

Also tried an MX lookup, same problem.

I have to restart the app.

--
Henri Fournier
Check WebBrowser & DHTMLEdit FAQ @ http://members.home.com/hfournier/
Check WebBrowser newsgroup @
http://groups.yahoo.com/group/delphi-webbrowser/
Check DHTMLEdit newsgroup @ http://groups.yahoo.com/group/delphi-dhtmledit/

Quote
"Vladimir Vassiliev" <volde...@mkb.mari.ru> wrote in message

news:975r9b$jaf11@bornews.inprise.com...
Quote
> I can resolve other hosts after getting such error. Did you reinstall Indy
> after applying my patch?

> --
> Best Regards,
> Vladimir Vassiliev
> http://voldemarv.virtualave.net

> "Henri Fournier" <hfourn...@home.com> wrote in message
> news:975m2q$jcc10@bornews.inprise.com...
> > I get "Query Name error" too, but any attempts to use the DNSResolver
> after
> > that results in "Invalid header Id XXXX" error.

> > --
> > Henri Fournier
> > Check WebBrowser & DHTMLEdit FAQ @ http://members.home.com/hfournier/
> > Check WebBrowser newsgroup @
> > http://groups.yahoo.com/group/delphi-webbrowser/
> > Check DHTMLEdit newsgroup @
> http://groups.yahoo.com/group/delphi-dhtmledit/

Re:DNSResolver bug


"Henri Fournier" <hfourn...@home.com> wrote in
<975ump$5...@bornews.inprise.com>:

Quote
>When I do an SOA on 202.95.107.32, I get "DNS Server Reports Query Name
>Error".

I tried "dig -x 202.95.107.32 soa" from Linux and got a NXDOMAIN error,
with the SOA in the additional data. (The full output is below.)

Quote
>Then I try to do an SOA on 202.95.107, and I get the "Invalid Header Id"

Each query is issued with a random query ID. The answer should have the
same value in its header. This is used to detect out-of-sync conditions,
like reading a stale answer from a previous query.

I looked at the ISC sources for res_query and they do the same check and
perform retries. They also round-robin all name servers for a domain until
all servers have been tried some configurable number of retries.

res_query also verifies that the answer came from the same server one
queried, to avoid spoofing attacks, and that the answer type matches the
query.

Quote
>I have to restart the app.

That would be reasonable, once you get out of sync. The only other solution
would be to "soak up" answers in flight for some period until you get a
header ID match again.

Here's the output from the dig command:

; <<>> DiG 8.3 <<>> -x soa
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;;      32.107.95.202.in-addr.arpa, type = SOA, class = IN

;; AUTHORITY SECTION:
95.202.in-addr.arpa.    2h52m55s IN SOA  ns.apnic.net. read-TXT-record-of-
zone-first-dns-admin.apnic.net. (
                                        2001021297      ; serial
                                        1D              ; refresh
                                        2H              ; retry
                                        4w2d            ; expiry
                                        4D )            ; minimum

;; Total query time: 2 msec
;; FROM: obi-wan.kenlabs.com to SERVER: default -- 127.0.0.1
;; WHEN: Sat Feb 24 01:37:44 2001
;; MSG SIZE  sent: 44  rcvd: 132

Go to page: [1] [2] [3]

Other Threads