Autor: Andrzej Krzysztofowicz (ankry_at_green.mif.pg.gda.pl)
Data: Fri 27 Apr 2001 - 10:05:01 MET DST
smarkacz <smarkacz_at_anathema.eu.org> wrote:
> Andrzej Krzysztofowicz <ankry_at_green.mif.pg.gda.pl> wrote:
>> darecki_at_wytnij.sobie.to wrote:
>> > Najpierw jest rejestracja/delegacja, a potem DNS. To delegacja jest
>> > powodem do konfiguracji DNSa, a nie skonfigurowany DNS powodem
>> > do wpisania delegacji!
>> Nie. Delegacja powinna zawsze wskazywac na wlasciwy serwer DNS-u.
> I o to właśnie chodzi - skoro nie ma delegacji, nie ma też żadnego
> powodu żeby konfigurować obsługę domeny u siebie.
>> > Dotad do czasu rejestracji domeny nie wpisywalismy jej do DNSa, bo
>> > PRZECIEZ JEJ NIE MA. Dopiero kiedy klient zalatwil wreszcie formalnosci
>> Nie ma jej w Internecie. U ciebie moze juz byc.
> To żeby nie zwiększać entropii, tak? Kosmiczna delegacja jest znacznie
> mniej groźna niż domena istniejąca u jednego providera.
Nie u jednego dostawcy, a na jednum hoscie. Jesli ten dostawca odpowiednio o
to zadba.
>> > Nie ma zadnego powodu aby nieistniejace domeny pojawialy sie w DNSach i
>> A jakie widzisz przeciwskazania ?
> Podobne jak dla adresów prywatnych pojawiających się w sieci
> publicznej.
Adresy prywatne w DNSie ? Zgoda.
Adresy prywatne w routingu ? Twierdze, ze jesli sie je dobrze skonfiguruje
(PMTU), to nie bedzie problemow.
>> > nastepnie czesto znikaly jako niezarejestrowane (lub gorzej -
>> > tkwily tam nadal). Jesli chodzi o potwierdzanie, czy chcemy taka
>> > delegacje, to oczywiscie mozemy potwierdzac, ale NIE POPRZEZ
>> > WPISYWANIE LIPY DO DNSow.
>> Jakiej lipy ? Przeciez jesli nie ma delegacji, to nikt poza tymi co
>> ustawili ten serwer jako swoj DNS nie bedzie cie o te domeny pytal.
> Nie "nie będzie pytał" tylko "nie dostanie odpowiedzi". To raz. Dwa,
A jakim cudem moga cie inne DNS-y pytac, jesli nie ma delegacji ?
I dlaczego nie dostanie odpowiedzi, jesli twoj serwer DNS obsluguje te
domene ?
> nie należy wpisywać do DNSu poddomen jakiejkolwiek istniejącej domeny,
> inaczej robi się burdel (wyjątkiem jest reverse dla adresów
> prywatnych, który wpisywać należy).
Chodz ci o wpisy typu
host.poddomena IN A ...
?
Istotnie z
poddomena IN NS ...
powinno sie to wykluczac.
Ale nie uwazam, ze dla pojedynczych wpisow nalezaloby tworzyc cala strefe.
Mozesz to jakos uzasadnic ?
>> > Poniewaz (zapewne jak wiekszosc) mamy jedne DNSy, ktore jednoczesnie
>> > obsluguja delegacje dla obcych zapytan i rekursywne zapytania dla calego
>> Problem twoj i twoich klientow. Mozecie wybrac inne inne serwery DNS,
>> ktorych nie zalecacie.
> Tak szczerze mówiąc, jeśli ktoś obsługuje swoje delegacje na innym
> serwerze niż zapytania rekurencyjne to ten drugi powinien
> skonfigurować tak, żeby delegowane do pierwszego domeny kierował do
> niego bezpośrednio, nie szukając od root serwerów.
Ale to moze zrobic juz po powstaniu delegacji. Inne przeciwskazania ?
>> * user wypelnia jaka domene chce miec
>> * wlaczenie DNS
> ..domena zostaje zarejestrowana dla kogo innego i klienci jej nie
> widzą.
.. jak to stwierdzisz swoim systemem monitorowania, likwidujesz swoj DNS dla
tej domeny w trybie natychmiastowym. Co za roznica ?
>> > NASK chce zeby potwierdzac chec wziecia delegacji wpisem do DNS?
>> NASK nie chce rejestrowac domen, ktore nie beda dzialac w chwili
>> rejestracji.
> Ideałem by było, żeby obsługa domeny była włączana dokładnie w
> momencie uruchomienia delegacji przez NASK. Ale że tego raczej nie da
Tu sie zgadzamy. Moze wiec secondary DNS na serwerach NASKu. Dla wszystkich
;)
> się osiągnąć, lepiej żeby przez pewien czas istniały wpisy NS w NASKu
> bez obsługi, niż żeby istniała obsługa bez delegacji.. zresztą według
> tego, co NASK pisze na swoim WWW, w momencie zgłoszenia wniosku DNSy
> nie muszą być skonfigurowane do obsługi rejestrowanej domeny. I słusznie.
-- ======================================================================= Andrzej M. Krzysztofowicz ankry_at_mif.pg.gda.pl tel. (0-58) 347 14 61 Wydz.Fizyki Technicznej i Matematyki Stosowanej Politechniki Gdanskiej
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 16:47:35 MET DST