Suggestion of change for inverse query of notify
Hello db-wg. I would like to change the behaviour of the whois-output for the following query whois -h whois.ripe.net -- "-r -T inetnum,route -i notify info@resilans.se" Via that question, I will see every object that has the notify info@resilans.se set, which right now is inetnum: 194.14.3.0 - 194.14.3.255 netname: RESILANS descr: Resilans AB remarks: VV org: ORG-ABUS1000-RIPE country: SE admin-c: RESI1-RIPE tech-c: RESI1-RIPE status: ASSIGNED PI mnt-by: RESILANS-MNT mnt-domains: RESILANS-MNT mnt-routes: RESILANS-MNT source: RIPE # Filtered However, my request is that the above query should give the exact same output as the below query whois -h whois.ripe.net -- "-r -T inetnum,route 194.14.3.0" which will also display the corresponding route-object, is there any real reason why this is not displayed with an inverse query? it looks like: inetnum: 194.14.3.0 - 194.14.3.255 netname: RESILANS descr: Resilans AB remarks: VV org: ORG-ABUS1000-RIPE country: SE admin-c: RESI1-RIPE tech-c: RESI1-RIPE status: ASSIGNED PI mnt-by: RESILANS-MNT mnt-domains: RESILANS-MNT mnt-routes: RESILANS-MNT source: RIPE # Filtered route: 194.14.3.0/24 descr: Resilans AB origin: AS12381 mnt-by: RESILANS-MNT source: RIPE # Filtered -- Best regards Fredrik Widell Resilans AB http://www.resilans.se/ mail: info@resilans.se , fredrik@resilans.se phone: +46 8 688 11 80
Hi Fredrik, just to make sure that the behaviour - and thus the problem - is: when inverse searching for that notify: attribute value, the whois software does pick up the inetnum:, due to the notify: attribute in the maintainer, but not the route:, although it is equally covered by that same maintainer. Correct? If that's the case then I guess you stumbled over bug (or weird interaction or side-effect of using an object type list :-) ) Regards, Wilfried. Fredrik Widell wrote:
Hello db-wg.
I would like to change the behaviour of the whois-output for the following query
whois -h whois.ripe.net -- "-r -T inetnum,route -i notify info@resilans.se"
Via that question, I will see every object that has the notify info@resilans.se set, which right now is
inetnum: 194.14.3.0 - 194.14.3.255 netname: RESILANS descr: Resilans AB remarks: VV org: ORG-ABUS1000-RIPE country: SE admin-c: RESI1-RIPE tech-c: RESI1-RIPE status: ASSIGNED PI mnt-by: RESILANS-MNT mnt-domains: RESILANS-MNT mnt-routes: RESILANS-MNT source: RIPE # Filtered
However, my request is that the above query should give the exact same output as the below query
whois -h whois.ripe.net -- "-r -T inetnum,route 194.14.3.0"
which will also display the corresponding route-object, is there any real reason why this is not displayed with an inverse query? it looks like:
inetnum: 194.14.3.0 - 194.14.3.255 netname: RESILANS descr: Resilans AB remarks: VV org: ORG-ABUS1000-RIPE country: SE admin-c: RESI1-RIPE tech-c: RESI1-RIPE status: ASSIGNED PI mnt-by: RESILANS-MNT mnt-domains: RESILANS-MNT mnt-routes: RESILANS-MNT source: RIPE # Filtered
route: 194.14.3.0/24 descr: Resilans AB origin: AS12381 mnt-by: RESILANS-MNT source: RIPE # Filtered
Of course, the notify attribute of the ROUTE object you mention is DIFFERENT to that of the inetnum, so unsurprisingly ROUTE didn't come up in the inverse query. You suppressed related content so no ORG was returned. No ROUTE is returned because you didn't specify an IP and no related content. Doesn't look like a bug to me. Kind regards Jamie Stallwood -- Jamie Stallwood Security Specialist Imerja Limited Tel: 07795 840385 jamie.stallwood@imerja.com -----Original Message----- From: db-wg-bounces@ripe.net on behalf of Wilfried Woeber Sent: Wed 3/19/2014 15:48 To: Fredrik Widell Cc: db-wg@ripe.net Subject: Re: [db-wg] Suggestion of change for inverse query of notify Hi Fredrik, just to make sure that the behaviour - and thus the problem - is: when inverse searching for that notify: attribute value, the whois software does pick up the inetnum:, due to the notify: attribute in the maintainer, but not the route:, although it is equally covered by that same maintainer. Correct? If that's the case then I guess you stumbled over bug (or weird interaction or side-effect of using an object type list :-) ) Regards, Wilfried. Fredrik Widell wrote:
Hello db-wg.
I would like to change the behaviour of the whois-output for the following query
whois -h whois.ripe.net -- "-r -T inetnum,route -i notify info@resilans.se"
-- Imerja Limited Tel: 0844 225 2888 | Fax: 0870 8611489 | 24x7 ISOC: 0870 8611490 | Web: www.imerja.com Registered Office: Hallmark House, Paragon Business Park, Chorley New Road, Horwich, Bolton BL6 6HG Registered in England and Wales No. 5180119 VAT Registered No. 845 0647 22 ISO9001 / ISO27001 This email is confidential and intended solely for the person or organisation to which it is addressed. It may contain privileged and confidential information. If you are not the intended recipient(s) you should not use, copy, distribute or take any action or reliance on it, since to do so is strictly prohibited and may be unlawful. If you have received this transmission in error please notify the sender immediately by email reply and delete it from your system. E-mail messages are not secure and attachments could contain software viruses which may damage your system. Whilst every reasonable precaution has been taken to minimise this risk, Imerja Limited cannot accept any liability for any damage sustained as a result of these factors. You are advised to carry out your own virus checks before opening any attachment. Any views or opinions expressed in this e-mail are solely those of the author and do not represent those of Imerja Limited unless otherwise stated.
Dear Fredrik Before we get into a discussion about how behaviour should/should not be changed, perhaps I can explain the technical details of how these queries work. There are several inter-related factors here. First of all, for a non inverse query as in your second query below, we parse the query string to see what type of object primary key it could match. We then search for matching objects of those types. If you use -T we filter the result set according to the types specified in the argument to -T. Adding the -r means we don't look into any of the objects in the (filtered) result set to find the referenced secondary object types (such as PERSON or ROLE). It was specifically requested by the community many years ago that if the query result set includes an Internet number resource object (INETNUM or INET6NUM) we also return any ROUTE/ROUTE6 object with a matching prefix. This is regardless of whether the query search string matches the primary key of the ROUTE/ROUTE6 object. These objects are added to the result set before any filtering or referral queries are made. If -r was not specified the secondary object for the routes would also be returned. If -T did not include ROUTE it would be added to the result set to satisfy the community exception and then filtered out with the -T. To enable inverse searches we keep index tables of all inverse searchable attributes. The primary result set of an inverse query is all objects that contain the inverse searched attribute with the specified value. The results are then subject to filtering with -T and expansion without -r in the same way as the above query. In general most uses of inverse queries only want to find those objects that contain the specified string in the searched attribute. The community exception for always returning ROUTE/ROUTE6 objects when the result set includes an INET(6)NUM object with matching prefix has never been applied to inverse queries. If this is the behaviour change you want it is quite a significant change. It will return objects in the result set that do not include the inverse searched string (ignoring referred secondary objects subject to -r). So for your specific examples, the inverse query looks for objects with "notify: info@resilans.se". This includes the INETNUM but not the ROUTE object. The other query looks for address space including the address 194.14.3.0 and any matching ROUTE object. So you get back both the INETNUM and ROUTE object. Regards Denis Walker Business Analyst RIPE NCC Database Team On 19/03/2014 13:41, Fredrik Widell wrote:
Hello db-wg.
I would like to change the behaviour of the whois-output for the following query
whois -h whois.ripe.net -- "-r -T inetnum,route -i notify info@resilans.se"
Via that question, I will see every object that has the notify info@resilans.se set, which right now is
inetnum: 194.14.3.0 - 194.14.3.255 netname: RESILANS descr: Resilans AB remarks: VV org: ORG-ABUS1000-RIPE country: SE admin-c: RESI1-RIPE tech-c: RESI1-RIPE status: ASSIGNED PI mnt-by: RESILANS-MNT mnt-domains: RESILANS-MNT mnt-routes: RESILANS-MNT source: RIPE # Filtered
However, my request is that the above query should give the exact same output as the below query
whois -h whois.ripe.net -- "-r -T inetnum,route 194.14.3.0"
which will also display the corresponding route-object, is there any real reason why this is not displayed with an inverse query? it looks like:
inetnum: 194.14.3.0 - 194.14.3.255 netname: RESILANS descr: Resilans AB remarks: VV org: ORG-ABUS1000-RIPE country: SE admin-c: RESI1-RIPE tech-c: RESI1-RIPE status: ASSIGNED PI mnt-by: RESILANS-MNT mnt-domains: RESILANS-MNT mnt-routes: RESILANS-MNT source: RIPE # Filtered
route: 194.14.3.0/24 descr: Resilans AB origin: AS12381 mnt-by: RESILANS-MNT source: RIPE # Filtered
Hi Denis, Denis Walker wrote: [...]
So for your specific examples, the inverse query looks for objects with "notify: info@resilans.se". This includes the INETNUM but not the ROUTE object.
my apologies for getting off-track in my previous mail. I was -again- bitten by the deault filtering, silently "eating" the notify: line in the inetnum object that was quoted :-( And I didn't "go to the source". Lesson learned. Sorry, Wilfried
The other query looks for address space including the address 194.14.3.0 and any matching ROUTE object. So you get back both the INETNUM and ROUTE object.
Regards Denis Walker Business Analyst RIPE NCC Database Team
participants (4)
-
Denis Walker -
Fredrik Widell -
Jamie Stallwood -
Wilfried Woeber