inverse query:PTR RR or OPCODE=1 ?
when I read the RFC1035, I noticed the opcode defination in the DNS message head . It said that when opcode = 1 the message did Inverse query . but in the packet I capatured when I used nslookup to do inverse query ,the inverse query packet use the opcode = 0 and the question segment with RR TYPE PTR. Can someone explain this ? Am I wrong about understanding the inverse query ? Thank a lot . -- 为爱上色 公益活动___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
inverse query:PTR RR or OPCODE=1 ?
when I read the RFC1035, I noticed the opcode defination in the DNS message head . It said that when opcode = 1 the message did Inverse query . but in the packet I capatured when I used nslookup to do inverse query ,the inverse query packet use the opcode = 0 and the question segment with RR TYPE PTR. Can someone explain this ? Am I wrong about understanding the inverse query ? Thank a lot . ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: inverse query:PTR RR or OPCODE=1 ?
On Thu, Dec 03, 2009 at 10:42:38AM +0800, lipeng967 wrote: when I read the RFC1035, I noticed the opcode defination in the DNS message head . It said that when opcode = 1 the message did Inverse query . but in the packet I capatured when I used nslookup to do inverse query ,the inverse query packet use the opcode = 0 and the question segment with RR TYPE PTR. Can someone explain this ? Am I wrong about understanding the inverse query ? Thank a lot . Note that 6.4 (inverse queries) was optional, and read 3.5 (in-addr.arpa), which is about REVERSE (not inverse) DNS as it is used today. With some additions and changes: the RFCs are living documents. RFC 3425 obsolets inverse queries entirely: The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete. This document updates RFC 1035. -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: inverse query:PTR RR or OPCODE=1 ?
In message 4591889.164031259808158905.javamail.corem...@app183.163.com, lipen g967 writes: when I read the RFC1035, I noticed the opcode defination in the DNS message head . It said that when opcode = 1 the message did Inverse query. but in the packet I capatured when I used nslookup to do inverse query ,the inverse query packet use the opcode = 0 and the question segment with RR TYPE PTR. Can someone explain this ? Am I wrong about understanding the inverse query ? Thank a lot . Nslookup does normal queries into the .ARPA namespace to do reverse lookups. Inverse lookups were a concept that really only worked in the dentist surgery senario (one server providing the entire DNS view). Inverse queries were deprecated years ago http://www.ietf.org/rfc/rfc3425.txt. Mark -- 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
Re: inverse query:PTR RR or OPCODE=1 ?
Thank you very much for your help and advice .___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
