Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

cokolwiek.net & cokolwiek.com

2 views
Skip to first unread message

Lukasz Trabinski

unread,
Sep 16, 2003, 12:59:52 PM9/16/03
to
Witam
Polecam przeczytać:
http://www.merit.edu/mail.archives/nanog/msg13603.html
Generalnie chodzi o to, aby wszelkie błedne, nieistniejące adresy
z końcówką .net i .com przekierowywać w jedno miejsce, do
do dysponenta domen .net i .com, a dokładniej do VeriSign.
O konsekwencjach tegoż, lepiej nawet nie myśleć.

--
*[ Łukasz Trąbiński ]*

Przemyslaw Popielarski

unread,
Sep 16, 2003, 1:31:58 PM9/16/03
to
Lukasz Trabinski wrote:
> http://www.merit.edu/mail.archives/nanog/msg13603.html
> Generalnie chodzi o to, aby wszelkie błedne, nieistniejące adresy
> z końcówką .net i .com przekierowywać w jedno miejsce, do
> do dysponenta domen .net i .com, a dokładniej do VeriSign.
> O konsekwencjach tegoż, lepiej nawet nie myśleć.

http://www.dsinet.org/?id=3598

--
./ premax
./ pre...@hot.pl
./ koniec i bomba, a kto czytal ten traba. w.g.

Piotr KUCHARSKI

unread,
Sep 16, 2003, 2:41:42 PM9/16/03
to

Na początek proponuję:
cd ~squid/errors/English
sed 's/%z/Name Error: The domain name does not exist./' ERR_DNS_FAIL \
> ERR_DNS_FAIL_LAMEVERISIGN
oraz dodać w odpowiednim miejscu (przed innymi http_access) w squid.conf
co następuje:
acl lameverisign dst 64.94.110.11
http_access deny lameverisign
deny_info ERR_DNS_FAIL_LAMEVERISIGN lameverisign

p.

--
Beware of he who would deny you access to information, for in his
heart he dreams himself your master. -- Commissioner Pravin Lal
http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów ;)

Michal Jankowski

unread,
Sep 16, 2003, 5:45:04 PM9/16/03
to
"Usluga" dotyczy glownie 1) http na port 80 i 2) smtp na port 25.

Ad 1) pokazuje sie strona firmy na V. zamiast komunikatu o blednym
adresie.

Ad 2) poczta do nas pochadzaca z nieistniejacych domen jest
przyjmowana, zamiast byc odrzucona na wstepie, a poczta od nas do
nieistniejacych domen probuje sie wyslac do firmy V., gdzie jest
odrzucana w sposob nader malo profesjonalny i tez z mylacym
komunikatem.

Sposoby zaradcze mozna podzielic z grubsza na 3 rodzaje: na poziomie
DNSu, warstwy transportowej i aplikacyjnej.

a) Modyfikujemy nasz serwer DNS, zeby wszystkie odpowiedzi zawierajace
"trefny" numer IP zmienial na komunikat "nie ma takiej domeny".
Wszystko wraca do sytuacji sprzed kilku dni. Wada rozwiazania jest
koniecznosc zadbania, aby nasi userzy nie korzystali z innych serwerow
DNS (ale to w wielu miejscach i tak sie robi) oraz koniecznosc
przekompilowania kodu serwera DNS z wprowdzonymi dosc "na kolanie"
poprawkami.

b) Blokujemy trefny adres na routerach. Do polaczenia (tak http, jak
smtp) z serwerami firmy V. nie dochodzi, ale uzytkownicy dostaja inne
niz dotad komunikaty o bledach, wygladajace na klopoty z lacznoscia, a
co gorsza poczta wyslana na bledny adres wraca do nadawcy dopiero po
kilku dniach, wczesniej zapychajac kolejke. Rozwiazanie wariantowe to
przekierowanie portu 80 na wlasny serwer, ktory bedzie wyswietlal
komunikat "nie ma takiej strony".

c) Rozwiazania aplikacyjne w czesci http mozna zastosowac tylko do
serwerow proxy czy cache, bo nie mamy kontroli nad przegladarka
"kazdego jednego" usera.
Natomiast co do smtp, to mozna dosc latwo nauczyc program MTA, zeby
adresy tlumaczace sie na owo trefne IP traktowal rownowaznie z
nieistniejacymi.

Niestety, wszystkie jak jeden maz powyzsze rozwiazania jako kryterium
"trefnosci" posluguja sie konkretnym, explicite wpisanym numerem IP i
jesli ten numer sie zmieni, to lezymy, dopoki nie wpiszemy nowego... I
tak w kolko...

Komentarze mile widziane.

MJ

Piotr KUCHARSKI

unread,
Sep 16, 2003, 6:44:28 PM9/16/03
to
Michal Jankowski <mic...@fuw.edu.pl> wrote:
> "Usluga" dotyczy glownie 1) http na port 80 i 2) smtp na port 25.

"Usługa" nie odpowiada 64.94.110.11 na zapytania o adresy, z których
chcemy skorzystać przy http lub smtp (jak by chcieli), tylko na wszystkie.
Oczywiście http i smtp są najbardziej wykorzystywane. Ale "usługa" psuje
wszystko.

> Sposoby zaradcze mozna podzielic z grubsza na 3 rodzaje: na poziomie
> DNSu, warstwy transportowej i aplikacyjnej.

Jedyna słuszna droga jest przez ICANN. Przy okazji, odpowiedź ICANN:
http://www.iab.org/Documents/icann-vgrs-response.html

> b) Blokujemy trefny adres na routerach. Do polaczenia (tak http, jak
> smtp) z serwerami firmy V. nie dochodzi, ale uzytkownicy dostaja inne
> niz dotad komunikaty o bledach, wygladajace na klopoty z lacznoscia, a
> co gorsza poczta wyslana na bledny adres wraca do nadawcy dopiero po
> kilku dniach, wczesniej zapychajac kolejke. Rozwiazanie wariantowe to
> przekierowanie portu 80 na wlasny serwer, ktory bedzie wyswietlal
> komunikat "nie ma takiej strony".

Tymczasowo można tak zrobić. W długim okresie lepiej systemowo => ICANN.

Paweł Sikora (aka pluto)

unread,
Sep 17, 2003, 10:32:28 AM9/17/03
to
Piotr KUCHARSKI wrote:

> Lukasz Trabinski <luk...@trabinski.net> wrote:
>> Polecam przeczytać:
>> http://www.merit.edu/mail.archives/nanog/msg13603.html
>> Generalnie chodzi o to, aby wszelkie błedne, nieistniejące adresy
>> z końcówką .net i .com przekierowywać w jedno miejsce, do
>> do dysponenta domen .net i .com, a dokładniej do VeriSign.
>> O konsekwencjach tegoż, lepiej nawet nie myśleć.
>
> Na początek proponuję:
> cd ~squid/errors/English
> sed 's/%z/Name Error: The domain name does not exist./' ERR_DNS_FAIL \
> > ERR_DNS_FAIL_LAMEVERISIGN
> oraz dodać w odpowiednim miejscu (przed innymi http_access) w squid.conf
> co następuje:
> acl lameverisign dst 64.94.110.11
> http_access deny lameverisign
> deny_info ERR_DNS_FAIL_LAMEVERISIGN lameverisign

ja dorzucilem ciut wiecej, bo mi jeszcze jakies inne strony veri ladowalo.

acl VeriSign dst 64.94.110.0/24 12.158.80.0/24 65.205.248.0/22
http_access deny VeriSign

--
The only thing necessary for the triumph of evil
is for good men to do nothing.
- Edmund Burke

Michal Jankowski

unread,
Sep 17, 2003, 10:32:20 AM9/17/03
to
Piotr KUCHARSKI <cho...@sgh.waw.pl> writes:

> Jedyna słuszna droga jest przez ICANN. Przy okazji, odpowiedź ICANN:
> http://www.iab.org/Documents/icann-vgrs-response.html

_Na co_ wedlug ciebie to jest odpowiedz? Zwroc uwage na _date_ tego
dokumentu!

Otoz wtedy - w styczniu - firma V. zaczela odpowiadac swoim numerkiem
na zapytania zawierajace znaki o kodach >127. Malo kogo to wtedy
obeszlo, bo nazw domen zawierajacych "ogonki" prawie nikt nie probowal
wpisywac.

Zostali skrytykowani przez Hoffmana i nic.

No to teraz poszli krok dalej i wzieli *.com *.net.

MJ

Tomasz Ostrowski

unread,
Sep 17, 2003, 10:32:35 AM9/17/03
to
On Tue, 16 Sep 2003 16:59:52 +0000 (UTC), Lukasz Trabinski wrote:

> Generalnie chodzi o to, aby wszelkie błedne, nieistniejące adresy
> z końcówką .net i .com przekierowywać w jedno miejsce, do
> do dysponenta domen .net i .com, a dokładniej do VeriSign.

Jest już oficjalny patch na BINDa
http://www.isc.org/products/BIND/delegation-only.html
dodający możliwość zastosowania czegoś takiego w named.conf:
zone "com" {
type delegation-only;
};
zone "net" {
type delegation-only;
};
co powoduje, że serwery autorytatywne domen "com" i "net" mogą jedynie
zwracać rekordy typu NS.

Uruchomiłem to u siebie - działa piknie.

Pozdrawiam
Tometzky
--
Best of prhn - najzabawniejsze teksty polskiego UseNet-u
http://rainbow.mimuw.edu.pl/~tometzky/humor/
Chaos zawsze pokonuje porządek, gdyż jest lepiej zorganizowany.
[ Terry Pratchett ]

Przemyslaw Frasunek

unread,
Sep 17, 2003, 10:32:08 AM9/17/03
to
Piotr KUCHARSKI <cho...@sgh.waw.pl> napisał(a):

> "Usługa" nie odpowiada 64.94.110.11 na zapytania o adresy, z których
> chcemy skorzystać przy http lub smtp (jak by chcieli), tylko na wszystkie.
> Oczywiście http i smtp są najbardziej wykorzystywane. Ale "usługa" psuje
> wszystko.

Przy okazji, "usluga" ma male klopoty z wydajnoscia:

riget:venglin:~> telnet adgfjlkafjgklajfgkl.com 80
Trying 64.94.110.11...
^C
riot:root:~# telnet 64.94.110.11 80
Trying 64.94.110.11...
Connected to sitefinder-idn.verisign.com.
Escape character is '^]'.
^]
telnet> cl
Connection closed.
riot:root:~# telnet 64.94.110.11 80
Trying 64.94.110.11...
^C

Tylko jedno na iles polaczen sie udaje.

--
* Fido: 2:480/124 ** WWW: http://www,frasunek,com/ ** NIC-HDL: PMF9-RIPE *
* Inet: przemyslaw$frasunek,com ** keyId: CD3F1FE5 | C0613BE3 | EC78FAB5 *

Przemyslaw Frasunek

unread,
Sep 17, 2003, 10:32:39 AM9/17/03
to
Piotr KUCHARSKI <cho...@sgh.waw.pl> napisał(a):

> Tymczasowo można tak zrobić. W długim okresie lepiej systemowo => ICANN.

[...]
The Internet Software Consortium promises to release a patch to its
(in)famous BIND that will block the controversial Site Finder.
[...]

http://www.wired.com/news/technology/0,1282,60473,00.html

Piotr KUCHARSKI

unread,
Sep 17, 2003, 10:39:27 AM9/17/03
to
Michal Jankowski <mic...@fuw.edu.pl> wrote:
>> Jedyna słuszna droga jest przez ICANN. Przy okazji, odpowiedź ICANN:
>> http://www.iab.org/Documents/icann-vgrs-response.html
> _Na co_ wedlug ciebie to jest odpowiedz? Zwroc uwage na _date_ tego
> dokumentu!
> Otoz wtedy - w styczniu - firma V. zaczela odpowiadac swoim numerkiem
> na zapytania zawierajace znaki o kodach >127.

Tak. I już wtedy spotkało się to z dezaprobatą.

> Malo kogo to wtedy
> obeszlo, bo nazw domen zawierajacych "ogonki" prawie nikt nie probowal
> wpisywac.

Bo nie są legalne. Ogonki są pobłogosławione przez IDN (tj. xn--).

> Zostali skrytykowani przez Hoffmana i nic.
> No to teraz poszli krok dalej i wzieli *.com *.net.

Z ww. wynika, że ICANN/IAB się to nie podoba. Mają prawo zabrać
V. net i com.

Michal Jankowski

unread,
Sep 17, 2003, 11:39:10 AM9/17/03
to
Tomasz Ostrowski <tometzk...@zodiac.mimuw.edu.pl> writes:

> co powoduje, że serwery autorytatywne domen "com" i "net" mogą jedynie
> zwracać rekordy typu NS.

Bardzo ladne rozwiazanie nieopierajace sie na konkretnym numerze IP.
Podoba mi sie.

MJ

Tomasz Ostrowski

unread,
Sep 17, 2003, 12:33:27 PM9/17/03
to
On Wed, 17 Sep 2003 15:39:10 +0000 (UTC), Michal Jankowski wrote:

>> serwery autorytatywne domen "com" i "net" mogą jedynie zwracać
>> rekordy typu NS.
>
> Bardzo ladne rozwiazanie nieopierajace sie na konkretnym numerze IP.
> Podoba mi sie.

Niestety dość proste do obejścia przez Verisign. Wystarczy, że zamiast
zwracać A będą zwracać NS na swój serwer, który z kolei będzie zwracać
A do wszystkich zapytań. Wtedy chyba tylko filtrowanie po IP zostanie.

Lukasz Trabinski

unread,
Sep 17, 2003, 6:43:58 PM9/17/03
to
Tomasz Ostrowski <tometzk...@zodiac.mimuw.edu.pl> wrote:
>
> Niestety dość proste do obejścia przez Verisign. Wystarczy, że zamiast
> zwracać A będą zwracać NS na swój serwer, który z kolei będzie zwracać
> A do wszystkich zapytań. Wtedy chyba tylko filtrowanie po IP zostanie.

Pomyslow jest coraz wiecej :)
http://www.merit.edu/mail.archives/nanog/msg13715.html
http://www.merit.edu/mail.archives/nanog/msg13727.html
Tyle, ze punktu widzenia np. ISP, to raczej nie powinno sie tak robic -
IMHO zadaniem ISPow jest routowac wszystko.

Piotr KUCHARSKI

unread,
Sep 17, 2003, 6:57:13 PM9/17/03
to
Lukasz Trabinski <luk...@trabinski.net> wrote:
> Pomyslow jest coraz wiecej :)

Dość oczywiste.

> Tyle, ze punktu widzenia np. ISP, to raczej nie powinno sie tak robic -
> IMHO zadaniem ISPow jest routowac wszystko.

Tyle że z punktu widzenia np. klientów to raczej nie powinno się tak
robić -- IMHO zadaniem rejestratorów jest rejestrować wszystko innym
i nie "podkradać" wszystkiego, co nie jest zarejestrowane.

tm

unread,
Sep 21, 2003, 10:32:55 AM9/21/03
to
On Tue, 16 Sep 2003 16:59:52 +0000 (UTC), Lukasz Trabinski wrote:

> Witam
> Polecam przeczytać:
> http://www.merit.edu/mail.archives/nanog/msg13603.html
> Generalnie chodzi o to, aby wszelkie błedne, nieistniejące adresy
> z końcówką .net i .com przekierowywać w jedno miejsce, do
> do dysponenta domen .net i .com, a dokładniej do VeriSign.

ISC zapowiada wypuszczenie łaty do Binda:

http://www.wired.com/news/technology/0,1282,60473,00.html

--
Tom

Piotr KUCHARSKI

unread,
Sep 21, 2003, 10:55:15 AM9/21/03
to
tm <ms...@poczta.fm> wrote:
> ISC zapowiada wypuszczenie łaty do Binda:

Taki trochę spóźniony news. Wypuścili 17 września.
A wczoraj nawet dodali nową opcję, "root-delegations-only".

Piotr KUCHARSKI

unread,
Sep 21, 2003, 1:19:18 PM9/21/03
to
Piotr KUCHARSKI <cho...@sgh.waw.pl> wrote:
>> No to teraz poszli krok dalej i wzieli *.com *.net.
> Z ww. wynika, że ICANN/IAB się to nie podoba.

http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html
http://www.icann.org/announcements/advisory-19sep03.htm

0 new messages