Witam!

Sami sobie popatrzcie:

[...]
198.41.0.4 (A.ROOT-SERVERS.NET) with failed to resolve ns.tpnet.pl due
to 198.41.0.4 - failed to resolve szeloba.nask.waw.pl due to 198.41.0.4
- failed to resolve kirdan.warman.nask.pl due to 198.41.0.4 - failed to
resolve ns.tpnet.pl due to 198.41.0.4 - nameserver loop detected
[...]

Zresztą bawiąc się Squish'em i różnymi domenami w PL można więcej
ciekawych kwiatków wyszukać (np. tutaj):
<http://www.squish.net/dnscheck/>

Efekty tego są ciekawe. Na przykład jeden taki znajomy ISP
(francusko-szwajcarska firma) przeniósł dwa dni temu jeden swój primary
DNS do firmy w Polsce - konkretnie podłączeni do TP SA. Zmienił się
zarówno IP maszyny, jak i zmieniono przy okazji jej nazwę.

I jest tak: w USA OK, w UK OK :), we Francji OK, w TP SA nawet OK,
a w sieciach podłączonych do NASQ:

- nowy serial,
- nowe NS'y,
- ale stary rekord A!

Źle się dzieje w państwie Duńskim... :-/

-K.

do góry

On Mon, 2008-01-28 at 21:00 +0100, Krzysztof Mlynarski wrote:
> Witam!
>
> Sami sobie popatrzcie:
>
> [...]
> 198.41.0.4 (A.ROOT-SERVERS.NET) with failed to resolve ns.tpnet.pl due
> to 198.41.0.4 - failed to resolve szeloba.nask.waw.pl due to 198.41.0.4
> - failed to resolve kirdan.warman.nask.pl due to 198.41.0.4 - failed to
> resolve ns.tpnet.pl due to 198.41.0.4 - nameserver loop detected
> [...]

A konkretnie to jaki jest problem? Z czego wziąłeś powyższy output?
Co nie działa?

> Na przykład jeden taki znajomy ISP
> (francusko-szwajcarska firma) przeniósł dwa dni temu jeden swój primary
> DNS do firmy w Polsce - konkretnie podłączeni do TP SA. Zmienił się
> zarówno IP maszyny, jak i zmieniono przy okazji jej nazwę.
>
> I jest tak: w USA OK, w UK OK :), we Francji OK, w TP SA nawet OK,
> a w sieciach podłączonych do NASQ:
>
> - nowy serial,
> - nowe NS'y,
> - ale stary rekord A!

Nie piszesz nic na temat serwera autorytatywnego dla tej domeny w sieci
NASK.
Jeśli zatem "w sieciach podłączonych do NASQ" ma oznaczać "na jakimś
NASKowym resolverze" to nie widzę powodów, dla których powyższe
zachowanie miałoby być błędne.
O rekord A ktoś już wcześniej zapytał i taki został skeszowany.
Będzie taki zwracany aż do końca TTLa (który możesz sobie jak
najbardziej odczytać). NSy i serial nic do tego nie mają.
Tak działa DNS.

Jacek

do góry

Krzysztof Mlynarski <k...@W...security.pl> writes:

> Efekty tego są ciekawe. Na przykład jeden taki znajomy ISP
> (francusko-szwajcarska firma) przeniósł dwa dni temu jeden swój
> primary DNS do firmy w Polsce - konkretnie podłączeni do TP SA.

> - nowy serial,
> - nowe NS'y,
> - ale stary rekord A!

Krzysiu, ten znajomy ISP mógłby sie nauczyć, co to jest TTL i _przed_
taka zmianą odpowiednio poskracać, żeby czas propagacji zmiany był
krótszy.

MJ

do góry

Michal Jankowski pisze:

> Krzysiu, ten znajomy ISP mógłby sie nauczyć, co to jest TTL i _przed_
> taka zmianą odpowiednio poskracać, żeby czas propagacji zmiany był
> krótszy.

Michale, sęk w tym, że TTL u nich był ustawiony na krótszy (86400),
dawno temu zresztą i taki też jest widziany np. na serwerach TP SA.

Natomiast odpytanie o ten sam rekord A w sieci NASK zwraca Ci TTL = 172800.

-K.

do góry

Jacek Zapala pisze:

> Nie piszesz nic na temat serwera autorytatywnego dla tej domeny w sieci
> NASK.
> Jeśli zatem "w sieciach podłączonych do NASQ" ma oznaczać "na jakimś
> NASKowym resolverze" to nie widzę powodów, dla których powyższe
> zachowanie miałoby być błędne.
> O rekord A ktoś już wcześniej zapytał i taki został skeszowany.
> Będzie taki zwracany aż do końca TTLa (który możesz sobie jak
> najbardziej odczytać). NSy i serial nic do tego nie mają.
> Tak działa DNS.

Jakby Ci to powiedzieć... mniej więcej wiem, jak działa DNS (oraz nazm
stosowne RFC). :)

Problem w tym, że w NASK TTL jest 2x dłuższy niż standardowo używany
przez Francuzów. I z polskich komputerów uczelnianych nie widać tego, co
rozpropagowało się już po całym niemal Świecie.

Zastanawia mnie, dlaczego TTL zdefiniowany w opisie strefy jest ignorowany?

Nawet wyjątkowo czujny i "politycznie poprawny ;)" serwis AFNIC'u zwraca
poprawne dane.

/* Swoją drogą polecam uwadze - on jest naprawdę bardzo restrykcyjny

<http://www.afnic.fr/outils/zonecheck/_en>

*/

Cóż.. widocznie trzeba będzie poczekać aż minie kolejna doba i mam
nadzieję, że wszystko się "wyprostuje" także i tutaj.

-K.

do góry

Krzysztof Mlynarski <k...@W...security.pl> writes:

> 198.41.0.4 (A.ROOT-SERVERS.NET) with failed to resolve ns.tpnet.pl due
> to 198.41.0.4 - failed to resolve szeloba.nask.waw.pl due to
> 198.41.0.4 - failed to resolve kirdan.warman.nask.pl due to 198.41.0.4
> - failed to resolve ns.tpnet.pl due to 198.41.0.4 - nameserver loop
> detected

A od kiedy to *.root-servers.net zajmuja sie znajdowaniem nazw
wewnatrz TLDs?

Name: a.root-servers.net.
Address: 198.41.0.4#53

;; AUTHORITY SECTION:
pl. 172800 IN NS C-DNS.pl.
pl. 172800 IN NS D-DNS.pl.
pl. 172800 IN NS E-DNS.pl.
pl. 172800 IN NS F-DNS.pl.
pl. 172800 IN NS G-DNS.pl.
pl. 172800 IN NS H-DNS.pl.
pl. 172800 IN NS A-DNS.pl.
pl. 172800 IN NS B-DNS.pl.

;; ADDITIONAL SECTION:
A-DNS.pl. 172800 IN A 195.187.245.44
B-DNS.pl. 172800 IN A 80.50.50.10
C-DNS.pl. 172800 IN A 193.171.255.47
D-DNS.pl. 172800 IN A 213.172.174.70
E-DNS.pl. 172800 IN A 213.218.118.26
F-DNS.pl. 172800 IN A 217.17.46.189
F-DNS.pl. 172800 IN AAAA 2001:1a68:0:10::189
G-DNS.pl. 172800 IN A 149.156.1.6
G-DNS.pl. 172800 IN AAAA 2001:6d8:0:1::a:6
H-DNS.pl. 172800 IN A 194.0.1.2

Wszystko wyglada tak, jak powinno chyba?

> Zresztą bawiąc się Squish'em i różnymi domenami w PL można więcej
> ciekawych kwiatków wyszukać (np. tutaj):
> <http://www.squish.net/dnscheck/>

Tyle ze dobrze byloby tez wiedziec jak interpretowac wyniki. Szczerze
mowiac, mam pewne watpliwosci (np. co to jest xx%).

"nameserver loop detected" dla tego squisha powstaje chyba wtedy, gdy
root ns nie chce mu dac glue records dla np. DNSow dla *.tpnet.pl -
tyle ze on od tego nie jest.

> Efekty tego są ciekawe. Na przykład jeden taki znajomy ISP
> (francusko-szwajcarska firma) przeniósł dwa dni temu jeden swój
> primary DNS do firmy w Polsce - konkretnie podłączeni do TP
> SA. Zmienił się zarówno IP maszyny, jak i zmieniono przy okazji jej
> nazwę.
>
> I jest tak: w USA OK, w UK OK :), we Francji OK, w TP SA nawet OK,
> a w sieciach podłączonych do NASQ:
>
> - nowy serial,
> - nowe NS'y,
> - ale stary rekord A!

