Eltuntek a domain neveim - dotroll

Hálózatok általános

Udv!

A dotroll- nal van 17 darab domain nevem, amibol 13 darab .hu vegodesu. Ezek delelott meg elerhetoek voltak, most viszont egyaltalan nem:


host xyz.hu 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

Host xyz.hu not found: 2(SERVFAIL)

. A domain.hu ezt mondja ra:


M-GREET -I- [xyz.hu] Domi version 20190827 at 2019-09-14.17:34
M-STAR -I- [xyz.hu] NS parameter not given, getting it from DNS
M-SEC -I- [xyz.hu] secure delegation (DS found at parent)
M-PNAM -I- [xyz.hu] NS name: ns1.webspacecontrol.com
M-PADD -I- [xyz.hu] NS addr: 185.33.52.2
M-SOAR -E- [xyz.hu] SOA error at 185.33.52.2 over UDP

.

Probaltam hivni a dotroll- t, de legkozelebb csak hetfon lesznek.

Mit tudok ilyenkor tenni? Ez azert eleg nagy kieses.

Esetleg van aki meg szinten dotroll- nal van, es hasonlo problemaval kuzd?

  • 5964 megtekintés

( e704112 | 2019. 09. 14., szo – 19:40 )

A domain nevek termeszetesen nem jartak le... .

En jartam ugy (masik szolgaltatonal), hogy az egyik lejaro felben levo domain-hez kuldtek szamlat, amit jol elfelejtettem befizetni. Aztan amikor lejart a fizetesi hatarido, jol lekapcsoltak a domaint (ami OK, hiszen nem fizettem) de vele egyutt az osszes tobbit is ami meg a nevem alatt futott...

Ez abból a szempontból reális, hogy a szolgáltatók folyószámlát vezetnek az egyes ügyfelekhez. Ha az ügyfél folyószámláján tartozás jelentkezik, akkor korlátozzák az adott ügyfél szolgáltatásait. A folyószámla-tartozás szempontjából nem releváns, hogy a tartozás milyen szolgáltatás(ok)kal kapcsolatban jött létre.

Ez nalam most egyaltalan nem all fenn. Eleve ha nem fizetem ki elore a szolgaltatast, akkor nem is rendelik meg, legalabbis itt igy mukodik.

Viszont az mennyire megszokott, hogy nincs hetvegen semmilyen ugyfelszolgalat? Egy masik cegnel voltam korabban, akiknel volt, de amikor az a ceg megszunt, a dotroll vett at mindent.

A Domainregisztrációs Szabályzat alapján viszont nagyon nem reális, egészen konkrétan erre nincs lehetősége a szolgáltatónak.
(Arról nem is beszélve, hogy a fenntartást mindenhol előre kell fizetni, a nem fizetés nem keletkeztet tartozást, egyszerűen felmondásra kerül.)

Több mint 10 éve vagyok kapcsolatban velük. Messzemenően a legjobb partner eddig ebben a témában.
Szerveremnél 2x voltam, mind a kétszer HDD csere volt. Az ő hibájukból nem tapasztaltam leállást, kivéve a meghirdetettet. Volt amikor költöztették a gépemet két szekrény között újraindítás nélkül!

Mindez hogyan lehetséges? Úgy, hogy vevőként felfogom mi a dolgom: _CSAK_ fizetni! A többit ők csinálják.

( msandor v | 2019. 09. 15., v – 10:40 )

Belépve a dotrollhoz, mit látsz a domain neveid mellett? Nincs valami figyelmeztetés?

A technikai ellenorzesnel azt, amit a posztban irtam, a keresnel annyit, hogy a domain nev nem szabad, a domain-igenylonel pedig szinten helyes adatokat latok. Valami uj szabaly szerint most mar csak annyi van ott, hogy Termeszetes szemely, es nem az en nevem, vagy a cegem neve.

Amugy a NIC- nel nincs valami support igy vasarnap? :- ).


; <<>> DiG 9.10.3-P4-Ubuntu <<>> ns1.dotroll.hu xyz.hu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43551
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.dotroll.hu. IN A

;; Query time: 6 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sun Sep 15 20:53:21 CEST 2019
;; MSG SIZE rcvd: 32

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48950
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;xyz.hu. IN A

;; Query time: 48 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sun Sep 15 20:53:21 CEST 2019
;; MSG SIZE rcvd: 35

.

" ok tartananak mindent nyilvan, es nem nekem kellene buveszkednem" => single point of failure.
A dns pont egy olyan kritikus dolog, hogy nem érdemes egy szogláltatóra bízni.

cserébe pofon egyszerű (gondolom) a felállás, semmibe se kerül pl:
dns.he.net fele is letolni mindent és ta-daa a recordjaid nem esnek a ki a cache-ekből, a szolgáltatásaid elérhetőek maradnak (gondolom gépe(k)et) nem (csak) onnan veszel..

Még nem jelent meg. 17 domainre szerintem saját NS-t fenntartani luxus, pláne ha nincs vele tapasztalatod. A "használj saját slave"-et jellemzően azért halt ki, mert többen megunták, hogy rendszeresen eltűnt a slave aztán mindenki hibás volt és így sokan eleve nem engedik ezt a hibrid megoldást. Nem tudom, hogy a domainjeid egy CPanelen vannak-e esetleg és akkor a tárhellyel együtt tudod kezelni vagy valami egyéb megoldásban működsz, de ha hirtelen kell másik NS, akkor a CloudFlare (vagy bármi hozzá hasonló) ad neked ingyenes lehetőséget DNS onlyra.

Ha majd mégis saját NS-ezel gondold meg, hogy mennyire van hozzá két szolgáltatónál külön szervered (akár VPS persze) és hogy mennyire akarsz vele foglalkozni.

[off]
értelmező olvasás azért hiányzik:
1. "az is egy opció". Ha neked az akkor az. Ha tikkelsz tőle akkor valószínűleg neked nem az.
2. így is úgy is fizetsz azért, hogy van valamid ami működik:
- a) a saját idődből fizetsz érte
- b) megveszed szolgáltatás(ok)-ként.
mindenki eldöntheti.
[/off]

( lajos22 | 2019. 09. 16., h – 10:28 )

SUB!

Megoldódott?

--
openSUSE 42.2 x86_64

( csardij v | 2019. 09. 16., h – 17:05 )

Az webspacecontrol.com-os NS a tárhely szolgáltatós NS, ide a bökőt, hogy a domain tárhelyre volt felvéve ami most lett törölve... Csak nem éppen a tárhelyre mutatott az IP cím, aztán azért nem okozott eddig gondot.

van egy cpanel tárhelyed, annak van valami NS-e. De a cPanel-en beállíthatod, hogy egy 3rd place-re mutasson az IP cím. Így ha a tárhely suspendelve lesz, attól még minden megy, nem nézi az emaileket, nem veszi észre. Aztán ha terminálják, kikerül a zóna az NS-ekből és akkor nem megy semmi.

( dotroll | 2019. 09. 17., k – 09:58 )

A tárhely járt le júniusban ami a domain nevek DNS szolgáltatását tartalmazta. Júniusban járt le, akkor fel lett függesztve a tárhely de a DNSben még tartjuk a zónaadatokat 3 hónapig ezért csak most álltak meg a domainek. Most telefonos megbeszélésünk alapján átmásoltuk backupból a zónaadatokat a "nem" tárhelyes névszervereinkbe és átváltottuk a névszervereket.

ha jol ertem akkor user error volt a konkret eset.

viszont nem talalom (lehet hulyen keresek), hogy a support most 24/7-es vagy csak hetkoznap munkaidoben van. ha elobbi akkor miert nem valaszoltak a ticketre hogy "elszartad a konfigot, ecsem!"? ::felfelhuzossmile::

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

NEM NÁLATOK, de máshol én is jártam így. Kellemetlen volt nem is kicsit, örököltem a domaint és hagytam ott a névszervereket csak a tárhely került az ügyfél saját szerverére. Aztán újonc kollégára rábízhatták a takarítást így nem a tárhelyet dobta hanem a teljes Cpanel fiókot. Bár nem ismerem a Cpanel admin részét külön válik-e a dolog. A lényeg, hogy eltűnt a domain. Sajnos azt mindenkinek el kell fogadni lassan, ha tetszik ha nem, hogy ilyen munkaerőt lehet találni. Akik ennél jobban oda figyelnének alkalmazottként ezekre a dolgokra mind dolgoztok valószínű magasabb pozicióban mint a nevezzük operátornak. Vagy magasabb feladatkörben. Esetleg saját cégben, vállalkozásban próbálunk megélni. Akik maradtak ilyen munkakörre mind ilyen ( tisztelet a kivételnek, de az meg dolgozik és valszeg felelősség teljesebb munkát kap rövid időn belül ). Így a munkáltatónak is be kell érni ilyen emberekkel, meg lassan ügyfélnek is el kell fogadnunk ez van és ilyenek sűrűbben megtörténnek. Mielőtt szétfikáztok, igen lehet kicsit túlzó amit leírtam, de lehet, hogy nem... ki-ki milyen céges környezetben, ügyfél környezetben mozog, mit lát ebből. De szerintem általános.

és hagytam ott a névszervereket csak a tárhely került az ügyfél saját szerverére

Szerintem meg is van a közös pont, amit nem csinálunk: névszerver ÉS tárhely ugyanannál a szolgáltatónál. Innen eredezik a probléma. Eleve nem kell ugyanonnan venni a névszerver szolgáltatást, ahonnan bármi mást, és akkor nincs ilyen gond.

Akkor van baj, ha a szolgáltató csak tárhely + névszerver szolgáltatást tud adni, ahol mondjuk a tárhely ingyen van. Aztán a kutya nem néz felé éveken át, mert csak a névszervert használod, aztán egyszer csak kirántják a tárhelyet, mert mondjuk fizetős lett, de nem akarsz érte fizetni és megy a névszervered is a levesbe. Mint ahogy itt történt elvileg.

--
https://iotguru.live

Mondjuk, a domainhez a legtöbb helyen névszerver szolgáltatást is adnak. Nem _kell_ a tárhelyszolgáltatóét használni.

A topicnyitónál pedig még az is lehet, hogy csak 1 névszerver volt beállítva és az is az ingyen/próba tárhely szolgáltatására (vagy csak én nem értem a bemásolt részt :) )

Ne viccelj már, miért is ne lehetne a tárhely és a névszerver egyazon szolgáltatónál? A webtárhelyek 90+%-a szerintem így működik. A baj az volt az én esetemben, hogy a tárhely fel lett mondva a domain ki lett fizetve. Nem le lett kapcsolva a tárhely, hanem az egész fiók törölve lett tárhelyestől, zónástól.

( e704112 | 2019. 09. 17., k – 22:17 )

Itt szerintem tobb oldalrol is tortent hiba.

Roviden a tortenet az en olvasatomban:

sok- sok evvel ezelott egy masik szolgaltatonal voltak a domain- ek, amit a dotroll felvasarolt. Soha nem hasznaltam ott sem tarhelyet, de a migralas soran kaptam egy tarhelyet, ami ingyenes volt. Ez juniusban lejart. Akkor voltak problemak, egyeztettem is a dotrollal, meg is talaltam a feljegyzeseket, hogy atmasoltak mindent, ebbol nem lesz tobb problema.

Szombaton a jelek szerint letelt a 3 honap, toroltek a tarhelyet, es a juliusi masolas nem igazan sikerult. Ekkor tunt el az osszes .hu domain nevem. Szombaton irtam nekik levelet, hogy ez van, ez tortent, illetve irtam egy peldat a domain nevek kozul. Hetfo reggel telefonon beszeltem egy nem tul raero supportossal, aki azt mondta, hogy aznap megcsinaljak valamikor. Nehany ora alatt az egyik domainem helyre is jott, a tobbi viszont nem. Este lattam, hogy a hibajegyet megvalaszoltak, hogy keszen van.

