Hi Ben,

On 6 Oct 2026, at 13:24, Ben Cartwright-Cox via db-wg <db-wg@ripe.net> wrote:

A surprise I just encountered was I was checking AS215165 (who recently had their aut-num object deleted) and I was surprised to see the whois server reply back with a inetnum having (I assume) matched the netname instead!

I know the whois server logic is a bit mythical but this seems like a obvious case of the clear intention of the user is not what is being delivered, and I assume this will confuse other programs as well

This behaviour is deliberate and Whois has worked like this for a long time, although it is surprising when the netname also matches an ASN. According to the DB documentation, "The netname attribute is a look-up key, one can query the RIPE Database supplying the netname as an argument. The result of the query will show all inetnum objects with that netname." https://docs.db.ripe.net/FAQ#what-is-a-netname https://docs.db.ripe.net/Tables-of-Query-Types-Supported-by-the-RIPE-Databas... The netname attribute is an object name, and the syntax for that is very broad: "Made up of letters, digits, the character underscore and the character hyphen; the first character of a name must be a letter, and the last character of a name must be a letter or a digit." https://docs.db.ripe.net/Appendices/Appendix-A--Syntax-of-Object-Attributes If there is consensus to change the behaviour for matching on netname, then we will do that. Otherwise, I suggest a workaround of using the "-T/--select-types" flag to only match on specified object types (i.e. if you're expecting an aut-num, only return aut-num). Regards Ed Shryane RIPE NCC