Michal juz napisal o TTLach, ale tak w ogole co ma wspolnego sposob
podlaczenia (provider, zakres IP itd) z dzialaniem DNS?
--
Krzysztof Halasa

do góry

Krzysztof Halasa pisze:

[...]
(Oelemy na chwilę wyniki odpytań Squisha)
[...]

> Michal juz napisal o TTLach, ale tak w ogole co ma wspolnego sposob
> podlaczenia (provider, zakres IP itd) z dzialaniem DNS?

To, że zazwyczaj resolvery w takiej sieci używają tych DNSów, które
pozwalają na odpytywanie rekurencyjne klientom z danej sieci. Słowem,
póki na tych serwerach w kaszy siedzą nieaktualne informacje. Klient
siedzący wewnątrz takiej sieci nie ma praktycznie szans na otrzymanie
aktualnej odpowiedzi (chyba, że znajdzie jakiś Open DNS na zewnątrz i go
użyje - narażając się tym samym na różne niebezpieczeństwa, ale to jest
dygresja).

Michał napisał oczywiste rzeczy o TTLach, natomiast nigdzie nie napisał,
w jakim celu w sieciach niektórych operatorów, totalnie ignoruje się
TTLe wyspecyfikowane w danej strefie. W skutek czego propagacja trwa
niemiłosiernie długo.

Efekt ignorowania TTLi jest dość smutny, jeśli robisz taką "burzę", jak
przenoszenie serwera, który jest primary dla N róznych domen. Wtedy
przez długi czas, z wielu miejsc w sieci, przychodzą zapytania o te
domeny pod stary adres przenoszonego serwera DNS.

Gorzej, jeśli musisz zlikwidować maszynę do konkretnej daty, a przez
operatorów ignorujących TTL i wstawiających w to miejsce własny,
propagacja sobie radośnie trwa i trwa i trwa... Tobie się wydawało, że
skrócenie TTLa jakiś czas przed przystąpieniem do przenoszenia serwera
załatwia temat, bo tak być powinno. Otóż nie, nie załatwia (j.w. na
przykładzie choćby NASKu - a takich przypadków jest więcej).

-K.

do góry

Krzysztof Mlynarski <k...@W...security.pl> writes:

> To, że zazwyczaj resolvery w takiej sieci używają tych DNSów, które
> pozwalają na odpytywanie rekurencyjne klientom z danej sieci.

Takie end-userskie resolvery, bez wlasnego serwera?
Tak czy owak, ten squish to nie ten przypadek (choc tez cokolwiek
dziwny).

> Michał napisał oczywiste rzeczy o TTLach, natomiast nigdzie nie
> napisał, w jakim celu w sieciach niektórych operatorów, totalnie
> ignoruje się TTLe wyspecyfikowane w danej strefie. W skutek czego
> propagacja trwa niemiłosiernie długo.

A konkretnie, na jakiej maszynce tak jest? Zaraz sprawdzimy.

> Gorzej, jeśli musisz zlikwidować maszynę do konkretnej daty, a przez
> operatorów ignorujących TTL i wstawiających w to miejsce własny,
> propagacja sobie radośnie trwa i trwa i trwa... Tobie się wydawało, że
> skrócenie TTLa jakiś czas przed przystąpieniem do przenoszenia serwera
> załatwia temat, bo tak być powinno.

Niezupelnie - jesli ktos ma TTL = miesiac, to fakt, ze na jeden dzien
przed zmianami zmieni go na 5 minut wiele moze nie dac. Niestety musi
to zrobic na miesiac przed zmianami, w przeciwnym przypadku to
ruletka, i efekt moze byc taki, ze wieksze serwery (robiace rekurencje
dla end userow) beda mialy stare wpisy, a mniejsze - nowe, bo nie byly
odpytywane o to przed zmianami.

W awaryjnych przypadkach mozna probowac notify, ale to da tylko
czesciowy efekt (oczywiscie jesli notify w ogole moze zadzialac).
--
Krzysztof Halasa

do góry

