RFC 3425

Obsoleting IQUERY

📅 published November 2002, from ietf

RFC 3425 💖 Obsoleting IQUERY

okay bestie, let's get into it ✨ This is an Internet standards track doc from D. Lawrence at Nominum, dated November 2002. It updates RFC 1035 🎀. The header doesn't list any "Obsoletes" field, but the title says it all: it obsoletes the IQUERY operation. 💅

Status of This Memo 🌸

This is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋.

Copyright (C) The Internet Society (2002). All Rights Reserved. 💜

Abstract ✨

so the IQUERY method for inverse DNS lookups, from RFC 1035, basically never got implemented 💀 And when it was, it was usually switched off. Everyone kinda agreed the idea was unwise, and the go-to move is PTR queries and reverse-mapping records instead 🙈. So this doc deprecates IQUERY and declares it entirely obsolete 👑. It also updates RFC 1035 🦋.

1 - Introduction 🧚

As RFC 1035 (section 6.4) explains, the IQUERY operation is for looking up the name(s) tied to a given value 🔍. The value you're searching for goes in the query's answer section, and the response fills the question section with one or more 3-tuples of type, name and class 💅.

As noted in [RFC1035], section 6.4.3, inverse query processing is a huge burden on a server 😭. The server would have to either do an exhaustive search of its database, or keep a separate database keyed by the values in its primary one. Both could strain system resources, especially for servers that are authoritative for millions of names 💀.

Responses from these megaservers can get exceptionally large and easily hit megabyte sizes 📦. For example, using IQUERY to find every domain delegated to one of a large ISP's nameservers could return tens of thousands of 3-tuples in the question section 😳. That could easily be used to launch denial of service attacks 🚨.

Operators of servers that still support IQUERY in some form (like very old BIND 4 servers) usually just turn it off 🙃. That's mostly because of bugs in code that didn't get tested much, or worries about big blocks of names in their zones getting exposed by probes like inverse MX queries 🫣.

IQUERY is also kind of crippled by design, since it can't tell a requester where to go to get the info they asked for 🥲. The answer only covers the one server that was queried. It's sometimes a handy diagnostic tool, but not handy enough that operators want to enable it, or ask for it where it's missing 🤷‍♀️.

No known clients use IQUERY to provide any meaningful service 💅. The only common reverse mapping on the Internet (address records to names) runs on PTR records in the in-addr.arpa tree, and it's been serving the community really well for years 🫶.

so based on all of this, this doc recommends officially obsoleting the IQUERY operation for DNS servers 🎀

2 - Requirements 📋

The key word "SHOULD" in this document is to be interpreted as described in BCP 14, RFC 2119. Basically, there may be valid reasons to ignore a particular item, but you have to fully understand the implications and carefully weigh them before picking a different path 🧐.

3 - Effect on RFC 1035 💫

This doc changes the definition of opcode 1 from the one originally in section 4.1.1 of RFC 1035, and it fully supersedes section 6.4 (subsections included) of RFC 1035 🦋.

The definition of opcode 1 is now changed to:

"1               an inverse query (IQUERY) (obsolete)"

The text in section 6.4 of RFC 1035 is now considered obsolete ✨. Here's the applicability statement for the IQUERY opcode 💅:

Inverse queries using the IQUERY opcode were first described as the ability to look up the names associated with a particular Resource Record (RR) 🔍. Implementing them was optional, and they never got widespread use. So IQUERY is now obsolete, and name servers SHOULD return a "Not Implemented" error whenever an IQUERY request comes in 🚫.

4 - Security Considerations 🔐

⚠️ Okay, this part is serious, so pay attention, bestie 😤

Since this doc obsoletes an operation that used to be available, someone might have been using it as the basis of a security policy 😬. Still, the most logical thing for such a policy to do when a server doesn't respond positively is deny authentication/authorization. So it's highly unlikely that removing IQUERY support opens up any new security holes 🙏.

Note that if IQUERY is not obsoleted, securing its responses with DNS Security (DNSSEC) is extremely difficult without out-on-the-fly digital signing 🔏. That's a whole mess 💀.

5 - IANA Considerations 🗂️

The IQUERY opcode of 1 should be permanently retired, and it should never be assigned to any future opcode 🪦.

6 - Acknowledgments 🫶

Olafur Gudmundsson got this whole thing started 🌟. Matt Crawford, John Klensin, Erik Nordmark and Keith Moore contributed improved wording on how to handle obsoleting functionality that an Internet Standard describes 👑.

7 - References 📚

[RFC1035]  Mockapetris, P., "Domain Names - Implementation and
           Specification", STD 13, RFC 1035, November 1987.

[RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
           3", BCP 9, RFC 2026, October 1996.

[RFC2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

8 - Author's Address 📮

David C Lawrence
Nominum, Inc.
2385 Bay Rd
Redwood City CA 94063
USA

Phone: +1.650.779.6042
EMail: tale@nominum.com

Okay, so this is the legal boilerplate, and I'm keeping it word-for-word so nothing gets lost 🙏:

Copyright (C) The Internet Society (2002).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society 💖

and that's the tea, bestie 🌈✨

📦 where this page comes from