Több osztrák (.at TLD) domain esetében beleütköztem abba a problémába, hogy a BIND 9 azt mondja rekurzív feloldás esetén, hogy SERVFAIL, viszont a nagyobb szolgáltatók rekurzív DNS szerverei (Google, CloudFlare, stb.) szerint feloldható a zóna.
Lássuk példának a "morenet.at" domaint. A "at" zónában benne vannak az NS rekordok, glue rekorddal, IP címmel:
dig @ns1.univie.ac.at. morenet.at
;; AUTHORITY SECTION:
morenet.at. 10800 IN NS ns1.morenet.at.
morenet.at. 10800 IN NS ns2.morenet.at.
morenet.at. 10800 IN NS ns3.morenet.at.
;; ADDITIONAL SECTION:
ns1.morenet.at. 10800 IN AAAA 2a01:4f8:0:a101::a:1
ns2.morenet.at. 10800 IN AAAA 2a01:4f8:d0a:2004::2
ns3.morenet.at. 10800 IN AAAA 2001:67c:192c::add:a3
ns1.morenet.at. 10800 IN A 213.239.242.238
ns2.morenet.at. 10800 IN A 213.133.105.6
ns3.morenet.at. 10800 IN A 193.47.99.3Viszont, ha a zóna fent hivatkozott szervereit nézzük, akkor nincs bennük sem "NS" rekord, sem a hozzá tartozó "A" rekord:
dig @213.239.242.238 morenet.at ns
morenet.at. 3600 IN SOA hydrogen.ns.hetzner.com. dns.hetzner.com. 2025110803 86400 10800 3600000 3600illetve
dig @213.239.242.238 ns1.morenet.at a
morenet.at. 3600 IN SOA hydrogen.ns.hetzner.com. dns.hetzner.com. 2025110803 86400 10800 3600000 3600Ha a saját rekurzív DNS szerveremmel csinálok egy lekérdezést, akkor ezt kapom:
dig ns1.morenet.at a +trace
; <<>> DiG 9.20.11-4-Debian <<>> ns1.morenet.at a +trace
;; global options: +cmd
. 518177 IN NS i.root-servers.net.
. 518177 IN NS g.root-servers.net.
. 518177 IN NS a.root-servers.net.
. 518177 IN NS k.root-servers.net.
. 518177 IN NS j.root-servers.net.
. 518177 IN NS d.root-servers.net.
. 518177 IN NS e.root-servers.net.
. 518177 IN NS m.root-servers.net.
. 518177 IN NS f.root-servers.net.
. 518177 IN NS c.root-servers.net.
. 518177 IN NS h.root-servers.net.
. 518177 IN NS b.root-servers.net.
. 518177 IN NS l.root-servers.net.
. 518177 IN RRSIG NS 8 0 518400 20251123050000 20251110040000 61809 . 6jL4QcWAw7hj6jLdO3Jk1pLz6R1usptIWhrwQpiHj1g3VhdrCpraptj4 ZMfnIRTt58FnDTAprh/3HCxWo/8Rmx9gXkJhpUF3bYv5jf/wDR+ywmnf /74csd2Z7kHQBoHCogor+FvBqg4/HoSpPl6mbXCoon9OfU4VKLj+2513 esHSN0j+oowt+xhoh/ncHrerLuY7d1zzsyPlIiiLtKoPHkNk+rC4+Ysv uiBXr/zvE5haKpdPCYVXja2GNWTlBnd5doqyjIM95c1K/hJF02kuNYit H3dYSzQw9XulWmItfvWQ7Ub5SMXKa+ivAWT9qrXu1KdwffkXi5r7l1Kz Rfgokw==
;; Received 1125 bytes from 172.28.0.1#53(172.28.0.1) in 0 ms
at. 172800 IN NS d.ns.at.
at. 172800 IN NS j.ns.at.
at. 172800 IN NS n.ns.at.
at. 172800 IN NS r.ns.at.
at. 172800 IN NS u.ns.at.
at. 172800 IN NS ns1.univie.ac.at.
at. 172800 IN NS ns2.univie.ac.at.
at. 86400 IN DS 1253 13 2 BA17C1BACB3FB49F7760AD1F7E71E17AB39EE0DF3E9D3BF23FD3D70D 6CF1719E
at. 86400 IN DS 60960 13 2 A00073DD75C499465FE829381CE3F5488FC353D06E68C7F90A04D26A 0D71A694
at. 86400 IN RRSIG DS 8 1 86400 20251123050000 20251110040000 61809 . lvjwZzrt8zGMMCwN2cNMHjuACWzvXbMXLjmI0CFa81JFo9ICIH+WZE7h PG+AV52zpyy5SAxKao9gN2uwT2vOqnrwwz2Exd04dOuLlKo0myRfD0Cc UP4CsRef9aZhxrKebwSSxRSxcfSXsktnD4tqe3aZzTDSmU2MyNLIBRlV kvZJJyY9bwV7Cr+bikDip0fH1voGCndkvOhfFMO3hDROzlP9eYFfmd/W TXETrCW0BSG6hh968O4pQYTITUVEVeb/85FcdFfLiOI4Q0UNS6s7ozRS oNflUgmSmPN+MtzkjE/3vcl8ynV5oYOEe0o/pTB0++fI1cF6P+EwjWgb IQgdTg==
;; Received 863 bytes from 2001:7fd::1#53(k.root-servers.net) in 0 ms
morenet.at. 10800 IN NS ns3.morenet.at.
morenet.at. 10800 IN NS ns1.morenet.at.
morenet.at. 10800 IN NS ns2.morenet.at.
fjscbioio98ccv4od6ka4d7oh5bgrn00.at. 10800 IN NSEC3 1 1 0 - FJTB0TH9158RT0NA9RGUQ165JJ6UAN8G NS SOA RRSIG DNSKEY NSEC3PARAM
fjscbioio98ccv4od6ka4d7oh5bgrn00.at. 10800 IN RRSIG NSEC3 13 2 10800 20251118230500 20251105130119 23696 at. OGDQzRWgK3bRFRqY2WuwSJfE38HqJJHTiRIwvq66r2dVK2xUqiAtjav4 WEBufTw8cZGanWtZ62xQAVoZG9IstQ==
ob8ge1mkf36alv3j3vemb23uejbhn0nb.at. 10800 IN NSEC3 1 1 0 - OBA8A2LNS2QQEEKRD7SH5F6BD559A3QJ NS DS RRSIG
ob8ge1mkf36alv3j3vemb23uejbhn0nb.at. 10800 IN RRSIG NSEC3 13 2 10800 20251119161047 20251106000120 23696 at. QuYPXfpBeBQY2YSklw4q2CeOpc3iASb9TlMIrCV6rKAwGVwjmAJiX+8P MdCusUrvffdaSIfogp1uW8wm4dByxg==
couldn't get address for 'ns3.morenet.at': not found
couldn't get address for 'ns1.morenet.at': not found
couldn't get address for 'ns2.morenet.at': not found
dig: couldn't get address for 'ns3.morenet.at': no moreAkkor ez most bug vagy feature?
- 807 megtekintés
Hozzászólások
Ez nem a parlament.hu-s mókához hasonló DNSSEC issue ? Csak egy tipp, mert nem néztem meg.
- A hozzászóláshoz be kell jelentkezni
Első dolgom volt kilőni a DNSSEC validálást.
- A hozzászóláshoz be kell jelentkezni
Szerintem a domain dns serverei nyökögnek. Az .at DNS serverei rendesen visszaadják a dns serverek A rekordját, ha ugyanezt a DNS serverektől kérdezed le, akkor már egyik se adja vissza, csak a SOA-t.
Szerk: lekérdeztem ugyanezeket az 1.1.1.1 és 8.8.8.8--ról is, azok se adták vissza, lehet, hogy amikor te nézted, cache-ből még neked megadták.
- A hozzászóláshoz be kell jelentkezni
Nem, a domain DNS szerverei egyetlen percig sem adták vissza az NS rekordokat és az NS rekordokhoz tartozó hosztok A/AAAA rekordjait. A Google-től, Cloudflare-től sem. Ennek ellenére a domain onnan "működik", tehát nem SERVFAIL jön, hanem rendesen megkapod a mindenfélre rekordokat (MX, A, TXT, ...)
- A hozzászóláshoz be kell jelentkezni
Érdekes, mintha dolgoznának rajta :)
dig -t SOA morenet.at @8.8.8.8
; <<>> DiG 9.20.15-1~deb13u1-Debian <<>> -t SOA morenet.at @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8815
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;morenet.at. IN SOA
;; ANSWER SECTION:
morenet.at. 3600 IN SOA hydrogen.ns.hetzner.com. dns.hetzner.com. 2025111000 86400 10800 3600000 3600
;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Mon Nov 10 19:43:01 CET 2025
;; MSG SIZE rcvd: 102És:
dig -t a morenet.at @8.8.8.8
; <<>> DiG 9.20.15-1~deb13u1-Debian <<>> -t a morenet.at @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50491
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;morenet.at. IN A
;; ANSWER SECTION:
morenet.at. 3438 IN A 91.112.20.187
;; Query time: 16 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Mon Nov 10 19:44:01 CET 2025
;; MSG SIZE rcvd: 55- A hozzászóláshoz be kell jelentkezni
Jah, frissült a SOA verziószám, ettől függetlenül még mindig fennáll a probléma.
- A hozzászóláshoz be kell jelentkezni
Több .at domainről írtál a nyitóban. Mindegyiknek a hetzner a DNS szolgáltatója?
- A hozzászóláshoz be kell jelentkezni
Igen, írtam is a Hetzner ügyfélszolgálatának, de visszajött egy sablonlevél, hogy lépjek be a Hetzner előfizetéshez tartozó fiókomba, és nyissak hibajegyet... (azzal kezdtem a levelet, hogy én nem vagyok Hetzner ügyfél)
- A hozzászóláshoz be kell jelentkezni
Biztos tényleg servfail, a "nagyok" meg cachelnek, talán félre is téve az expiry értékét ha épp servfailt látnak... nem szabványos, de lehet benne logika
- A hozzászóláshoz be kell jelentkezni
hat a SOA alapjan
morenet.at has SOA record hydrogen.ns.hetzner.com. dns.hetzner.com. 2025111000 86400 10800 3600000 3600
a domain dns szervere a hydrogen.ns.hetzner.com., es valoban, az szepen valaszol
root@astral3:~# host -t A morenet.at. hydrogen.ns.hetzner.com.
Using domain server:
Name: hydrogen.ns.hetzner.com.
Address: 2a01:4f8:0:1::add:1098#53
Aliases:
morenet.at has address 91.112.20.187
- A hozzászóláshoz be kell jelentkezni
ez nem bind bug, hanem a domain delegációs konfigurációjának hibája. a .at zóna delegálja a morenet.at-ot olyan névkiszolgálókra, amelyek ip-címre vannak glue-olva, de maguk a kiszolgálók nem szolgáltatják a morenet.at zónát (vissza soa-t adnak egy másik zónához), és a child zóna apexén hiányoznak az ns-ek. Ettől a bind ésszerűen servfail-t ad, míg egyes nagy rekurzív szolgáltatók toleránsabbak vagy eltérő heurisztikát használnak, ezért nekik sikerül a feloldás. szóval a glue miatt kapsz a-t
ez akkor szokott lenni, ha a névszervere a domainnak saját domainén van
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
- A hozzászóláshoz be kell jelentkezni
Várj, attól, mert a zóna névszerverei a zónán belüli névszerveren vannak, az pont a TLD feloldás miatt nem kellene, hogy gondot okozzon, hiszen a .at megmondja, hogy ezek hol vannak IP címileg.
Itt mintha az okozna gondot, hogy "maguk a kiszolgálók nem szolgáltatják a morenet.at zónát". Márpedig, ha valami be van regisztrávlva a TLD névszervereibe, annak kutya kötelessége lenne.
Az a tippem, hogy valami előfizetés(ek) lejárt(ak), és emiatt a Hetzner beszüntette a zóna/zónák kiszolgálását, azonban mivel ilyenkor a regisztráció már ki van fizetve X évre, az nem szűnik meg ezzel párhuzamosan.
A másik lehetőség, hogy a Hetzner átstrukturálja a DNS kiszolgáló infráját, de még nem ért át minden domain / nem íródott át minden zóna a .at TLD -ben. Nem tudom, mekkora bürokrácia náluk egy zóna módosítás a helyi ISZT-nél.
- A hozzászóláshoz be kell jelentkezni
maguk a kiszolgálók nem szolgáltatják a morenet.at zónát
A kiszolgálók szolgáltatják a morenet.at zónát, csak a zónákban nincsenek benne az NS rekordok, valamint a glue rekordokhoz szükséges IP címek.
- A hozzászóláshoz be kell jelentkezni
Glue rekordhoz az IP nem is feltétlen kell legyen benne a zónába, azt a root NS kiszolgálja.
- A hozzászóláshoz be kell jelentkezni
Ilyen alapon akkor az NS-nek sem kellene benne lenni a zónában, mert a fölötte lévő NS kiszolgálja, nem? :)
- A hozzászóláshoz be kell jelentkezni
így van. működik, de rossz
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
- A hozzászóláshoz be kell jelentkezni
A jelek épp arra utalnak, hogy nem működik.
IMHO, ha egy resolver találkozik azzal, hogy egy zóna authoritatív kiszolgálója az ns.foobar.hu, akkor (amíg ez az infó a cache-ben megvan) mindent, ami az adott zónában van, az ns.foobar.hu-tól fogja kérdezni, és nem fogja végigjárni újra a teljes fát rekurzívan.
- A hozzászóláshoz be kell jelentkezni
Pontosan.
- A hozzászóláshoz be kell jelentkezni
az oldalt feloldotta. ergó működik az oldal
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
- A hozzászóláshoz be kell jelentkezni
Jepp, rfc2181 szerint kötelező (soa + ns), de anélkül is megy a dolog.
- A hozzászóláshoz be kell jelentkezni
Ilyenekre szerintem egy jo tool a https://zonemaster.se (src: https://github.com/zonemaster/zonemaster )
morenet.at eseteben az eredmeny: Lame delegation. :)
https://zonemaster.se/en/result/26dfd5e16de81c42
- A hozzászóláshoz be kell jelentkezni
Ez tök jó, kösz! Nem én miattam, mert én remekül használom a diagnosztikai eszközöket (dig és társai), hanem az ügyfélnek lehet mutogatni, aki egyfolytában azt mantrázza, hogy biztosan nálunk szar valami.
Azt egyébként tökre "szeretem", amikor az ügyfélnek részletesen kifejtjük a probléma okát, majd visszaír, hogy szerinte hülyeséget beszélünk, és megkérdezi, mivel tudjuk alátámasztani a véleményünket? (Úgynevezett tényekkel, paszmek.)
- A hozzászóláshoz be kell jelentkezni
... de ő megkérdezte az éjájt.
- A hozzászóláshoz be kell jelentkezni
Erre pont nem jó, mivel hülyeséget ír. Ez nem lame delegation, mert annak az az ismérve, hogyha a delegált szerver nem szolgálja a ki a zónát mert
- nincs frissítve
- nem érhető el
- nem tud róla, hogy neki kellene kiszolgálni
Itt simán egy hibásan generált DNS zone tartalom van amiben nincsenek definiálva az NS erőforrás bejegyzések.
Miért működik?
Mert minden NS szervere az adott zónának in-domain definiált és glue -ként definiált a szülő zónájában.
Miért nem működik?
Mert a legtöbb DNS resolver ellenőrzi a zónát is és így eldobja (bind, unbound), ennek semmi köze a szolgáltató méretéhez. Például a knot resolver fel fogja oldani a zóna alatt definiált tartalmat a glue adatok alapján.
- A hozzászóláshoz be kell jelentkezni
Mindig is szerettem volna a DNS-hez -ilyen szinten- érteni :)
- A hozzászóláshoz be kell jelentkezni
Mire gondolsz pontosan? Hogy be tudj szarul konfigolni egyet? Szerintem az a tudás kb. mindenkinek adott.
- A hozzászóláshoz be kell jelentkezni
Nem-nem, úgy értem jobban belelátni hogy működik a DNS internet-méretben. Intraneten felhúzni egy primitiv dns szervert egy kontárul beállított local-only zónával, ami mégis működik valamiért többé-kevésbbé, az még nem jelenti h. az ember valóban érti a dns nüanszjait internet környezetben is. Nem a balfasz hibásan beállított ontopik témában kérdeztem, hanem általánosságban. Én pl. nem teljesen értem hogy mit kellene nézni ebben a posztban amiből egyértelműen látszik h. mi hol lett elkefélve. Azaz nincs összehasonlítási alapom egy tankönyvi mintapélda zóna + mintapélda DNS szerver beállítás vs. egy nemszépen de amúgy működően vs. egy kicsithibásan vs egy totál szarul beállított esetre.
- A hozzászóláshoz be kell jelentkezni
nem tudom, hogy van-e koze, mert az nft drop fogta meg, de letezik, hogy egy dns lekerdezes a 10.0.0.0/8 privat halozat fele menjen?
konkretan:
DST=10.228.5.106
DST=10.228.69.25
DST=10.228.133.23
DST=10.228.133.22
DST=10.228.69.24
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
ha ott van a dns szervered, akkor miért ne? :D
- A hozzászóláshoz be kell jelentkezni
vegulis, minden dns szerveren fel lehet oldani a rajta levo zonakat 127.0.0.1 szerver cimmel is, miert nem ezt adjuk meg minden ns rekordban? :)
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Simán, ha valami gépen úgy van beállítva. Lépj kettőt hátra, és gondold át, hogy hogy működik az, hogy én feloldom a hup.hu -t IP címre. Felejtsd el a tűzfalat, csak gondold végig.
Amúgy, én láttam már a 10.0.0.0/8-as hálóban levő gépet interneten is, és válaszolt. Szóval valójában semmi nem lehetetlen.
- A hozzászóláshoz be kell jelentkezni
nekem ez az informaciom van, neked van ujabb?
"# whois 10.228.5.106
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2025, American Registry for Internet Numbers, Ltd.
#
NetRange: 10.0.0.0 - 10.255.255.255
CIDR: 10.0.0.0/8
NetName: PRIVATE-ADDRESS-ABLK-RFC1918-IANA-RESERVED
NetHandle: NET-10-0-0-0-1
Parent: ()
NetType: IANA Special Use
OriginAS:
Organization: Internet Assigned Numbers Authority (IANA)
RegDate:
Updated: 2024-05-24
Comment: These addresses are in use by many millions of independently operated networks, which might be as small as a single computer connected to a home gateway, and are automatically configured in hun
dreds of millions of devices. They are only intended for use within a private context and traffic that needs to cross the Internet will need to use a different, unique address.
"
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni