It's not a perfect world. Even getting back a EDNS response does not indicate that the server understands EDNS.
In message <002301ca579c$56deb0f0$21011...@china.huawei.com>, Ashwin writes: > > In message <001501ca5785$257c7220$21011...@china.huawei.com>, Ashwin writes: > > > > Hi All, > > > > RFC 2671 mentions in Section 5.3 > > > > Responders who do not understand these protocol extensions are > > expected to send a response with RCODE NOTIMPL, FORMERR, or > > SERVFAIL. > > > > However the above mentioned error codes are shared [SERVFAIL, NOTIMPL] are > > shared, so how do we ascertain that the error code returned is an > indication > > that a particular server is non-EDNS, since the error might be returned > due > > to some other reason also. > > > > So essentially my query is how do we decide that a particular server is > EDNS > > or not? Can it be assumed that each time the above three error codes are > > returned , it signifies that the DNS server is not EDNS capable? > > > Hi Mark, > >> You assume it is EDNS if it is in response to a EDNS query and retry > >> w/o EDNS. It the problem is EDNS the plain DNS query will succeed. > >> If it is not EDNS the plain EDNS query will fail. > > Thanks for you response. I have a doubt though. > > I send out an EDNS query, for the response the following possibilities > a) Success, with OPT RR, I assume server is EDNS capable > b) Failure with RCODE NOTIMPL, FORMERR, or SERVFAIL with or without > OPT RR. > > In b) I do not know whether server is EDNS or not, since server might return > NOTIMPL & SERVFAIL error codes for some other reason also. If I consider the > case that retry with plain DNS query is success and assume EDNS was problem, > I think maybe its not correct because SERVFAIL might happen for some other > reason at the time EDNS query is sent, but that error is resolved by the > time the plain DNS query is sent. So even though server is EDNS i would > assume it is non-EDNS. > > The idea is to identify whether a server supports EDNS through a first > query, and then subsequent requests we send based on this identification. > One could call it a pseudo-caching of the EDNS feature for servers. > > I hope I made myself clear :( > > > Regards > > > > Ashwin > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users