A kedd reggeli beszelgetesen (egy mar sokkal raerobb) kollega megnezte, hogy sajnos csak 2 domain- t allitottak vissza a sokbol, abbol is az egyiket hibas adatokkal (lehet, hogy 3 volt, meg is neznem most a dotroll oldalan, de eppen valami cert hibat dob).

Mondhatja mindenki, hogy az en hibam, de en juniusban arrol kaptam visszajelzest, hogy minden rendben a tarhely torlesevel kapcsolatban, nem kell semmit tennem. Megjegyzem, en azt sem hiszem, hogy akkor hibaztam volna, hiszen - mint kiderult - a tarhelyhez volt kotve hosszu evekig, ami - ahogy ertettem - megszunt ingyenesnek lenni, am arrol mar nem kaptam levelet, hogy ha nincs tarhely, akkor nincs cpanel sem, es a dns bejegyzesek is megszunnek letezni.

Az is biztos, hogy a hibat hetfon sem sikerult helyreallitani, holott arrol irtak, hogy kesz, meg lett oldva.

Dotroll hiba

.

Persze, de amikor az arpanet korában elindultak a dolgok, akkor nem az észnélküli csapatás volt a cél. :) Elérhető például a Cloudflare DNS, ott mernék kis TTL-t használni, bár eleve van ott egy CDN feature ha akarjuk.

A módosításokat érdemes azért tervezni, és 2 nappal előre levenni a TTL-t, ahogy ez régen jólbeváltan ment. A DNS sosem arról szólt, hogy pánikszerűen 5 perc alatt álljunk át.

Node az hogy valamire használják, mert végülis meg lehet csinálni, az nem azt jelenti, hogy arra való. :) Ha ilyen DNS szolgáltatást használ valaki, akkor hajrá, de az nem pont a sima domainreges névszerver csomag lesz valszin. Nem véletlenül hoztam a cloudflare-t példának.

Hát az van, hogy ezzel szemben a gyakorlat az, hogy sok közbülső DNS-en egyszerűen felülvágják a minimum TTL-t. 30 perc alá, de 5 perc alá, nemnagyon érdemes állítani a tapasztalat szerint. Nyilván vannak extrém esetek, amikor pont a weboldal tulajánál lévő router saját cache-e nem hajlandó frissülni még 3 nap után se.

Nem. A DNS cache beállításban megadod, hogy a minimum TTL márpedig N másodperc és kész. Az ISP nem feltétlenül viszi túlzásba a névszerveres dolgot egyébként, szóval hiába van CF, meg Route55 meg szuperfelhő DNS, ha az ISP felülvágja, vagy eleve az nem is elérhető. Ettől függetlenül ha olyan a DNS infra, akkor persze lehet ott varázsolni, csak azzal tisztában kell lenni, hogy a kliens oldal az messze nem HA/failover/overtake/missioncritical stb.

A DNS cache beállításban megadod, hogy a minimum TTL márpedig N másodperc és kész. 

Hát pedig ebből Route 53 esetén nincs issue, szóval vagy mítosz az, hogy a szolgáltatók leszarják a DNS beállításokat vagy minimum a Google, Amazon és a Cloudflare picsán rúgja azokat az ISP-ket, ahol ilyennel próbálkoznak és attól kezdve nem próbálkoznak TTL violation trükkökkel...

https://iotguru.cloud

Több helyen használom a Route 53 geo és health alapú load-balance szolgáltatását, ebből van olyan, ahol nagy a globális forgalom, mértük a céggel többször is, a 60 másodperc az a 60 másodperc, nem téved oda órákkal később forgalom, ha ki van szedve az adott IP. Ezért mondom, hogy vagy egy legenda az, hogy ez széles körben elterjedt lenne vagy az ilyen DNS szolgáltatást nyújtó cégek a méretüknél fogva picsán rúgják azokat az ISP-ket, ahol ilyet csinálnak.

https://iotguru.cloud

pedig regen az upc csinalta. egy addig nem hasznalt domain nslookup-ra visszadott X idot (talan 1 ora, nem emlekszem), mikozben a ttl tokre mas volt. a 8888 vagy 1111 is a valid ttl adta vissza. az upc meg ragaszkodott fix idohoz. de mar nincs meg a screenshot. azota (lehet a voda infra atallasnal) leszoktak errol

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Az Amazon DNS szolgáltatása nincs még 12 éves. A Cloudflare mint cég sincs még 12 éves. A másodperces TTL alapú failover, load-balancing és geo-routing kb. 8 éves szolgáltatás ezeknél a cégeknél. A megadott TTL-től felfelé való eltérés TTL violation, lefelé bármikor el lehet térni, lévén ez egy cache, ahonnan bármikor kikerülhet a tartalom. És ugye ez egy fizetős szolgáltatás, amivel nem tapasztalható hiba, tehát vagy kivétellistán van az Amazon, a Cloudflare és a Google, ahol aktívan használják ezt a másodperces TTL-t, vagy már rég leszoktak róla a szolgáltatók, mert kapták a DNSMON-on keresztül vagy közvetlenül az említett cégektől a TTL violation figyelmeztetéseket... vélhetően másképp reagál egy szolgáltató, ha Gipsz Jakab veri az asztalt a TTL violation miatt vagy ha az Amazon ír egy automatikus levél, hogy ha nem rendeződik a helyzet, akkor kompletten blokkolja az ISP-t. Nem kedvelem a túl nagyra nőtt cégeket, de amikor ilyen módon élnek vissza a piaci fölényükkel, akkor nagyon egyet tudok érteni.

https://iotguru.cloud

A DNS sosem arról szólt, hogy pánikszerűen 5 perc alatt álljunk át.

Dehogynem, erre még feature is épül, hogy ha egy IP halmazból egy IP kiesik, akkor a DNS szolgáltató nem oldja fel a nevet arra az IP-re, amíg meg nem javul az IP mögötti szolgáltatás.

https://iotguru.cloud

? :) Ez nem DNS feature, hanem azért erre rá kell dolgozni, hogy kikerüljön az adott rekordok közül az átmenetileg nem elérhető. Vagy eleve spéci névszervert használnak, ami az adott cluster része, de ez csak a technológiai lehetőségek tág értelmezése. Az 1 perces TTL erre lehetőséget ad, egészen addig, amíg valahol közbülsőleg nem dönt egy DNS cache, hogy ő márpedig egy órát cache-el minimum, vagy esetleg olyan szinten beragad, hogy újra kell indítani.

Csináltunk anno sima faék egyszerűséggel DNS alapon roundrobint, működött egész jól, sőt ott a timeout után a kliens továbbmegy a következő IP-re, csak bután néz ki, hogy mondjuk 30-60mp-et malmozik valami. Ez különösen ma, a mindentazonnal világában. :) Igen, biztosan csináltunk olyat, hogy átmenetileg kézzel kivettünk karbantartós gépet a halmazból, node ettől még ez nem a failover netovábbja. :)

Kurva olcsó alapvetően maga a szolgáltatás (viszonylag nagy forgalomnál is 10 dollár per hónap alatt vagyok, bármi egyéb load-balancer drágább ennél), és nyoma nincs azoknak a nyűgöknek, amiket írtál, hogy vannak. És ugyanazon a DNS infrán megy, ami elvileg nem erre való.

https://iotguru.cloud

"Az éjszaka folyamán a névszerverünket a DDOS támadás érte, ezért nem volt elérhető.

Rendszergazdáink ezt azonnal érzékelték és megkezdték a támadás elhárítását, melyet rövid időn belül el is végeztek.

A névszerver szolgáltatás jelenleg zavartalanul működik."

( persicsb | 2022. 07. 20., sze – 14:26 )

A dotroll tegnap is megadta magát, sok ott regisztrált domain este nem volt elérhető, mert az authoritative névszerver nem válaszolt.

( Ar0n v | 2022. 07. 20., sze – 17:00 )

Szerkesztve: 2022. 07. 20., sze – 17:00

Regisztrald at mashoz! Ilyen nincs, hogy nem lehet elerni senkit ...