APNIC - Query the APNIC Whois Database

To assist you with debugging problems, this whois query was received from IP Address

% APNIC found the following authoritative answer from: whois.ripe.net
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.
% Information related to 'AS3209 - AS3353'
as-block:       AS3209 - AS3353
descr:          RIPE NCC ASN block
remarks:        These AS Numbers are assigned to network operators in the RIPE NCC service region.
mnt-by:         RIPE-NCC-HM-MNT
created:        2018-11-22T15:27:19Z
last-modified:  2018-11-22T15:27:19Z
source:         RIPE
% Information related to 'AS3320'
% Abuse contact for 'AS3320' is 'auftrag@nic.telekom.de'
aut-num:        AS3320
as-name:        DTAG
org:            ORG-DTA2-RIPE
descr:          Internet service provider operations
remarks:        peering coordinators for AS3320: <peering@telekom.de>
remarks:        abuse reports should be sent to the contacts listed in the registry entries for the IP address of the offending host system
remarks:        We share the view that for many networks (including ours:-) only some abstraction of the actual routing policy should/can be published in the IRR. Right now we are abstracting to a very essential minimum.
remarks:        the most important and helpful use of the IRR is to publish what a network will announce to peers and upstream # we are providing that by means of the AS-set AS3320:AS-DTAG which we have been keeping up to date all the time
remarks:        we encourage all our neighbors to define and maintain an AS-set to describe their announcements, and to register all the routes (and have their customers do so as well)
import:         from AS-ANY accept ANY # heavy abstraction hits! well, we are ... neither peering promiscuously nor accepting all junk routes offered...
remarks:        we maintain a list of what our neighbors have told us about their announcements towards AS3320 - in terms of AS-set (preferred), AS number, route-set (and the IRR database used to publish)
remarks:        in fact we apply route filters based on this for all neighbors - as far as feasible
remarks:        for data published through the RIPE routing registry we generate filters automatically
remarks:        we consider the integration of RIR and routing registry data and the application of RPSS authorization a great feature of the RIPE routing registry # unfortunately this benefit is not available with any other IRR database that we know of... and some of the IRR databases allow essentially any garbage to be registered without any control - making those databases quite useless...
export:         to AS3320:AS-CUSTOMERS announce ANY # but don't publish that list; in general - if they ask for less, we can do
export:         to AS-ANY announce AS3320:AS-DTAG # for peers and others... for backwards compatibility the older AS-DTAG will be kept around for some more time - defined using just members: AS3320:AS-DTAG please convert to AS3320:AS-DTAG if you are still using the old AS-DTAG
remarks:        customers are strongly encouraged to define and maintain an AS-set that we will include in the definition of AS3320:AS-DTAG (if we are told the name)
remarks:        this will be sufficient to have our peers accept the routes
remarks:        in any case peers - and any network in the Internet - is free to apply some selective policy (e.g. prefix length based) # but we do not think that any such selective policy will be based on details of our routing policy omitted from this aut-num: object
remarks:        unfortunately some customers do not provide usable IRR data; we will NOT add to the uncontrolled garbage in the IRR by proxy registering in some database that requires no authorization
remarks:        we advise customers that routes without IRR registration and not covered by AS3320:AS-DTAG may receive less than full support by some of our peer networks and other parts of the Internet
remarks:        ============================================================== IPv6 we do/publish essentially the same like for IPv4
mp-import:      afi ipv6.unicast from AS-ANY accept ANY # heavy abstraction... neither peering promiscuously nor accepting all junk routes offered...
mp-export:      afi ipv6.unicast to AS3320:AS-CUSTOMERS-V6 announce ANY # but don't publish that list; in general - if they ask for less, we can do
mp-export:      afi ipv6.unicast to AS-ANY announce AS3320:AS-DTAG-V6 # for peers and others...
remarks:        ==============================================================
admin-c:        SB15220-RIPE
tech-c:         SB15220-RIPE
status:         ASSIGNED
mnt-by:         RIPE-NCC-END-MNT
mnt-by:         DTAG-RR
created:        1970-01-01T00:00:00Z
last-modified:  2020-12-11T15:33:02Z
source:         RIPE
organisation:   ORG-DTA2-RIPE
org-name:       Deutsche Telekom AG
country:        DE
org-type:       LIR
address:        Eduard-Schopf-Allee 1
address:        D-28217
address:        Bremen
address:        GERMANY
phone:          +4942151555165
fax-no:         +494412344589
fax-no:         +49391580100379
admin-c:        DTAG-RIPE
admin-c:        UR661-RIPE
admin-c:        SL7866-RIPE
admin-c:        VZ56-RIPE
admin-c:        REIS1-RIPE
admin-c:        EH4097-RIPE
admin-c:        MBT1-RIPE
admin-c:        LB470-RIPE
admin-c:        SB15220-RIPE
admin-c:        SB15220-RIPE
admin-c:        KUNO2-RIPE
admin-c:        HB3076-RIPE
admin-c:        LF1459-RIPE
admin-c:        KB6787-RIPE
admin-c:        CP12467-RIPE
admin-c:        DS22814-RIPE
admin-c:        ILKA2-RIPE
admin-c:        SL13187-RIPE
admin-c:        JS21561-RIPE
admin-c:        IRIS3-RIPE
abuse-c:        DTAG3-RIPE
mnt-ref:        RIPE-NCC-HM-MNT
mnt-ref:        DTAG-NIC
mnt-by:         RIPE-NCC-HM-MNT
mnt-by:         DTAG-NIC
created:        2004-04-17T11:12:44Z
last-modified:  2020-12-16T13:24:00Z
source:         RIPE # Filtered
person:         Sebastian Becker
address:        Deutsche Telekom AG
address:        Gartenstrasse 217
address:        DE 48147 Muenster
address:        Germany
phone:          +49 228 18123797
nic-hdl:        SB15220-RIPE
mnt-by:         DTAG-NIC
mnt-by:         DTAG-RR
created:        2011-11-01T16:24:28Z
last-modified:  2020-03-20T12:56:13Z
source:         RIPE # Filtered
% This query was served by the RIPE Database Query Service version 1.101 (BLAARKOP)
  • Bold: Object type.
  • Underlined: Primary key(s).
  • Hyperlinks: Searchable Attributes.
4 records found for 'AS3320'
Search for  
IP address lookups Miscellaneous queries
-l

1st level less specific

Returns smallest IP address range that includes the queried IP address or range

-i

Inverse attributes

Returns objects with an attribute that matches the query text and attribute type
-L

All less specific

Return all larger IP address ranges that include the queried IP address or range

-T

Object types

Results that match the query and are of a specified object type
-m

1st level more specific

Returns first level more specific address ranges within the boundaries of the queried IP address range
-M

All more specific

Returns all more specific address ranges within the boundaries of the queried IP address range

Query hints

  • Include "AS" in front of an AS number.
    Example: AS4808

  • Include "-t" (template only) or "-v" (template and description) in front of an object name to view the template
    Example: -t inetnum

-x

Exact match only

Returns address range that exactly matches the queried IP address range
-d

Associated reverse domain

Returns IP address range and associated reverse domain

For more information see: