Oma domeeni saidi serverihalduri uurimine 'aguse.jp' abil

Niin-öelda iseseisval domeenil töötava veebisaidi artiklite puhul, kui soovite teha kustutamis- või postitaja IP-aadressi avalikustamise taotlusi, on need taotlused suunatud peamiselt kahele osapoolele:

1. Saidi haldajale (enamasti kattub see domeeni registreerijaga)
2. Veebiserveri administraatorile

Näiteks kustutamistaotluse korral võite:

1. Pöörduda saidi haldaja poole palvega: “Ma olen saanud teie hallataval saidil laimuohvriks, palun kustutage see artikkel”
2. Pöörduda veebiserveri administraatori poole palvega: “Ma olen saanud laimuohvriks saidil, mida teie hallatav server majutab, palun kustutage see artikkel”

Lihtsustatult öeldes on internetis avaldatud artikli kustutamistaotluse adressaat:

• Isik, kellel on õigus see artikkel kustutada
• Isik, kes on seotud artikli internetis avaldamisega mõõdukalt või rohkem ning kes peaks seaduse järgi selle artikli kustutama

Need taotlused on võimalik esitada nii saidi haldajale kui ka veebiserveri administraatorile, kuna mõlemad vastavad neile kriteeriumidele. IP-aadressi avalikustamise taotluse puhul on loogiline struktuur erinev, kuid järeldus on sama.

Mida tähendab “veebiserveri administraatori uurimine”

Kuid kes on konkreetne isik, kes on “veebiserveri administraator, kes haldab saiti, mis töötab oma domeeninime all”? Näiteks, kes on konkreetne isik meie saidi (Monolise õigusbüroo sait) puhul?

Selleks, et teada saada, kes on veebiserveri administraator, kes haldab saiti, mis töötab oma domeeninime all, selgitame, kuidas kasutada veebiteenust nimega “aguse.jp”.

Veebisaidi haldaja = domeeni registreerija uurimismeetod

Nagu alguses mainisin, on võimalik nõuda artikli kustutamist või IP-aadressi avalikustamist, kui saidi haldaja on teada. Eradomeeni puhul langeb saidi haldaja enamasti kokku domeeni registreerijaga. Eradomeeni registreerija kohta saab teavet uurida “whois” süsteemi abil. Selle meetodi kohta on selgitusi teises artiklis.

https://monolith.law/reputation/ansi-whois-howto[ja]

Veebiserveri administraatori uurimismeetodid

Enamikul juhtudel kasutatakse isikliku domeeniga saite, mida nimetatakse rendiserveriteks. “Isikliku domeeniga saitide” puhul on see üldiselt järgmine:

1. Kõigepealt kasutage domeeni registreerimisteenust (domeeni registraatorit), nagu “onamae.com” või “GoDaddy”, et saada isiklik domeen
2. Seejärel sõlmige leping rendiserveriga, nagu “Sakura Internet”, et tagada veebiserver, mis hostib teie veebisaiti
3. Seadistage nii, et kui proovite juurde pääseda selle domeeni URL-ile, ühendub see veebiserveriga

See on avamise protsess.

“aguse.jp” kasutusjuhend

Ja selleks, et uurida seda veebiserverit, on üsna laialdaselt kasutusel veebiteenus nimega “aguse.jp”.

“aguse.jp” kasutamine on lihtne. Kõigepealt sisestage avalehel uurimiseks vajalik URL. Sel juhul on vajalik info URL-i

http://www.Monolith-law.jp/article/index.html

osa kuni “www.Monolith-law.jp”. Seda osa nimetatakse “hostinimeks”.

Näiteks ülaltoodud juhul on “/article” allpool asuv info nagu veebilehe asukoht serveris ja see pole vajalik serveri tuvastamiseks. Teisalt on “www” osa “alamdomeen”, mida saab paigaldada ükskõik kui palju ühele unikaalsele domeenile (Monolith-law.jp), kuid kui alamdomeen on erinev, võib veebiserver olla erinev. Teisisõnu, kui on olemas

https://monolith-law.jp
http://www2.Monolith-law.jp
http://blog.Monolith-law.jp

mitu alamdomeeni, siis iga alamdomeeni puhul võib veebiserver olla erinev. See erineb domeeni registreerija info uurimisest “whois” abil.

Kuidas lugeda “aguse.jp” uurimistulemuste lehekülge

Kui klõpsate nupul “Uuri”, kuvatakse uurimistulemuste lehekülg.

“Tagurpidi hostinimi” näitab veebiserveri “hostinime”, mis hostib vastavat veebisaiti.

Ja “IP-aadressi ●●.●●.●●.●● haldaja teave”, mis on kuvatud, on teave vastava veebiserveri haldaja kohta.

Administraatori uurimismeetodid

Kui otsite Google’is siin kuvatavat teksti, saate veebiserveri administraatori kindlaks teha. Sel juhul selgus, et “Sakura Internet Inc.” haldab “www.Monolith-law.jp”.

Kuidas “aguse.jp” oma uurimistööd teeb?

Veebiteenuse “aguse.jp” kasutamine on põhimõtteliselt lõppenud ülaltoodud kirjeldusega, kuid selgitame lähemalt, milline tehniline töötlus toimub sel ajal, miks saame selle meetodiga kontrollida veebiserveri administraatori teavet, mis hostib ainulaadset domeeni saiti. Lõppude lõpuks, kui me ei mõista, “mida nad teevad”, ei suuda me toime tulla isegi erandlike olukordadega.

“IP-aadress” on aadress internetis

Alustuseks, see lugu algab küsimusest “Mis on IP-aadress?”. IP-aadress on teave, mida kõik internetiga ühendatud masinad (põhimõtteliselt) ainulaadselt omavad ja mida nimetatakse ka “aadressiks internetis”. Näiteks kui vaatate seda veebisaiti oma nutitelefonis, on sellel nutitelefonil oma ainulaadne IP-aadress.

Ja nagu seadmel (näiteks nutitelefonil), mis veebisaiti vaatab, on oma ainulaadne IP-aadress, on ka veebisaidil ja veebiserveril, mis seda saiti hostib, oma ainulaadne IP-aadress. Internetis olevate masinate vaheline suhtlus, näiteks “Monolis advokaadibüroo veebisaidi vaatamine nutitelefonis”, toimub alati masinate vahel, millel on ainulaadne IP-aadress.

IP-aadressiga ●●.●●.●●.●● nutitelefoni ja
IP-aadressiga ●●.●●.●●.●● veebiserveri vahel
vahetatakse veebilehe andmeid jne

See on “veebisaidi vaatamine interneti kaudu”.

“URL” ja “veebiserveri IP-aadressi” suhe

Kuid tavaliselt, kui inimesed sirvivad internetti, ei mõtle nad teadlikult veebisaidi (täpsemalt selle hostiva veebiserveri) IP-aadressile. Nagu eespool mainitud, toimub IP-aadressi põhine suhtlus peamiselt nutitelefoni ja muude seadmete sisemuses ning kasutajad ei pea “IP-aadressi” teadlikult meeles pidama. Selle asemel, mida kasutajad teadlikult mõtlevad, on URL.

https://monolith.law/article/index.html

Kasutajad sirvivad internetti, olles teadlikud sellistest URL-idest. Kui kasutaja üritab avada ülaltoodud tüüpi URL-i, teeb nutitelefoni või muu seade järgmist:

1. Esiteks uurib see URL-i (veebiserveri, mis hostib veebisaiti) IP-aadressi
2. Seejärel suhtleb see IP-aadressiga

See on protsess, mida seade teostab.

Mis on “otsene viide” hostinimele

Eelnevalt mainitud 1. protsess, st URL-i (täpsemalt URL-i osa “www.Monolith-law.jp”, mida nimetatakse “hostinimeks”) teisendamine IP-aadressiks, on tuntud kui “otsene viide”.

Kui uurite URL-i “aguse.jp”, siis “IP-aadressi” all kuvatav teave on IP-aadress, mis saadakse vastava URL-i (täpsemalt selle hostinime osa) “otsese viite” abil.

Mis on IP-aadressi “tagasitõmbamine”

“Tagasitõmbamine” on “otsene tõmbamine” vastand, see tähendab, protsess, milles IP-aadress muudetakse hostinimeks.

“aguse.jp” “tagasitõmmatud hostinime” kuvatakse järgmiselt:

1. URL-i (hostinime osa) otsene tõmbamine
2. seejärel tagasitõmmatud hostinimi

See on see.

Keeruline osa on see, et kui teete “otsese tõmbamise → tagasitõmbamise”, siis kohandatud domeeni saitide puhul ilmub rendiserveri hostinimi. See süsteem on natuke keeruline, kuid selgitan seda allpool lihtsalt.

Mis on “nimeserver”

Esiteks, “tagasipöördumine” ei ole interneti kasutamisel hädavajalik protsess. Nagu eespool mainitud, toimub tavalise veebis surfamise ajal “otsene viide”, kus “uuritakse veebiserveri IP-aadressi URL-i alusel”, kuid “tagasipöördumist” ei esine tavalise veebis surfamise (või tavalise internetiühenduse) ajal. Ja see “otsene viide” kasutab “nimeserverit”.

1. Esiteks uuritakse selle URL-i (veebiserveri, mis hostib veebisaiti) IP-aadressi
2. Seejärel suheldakse selle IP-aadressiga

Täpsemalt öeldes, esimese punkti ajal toimub järgmine:

1. Küsitakse nimeserverilt URL-i (veebiserveri hostinime, mis hostib veebisaiti), millele soovitakse juurde pääseda
2. Nimeserver vastab selle URL-i (veebiserveri hostinime, mis hostib veebisaiti) IP-aadressiga

Seega, nimeserver hoiab justkui sõnaraamatuna “hostinime ja sellele vastava IP-aadressi” määramise teavet.

“Nimeserverid” ja “juurnimeserverid”

Internetis on lugematul hulgal nimeservereid. Nagu eespool mainitud, toimub päringute töötlemine suures koguses internetis surfamise käigus. Kui näiteks üks nimeserver vastaks kõigile interneti kogu ulatuses tehtavatele päringutele, muutuks serveri koormus tohutuks. Seetõttu on nimeservereid lugematult ja need on paigutatud puustruktuuri, mille alguspunktiks on “juurnimeserver”, nimeserverite meister. Näiteks on juurnimeserveri all nimeserverid (näiteks A, B) ja nimeserveri A all on teised nimeserverid (näiteks C, D).

Internetis on soovitav, et kõik nimeserverid hoiaksid alati sama sõnastiku teavet, kuid selle saavutamine tooks kaasa tohutu koormuse. Seetõttu ei tehta täielikku sünkroniseerimist. Süsteem toimib nii, et “kui teave on kusagil puustruktuuris olevas nimeserveris, siis saab vastuse saada, kui päringuid teha järjest”.

Mis on IP-aadressi “tagasitõmbamine”?

“Tagasitõmbamise” korral tehakse päringud järjest juur-nimiserverist teistesse nimiserveritesse. See on vastupidine päring tavapärasele päringule (ehk “edasitõmbamise” korral tehtavale päringule), mis palub vastata küsimusele “Mis on hostinimi, mis vastab IP-aadressile ●●.●●.●●.●●?”. Selle päringu vastus on enamasti seotud veebiserveriga, mis hostib vastavat veebisaiti. Näiteks:

• Kui “edasitõmbame” hostinime “Monolith-law.jp”, on vastuseks antav IP-aadress “59.106.27.183”
• Kui “tagasitõmbame” IP-aadressi “59.106.27.183”, on vastuseks antav hostinimi (mitte “Monolith-law.jp”, vaid) “www1943.sakura.ne.jp”

See on nii.

Ja hostinimi, mis on “seotud veebiserveriga, mis hostib vastavat veebisaiti”, sisaldab rendiserveri puhul rendiserveri teenusepakkuja domeeni, antud juhul “sakura.ne.jp”.

Rendiserveri teenusepakkuja domeeni whois-teave

Rendiserveri teenusepakkujad registreerivad enamasti whois’is korrektseid andmeid.

Seega, kui uurida seda domeeninime “whois” kaudu, saab hankida selle rendiserveri teenusepakkuja teabe. Ülaltoodud näites on “operaatororganisatsioon” “SAKURA Internet Inc.”

Kokkuvõte

Nagu näha, on “uurida rendiserveri teenusepakkujat, kes haldab hosting serverit, et teha kustutamis- või IP-aadressi avalikustamise taotlusi saidile, mis töötab oma domeenil” väga keeruline teema IT mõttes. Selles artiklis selgitatud teave on vaid “põhiline” ja kui tekib probleem, mida ei saa lahendada ainult põhiteadmistega, siis “kuidas seda probleemi lahendada” muutub “rakenduseks”.

Internetis leviva mainekahju vastu võitlemine on seega väga spetsialiseeritud nii IT kui ka õiguse mõttes.