Krzysztof Halasa napisał(a):
> Krzysztof Mlynarski <k...@W...security.pl> writes:
>
>> To, że zazwyczaj resolvery w takiej sieci używają tych DNSów, które
>> pozwalają na odpytywanie rekurencyjne klientom z danej sieci.
>
> Takie end-userskie resolvery, bez wlasnego serwera?
> Tak czy owak, ten squish to nie ten przypadek (choc tez cokolwiek
> dziwny).
>
>> Michał napisał oczywiste rzeczy o TTLach, natomiast nigdzie nie
>> napisał, w jakim celu w sieciach niektórych operatorów, totalnie
>> ignoruje się TTLe wyspecyfikowane w danej strefie. W skutek czego
>> propagacja trwa niemiłosiernie długo.
>
> A konkretnie, na jakiej maszynce tak jest? Zaraz sprawdzimy.
>
>> Gorzej, jeśli musisz zlikwidować maszynę do konkretnej daty, a przez
>> operatorów ignorujących TTL i wstawiających w to miejsce własny,
>> propagacja sobie radośnie trwa i trwa i trwa... Tobie się wydawało, że
>> skrócenie TTLa jakiś czas przed przystąpieniem do przenoszenia serwera
>> załatwia temat, bo tak być powinno.
>
> Niezupelnie - jesli ktos ma TTL = miesiac, to fakt, ze na jeden dzien
> przed zmianami zmieni go na 5 minut wiele moze nie dac. Niestety musi
> to zrobic na miesiac przed zmianami, w przeciwnym przypadku to
> ruletka, i efekt moze byc taki, ze wieksze serwery (robiace rekurencje
> dla end userow) beda mialy stare wpisy, a mniejsze - nowe, bo nie byly
> odpytywane o to przed zmianami.

Ale część serwerów DNS olewa całkowicie TTL i trzyma dane przez 24 godziny. Może to
miało sens przy
słabych łączach i słabych maszynach. W tej chwili sensu nie ma. Kiedyś ktoś zrobił,
żeby cache było
48 godzin i tak już zostało. Sam się z tym zetknąłem kilka razy przy zmianach
delegacji i podobnych
operacjach.

wer

do góry

Krzysztof Halasa pisze:

>> Michał napisał oczywiste rzeczy o TTLach, natomiast nigdzie nie
>> napisał, w jakim celu w sieciach niektórych operatorów, totalnie
>> ignoruje się TTLe wyspecyfikowane w danej strefie. W skutek czego
>> propagacja trwa niemiłosiernie długo.
>
> A konkretnie, na jakiej maszynce tak jest? Zaraz sprawdzimy.

Zaraz Ci puszczę na priva. :)

>> Gorzej, jeśli musisz zlikwidować maszynę do konkretnej daty, a przez
>> operatorów ignorujących TTL i wstawiających w to miejsce własny,
>> propagacja sobie radośnie trwa i trwa i trwa... Tobie się wydawało, że
>> skrócenie TTLa jakiś czas przed przystąpieniem do przenoszenia serwera
>> załatwia temat, bo tak być powinno.
>
> Niezupelnie - jesli ktos ma TTL = miesiac, to fakt, ze na jeden dzien
> przed zmianami zmieni go na 5 minut wiele moze nie dac.

No to akurat jest chyba oczywiste. Tak działa DNS :-)

> Niestety musi
> to zrobic na miesiac przed zmianami,

No.. chyba nawet nieco więcej niż miesiąc - byłoby bezpieczniej.

> w przeciwnym przypadku to
> ruletka, i efekt moze byc taki, ze wieksze serwery (robiace rekurencje
> dla end userow) beda mialy stare wpisy, a mniejsze - nowe, bo nie byly
> odpytywane o to przed zmianami.

Owszem.

> W awaryjnych przypadkach mozna probowac notify, ale to da tylko
> czesciowy efekt (oczywiscie jesli notify w ogole moze zadzialac).

W tym przypadku - wątpię (bo zgodnie z RFC 1996, Notify skierowane jest
do slaves - czyli "w dół", a z tym akurat nie ma problemu, bo slave ma
to co master i notify otrzymał natychmiast - przypadkowo mam do niego
osobisty dostęp i sprawdziłem stosowne rekordy od razu).

-K.

do góry