WHOIS Lookup
Look up the registration record for a domain or an IP block, RDAP first, with port 43 WHOIS as the fallback.
Enter a domain or an address. We query RDAP first, the structured JSON successor to WHOIS, and fall back to port 43 WHOIS where a registry runs none. A domain returns the registrar, creation and expiry dates, nameservers, and EPP status codes, and an address returns the RIR, netname, organisation, country, and abuse contact. Personal details are usually redacted under privacy law, and results cache for six hours.
AS recordAS3320
Structured RDAP from rdap.db.ripe.net.
Allocation
- AS number
- AS3320
- Netname
- DTAG
- Holder
- DTAG-RR
- Country
- Not published
- Registry
- RIPE — RIPE Network Coordination Centre
- Block
- Not published
- Registered
- 1970-01-01T00:00:00Z
- Last changed
- 2020-12-11T15:33:02Z
- Abuse contact
- abuse@telekom.de
- Status
- active
- Registry server
- rdap.db.ripe.net
Raw RDAP JSON
{
"handle": "AS3320",
"startAutnum": 3320,
"endAutnum": 3320,
"name": "DTAG",
"status": [
"active"
],
"entities": [
{
"handle": "DTAG-RR",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
"fn",
{},
"text",
"DTAG-RR"
],
[
"kind",
{},
"text",
"individual"
]
]
],
"roles": [
"registrant"
],
"links": [
{
"value": "https://rdap.db.ripe.net/autnum/3320",
"rel": "self",
"href": "https://rdap.db.ripe.net/entity/DTAG-RR"
},
{
"value": "http://www.ripe.net/data-tools/support/documentation/terms",
"rel": "copyright",
"href": "http://www.ripe.net/data-tools/support/documentation/terms"
}
],
"objectClassName": "entity"
},
{
"handle": "ORG-DTA2-RIPE",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
"fn",
{},
"text",
"Deutsche Telekom AG"
],
[
"kind",
{},
"text",
"org"
],
[
"adr",
{
"label": "Eduard-Schopf-Allee 1\nD-28217\nBremen\nGERMANY"
},
"text",
[
"",
"",
"",
"",
"",
"",
""
]
],
[
"tel",
{
"type": "voice"
},
"text",
"+4942151555165"
],
[
"tel",
{
"type": "voice"
},
"text",
"+4942151554041"
],
[
"tel",
{
"type": "fax"
},
"text",
"+49391580100379"
]
]
],
"roles": [
"registrant"
],
"links": [
{
"value": "https://rdap.db.ripe.net/autnum/3320",
"rel": "self",
"href": "https://rdap.db.ripe.net/entity/ORG-DTA2-RIPE"
},
{
"value": "http://www.ripe.net/data-tools/support/documentation/terms",
"rel": "copyright",
"href": "http://www.ripe.net/data-tools/support/documentation/terms"
}
],
"objectClassName": "entity"
},
{
"handle": "RIPE-NCC-END-MNT",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
"fn",
{},
"text",
"RIPE-NCC-END-MNT"
],
[
"kind",
{},
"text",
"individual"
],
[
"org",
{},
"text",
"ORG-NCC1-RIPE"
]
]
],
"roles": [
"registrant"
],
"links": [
{
"value": "https://rdap.db.ripe.net/autnum/3320",
"rel": "self",
"href": "https://rdap.db.ripe.net/entity/RIPE-NCC-END-MNT"
},
{
"value": "http://www.ripe.net/data-tools/support/documentation/terms",
"rel": "copyright",
"href": "http://www.ripe.net/data-tools/support/documentation/terms"
}
],
"objectClassName": "entity"
},
{
"handle": "SB15220-RIPE",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
"fn",
{},
"text",
"Sebastian Becker"
],
[
"kind",
{},
"text",
"individual"
],
[
"adr",
{
"label": "Deutsche Telekom AG\nWolbecker Str. 268, 48155, Muenster, Deutschland"
},
"text",
[
"",
"",
"",
"",
"",
"",
""
]
],
[
"tel",
{
"type": "voice"
},
"text",
"+49 228 18123797"
]
]
],
"roles": [
"administrative",
"technical"
],
"links": [
{
"value": "https://rdap.db.ripe.net/autnum/3320",
"rel": "self",
"href": "https://rdap.db.ripe.net/entity/SB15220-RIPE"
},
{
"value": "http://www.ripe.net/data-tools/support/documentation/terms",
"rel": "copyright",
"href": "http://www.ripe.net/data-tools/support/documentation/terms"
}
],
"objectClassName": "entity"
},
{
"handle": "DTAG3-RIPE",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
"fn",
{},
"text",
"Deutsche Telekom LIR Abuse Contact"
],
[
"kind",
{},
"text",
"group"
],
[
"adr",
{
"label": "Deutsche Telekom AG"
},
"text",
[
"",
"",
"",
"",
"",
"",
""
]
],
[
"email",
{
"type": "abuse"
},
"text",
"abuse@telekom.de"
]
]
],
"roles": [
"abuse"
],
"entities": [
{
"handle": "DTAG-NIC",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
"fn",
{},
"text",
"DTAG-NIC"
],
[
"kind",
{},
"text",
"individual"
]
]
],
"roles": [
"registrant"
],
"links": [
{
"value": "https://rdap.db.ripe.net/autnum/3320",
"rel": "self",
"href": "https://rdap.db.ripe.net/entity/DTAG-NIC"
},
{
"value": "http://www.ripe.net/data-tools/support/documentation/terms",
"rel": "copyright",
"href": "http://www.ripe.net/data-tools/support/documentation/terms"
}
],
"objectClassName": "entity"
},
{
"handle": "DTAG1-RIPE",
"vcardArray": [
"vcard",
[
[
"version",
{},
"text",
"4.0"
],
[
"fn",
{},
"text",
"DTAG Internet Routing Registry"
],
[
"kind",
{},
"text",
"group"
],
[
"adr",
{
"label": "Deutsche Telekom Service GmbH\nInternet Services\nEduard-Schopf-Allee 1\nDE 28217 Bremen"
},
"text",
[
"",
"",
"",
"",
"",
"",
""
]
]
]
],
"roles": [
"administrative",
"technical"
],
"links": [
{
"value": "https://rdap.db.ripe.net/autnum/3320",
"rel": "self",
"href": "https://rdap.db.ripe.net/entity/DTAG1-RIPE"
},
{
"value": "http://www.ripe.net/data-tools/support/documentation/terms",
"rel": "copyright",
"href": "http://www.ripe.net/data-tools/support/documentation/terms"
}
],
"objectClassName": "entity"
}
],
"objectClassName": "entity"
}
],
"remarks": [
{
"description": [
"Internet service provider operations",
"peering coordinators for AS3320: <peering@telekom.de>",
"abuse reports should be sent to the contacts listed in the registry entries for the IP address of the offending host system",
"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.",
"the most important and helpful use of the IRR is to publish what a network will announce to peers and upstream",
"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)",
"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)",
"in fact we apply route filters based on this for all neighbors - as far as feasible",
"for data published through the RIPE routing registry we generate filters automatically",
"we consider the integration of RIR and routing registry data and the application of RPSS authorization a great feature of the RIPE routing registry",
"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)",
"this will be sufficient to have our peers accept the routes",
"in any case peers - and any network in the Internet - is free to apply some selective policy (e.g. prefix length based)",
"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",
"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",
"============================================================== IPv6 we do/publish essentially the same like for IPv4",
"=============================================================="
]
}
],
"links": [
{
"value": "https://rdap.db.ripe.net/autnum/3320",
"rel": "rdap-up",
"href": "https://rdap.db.ripe.net/autnums/rirSearch1/rdap-up/AS3320",
"type": "application/rdap+json"
},
{
"value": "https://rdap.db.ripe.net/autnum/3320",
"rel": "rdap-up rdap-active",
"href": "https://rdap.db.ripe.net/autnums/rirSearch1/rdap-up/AS3320?status=active",
"type": "application/rdap+json"
},
{
"value": "https://rdap.db.ripe.net/autnum/3320",
"rel": "rdap-down",
"href": "https://rdap.db.ripe.net/autnums/rirSearch1/rdap-down/AS3320",
"type": "application/rdap+json"
},
{
"value": "https://rdap.db.ripe.net/autnum/3320",
"rel": "rdap-top",
"href": "https://rdap.db.ripe.net/autnums/rirSearch1/rdap-top/AS3320",
"type": "application/rdap+json"
},
{
"value": "https://rdap.db.ripe.net/autnum/3320",
"rel": "rdap-top rdap-active",
"href": "https://rdap.db.ripe.net/autnums/rirSearch1/rdap-top/AS3320?status=active",
"type": "application/rdap+json"
},
{
"value": "https://rdap.db.ripe.net/autnum/3320",
"rel": "rdap-bottom",
"href": "https://rdap.db.ripe.net/autnums/rirSearch1/rdap-bottom/AS3320",
"type": "application/rdap+json"
},
{
"value": "https://rdap.db.ripe.net/autnum/3320",
"rel": "self",
"href": "https://rdap.db.ripe.net/autnum/3320",
"type": "application/rdap+json"
},
{
"value": "http://www.ripe.net/data-tools/support/documentation/terms",
"rel": "copyright",
"href": "http://www.ripe.net/data-tools/support/documentation/terms"
}
],
"events": [
{
"eventAction": "registration",
"eventDate": "1970-01-01T00:00:00Z"
},
{
"eventAction": "last changed",
"eventDate": "2020-12-11T15:33:02Z"
}
],
"rdapConformance": [
"nro_rdap_profile_asn_flat_0",
"rirSearch1",
"autnums",
"cidr0",
"rdap_level_0",
"nro_rdap_profile_0",
"redacted"
],
"notices": [
{
"title": "Filtered",
"description": [
"This output has been filtered."
]
},
{
"title": "Whois Inaccuracy Reporting",
"description": [
"If you see inaccuracies in the results, please visit:"
],
"links": [
{
"value": "https://rdap.db.ripe.net/autnum/3320",
"rel": "inaccuracy-report",
"href": "https://www.ripe.net/contact-form?topic=ripe_dbm&show_form=true",
"type": "text/html"
}
]
},
{
"title": "Source",
"description": [
"Objects returned came from source",
"RIPE"
]
},
{
"title": "Terms and Conditions",
"description": [
"This is the RIPE Database query service. The objects are in RDAP format."
],
"links": [
{
"value": "https://rdap.db.ripe.net/autnum/3320",
"rel": "terms-of-service",
"href": "http://www.ripe.net/db/support/db-terms-conditions.pdf",
"type": "application/pdf"
}
]
}
],
"port43": "whois.ripe.net",
"objectClassName": "autnum",
"redacted": [
{
"name": {
"description": "Personal e-mail information"
},
"reason": {
"description": "Personal data"
},
"prePath": "$.entities[?(@.handle=='ORG-DTA2-RIPE')].vcardArray[1][?(@[0]=='e-mail')]",
"method": "removal"
},
{
"name": {
"description": "Personal e-mail information"
},
"reason": {
"description": "Personal data"
},
"prePath": "$.entities[?(@.handle=='SB15220-RIPE')].vcardArray[1][?(@[0]=='e-mail')]",
"method": "removal"
},
{
"name": {
"description": "Personal e-mail information"
},
"reason": {
"description": "Personal data"
},
"prePath": "$.entities[?(@.handle=='DTAG3-RIPE')].vcardArray[1][?(@[0]=='e-mail')]",
"method": "removal"
}
]
}Cached for six hours. The same record as JSON: /api/v1/rdap. Add &raw=1 for the unmodified registry document.
RDAP first, WHOIS as a fallback
RDAP gives us typed fields, so the normalised view on this page is a mapping rather than a guess. Classic WHOIS output has no schema at all; each registry invented its own labels, and parsing it reliably is a losing game. When a registry publishes no RDAP endpoint, usually an older country-code registry, we fall back to a port 43 query and show the raw text with only light normalisation. The result labels which path was used.
Reading the raw output
The raw response stays collapsed under the normalised view. Open it when a field looks wrong, when the registry publishes something we did not map, or when you need the exact text for a dispute or a transfer request. Registry text is authoritative; our normalisation is a convenience.
Caching
Results cache for six hours. WHOIS and RDAP data changes on the scale of days, registries rate-limit aggressively, and hammering them for a value that did not move helps nobody. If you need a fresh read after a change you just made, wait out the cache rather than retrying in a loop.
About this tool
Enter a domain or an address. We query RDAP first, the structured JSON successor to WHOIS, and fall back to port 43 WHOIS where a registry runs none. A domain returns the registrar, creation and expiry dates, nameservers, and EPP status codes, and an address returns the RIR, netname, organisation, country, and abuse contact. Personal details are usually redacted under privacy law, and results cache for six hours.
How to read the result
- Registrar
- The accredited company through which the domain was registered, which is where it was bought rather than who owns it. A transfer changes this field while the registrant stays the same.
- Creation, updated, and expiry dates
- Registry timestamps in UTC for when the domain was created, last changed, and paid through. The expiry date is the paid-through date, not the deletion date, and after it a domain usually passes through a renewal grace period, then redemption, then pending-delete, roughly 75 days in total.
- Nameservers
- The nameservers recorded at the registry as the delegation for this domain. They can differ from the NS records the zone itself serves, when a zone was changed without updating the delegation, which is a lame delegation.
- EPP status codes
- Registry and registrar locks that say what can be done with the domain right now. clientTransferProhibited is normal and prevents unauthorised transfers, serverHold means the domain is not published in the zone at all, and pendingDelete and redemptionPeriod mean an expired domain is moving toward deletion.
- Registrant details or a redaction notice
- For most generic and European domains the registrant name, address, and email are withheld under GDPR and ICANN Temporary Specification policy, leaving a registrar-operated forwarding address. Some country registries publish more, and business registrations often do.
- For IP addresses, RIR, netname, org, and abuse contact
- The Regional Internet Registry that allocated the block, the registered netname, the holding organisation, and the abuse mailbox to complain to. For a hosting provider the organisation is the provider rather than their customer, and that mailbox is where a complaint about the customer goes.
Questions people ask
- Why is the WHOIS record for a domain redacted?
- The GDPR took effect in 2018 and ICANN issued a Temporary Specification requiring registries and registrars to withhold personal data from public output. Most contact fields for private registrants are now replaced with a redaction notice and a forwarding address. Legitimate access requests go through the registrar or the RDAP tiered-access process.
- What is the difference between WHOIS and RDAP?
- WHOIS is a plain-text protocol from 1982 with no consistent format, no authentication, and no internationalisation. RDAP returns structured JSON over HTTPS, supports differentiated access, and is standardised in RFC 7480 through 7484. ICANN has required RDAP for gTLDs since 2019, and it is the source we prefer.
- Can I find who owns an IP address?
- You can find the organisation the block is registered to, which for a datacenter address is the hosting provider rather than the customer running the machine. Smaller allocations sometimes name the end customer in the netname. There is no public record linking a residential address to a person.
- The domain looks unregistered but I cannot buy it. Why?
- Check the status codes. redemptionPeriod and pendingDelete mean a previous registration expired and is still working through the deletion sequence, which takes about 75 days total. Some registries also reserve names or hold them at premium pricing without showing a registration.
- Is a WHOIS lookup visible to the domain owner?
- Not through the query itself. RDAP and WHOIS queries go to the registry or registrar, not to the domain holder. Registries log queries and rate-limit them, so heavy automated querying gets throttled or blocked.
Related
Last reviewed 2026-09-05.