eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.internet.polipCo się dzieje z tymi DNS-ami w NASK i TP SA?! [loop detected!]
Ilość wypowiedzi w tym wątku: 29

  • 1. Data: 2008-01-28 20:00:27
    Temat: Co się dzieje z tymi DNS-ami w NASK i TP SA?! [loop detected!]
    Od: Krzysztof Mlynarski <k...@W...security.pl>

    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.


  • 2. Data: 2008-01-28 22:11:37
    Temat: Re: Co się dzieje z tymi DNS-ami w NASK i TP SA?! [loop detected!]
    Od: Jacek Zapala <j...@i...pl>

    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



  • 3. Data: 2008-01-29 08:34:22
    Temat: Re: Co się dzieje z tymi DNS-ami w NASK i TP SA?! [loop detected!]
    Od: Michal Jankowski <m...@f...edu.pl>

    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


  • 4. Data: 2008-01-29 09:21:00
    Temat: Re: Co się dzieje z tymi DNS-ami w NASK i TP SA?! [loop detected!]
    Od: Krzysztof Mlynarski <k...@W...security.pl>

    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.




  • 5. Data: 2008-01-29 10:05:39
    Temat: Re: Co się dzieje z tymi DNS-ami w NASK i TP SA?! [loop detected!]
    Od: Krzysztof Mlynarski <k...@W...security.pl>

    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.


  • 6. Data: 2008-01-29 13:47:40
    Temat: Re: Co się dzieje z tymi DNS-ami w NASK i TP SA?! [loop detected!]
    Od: Krzysztof Halasa <k...@p...waw.pl>

    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


  • 7. Data: 2008-01-29 14:42:43
    Temat: Re: Co się dzieje z tymi DNS-ami w NASK i TP SA?! [loop detected!]
    Od: Krzysztof Mlynarski <k...@W...security.pl>

    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.


  • 8. Data: 2008-01-29 15:05:33
    Temat: Re: Co się dzieje z tymi DNS-ami w NASK i TP SA?! [loop detected!]
    Od: Krzysztof Halasa <k...@p...waw.pl>

    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


  • 9. Data: 2008-01-29 15:58:47
    Temat: Re: Co się dzieje z tymi DNS-ami w NASK i TP SA?! [loop detected!]
    Od: wer <b...@n...pl>

    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


  • 10. Data: 2008-01-29 16:08:22
    Temat: Re: Co się dzieje z tymi DNS-ami w NASK i TP SA?! [loop detected!]
    Od: Krzysztof Mlynarski <k...@W...security.pl>

    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.

strony : [ 1 ] . 2 . 3


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: