AS112

uruchomiłem właśnie dzięki inspiracji od Roberta Woźnego, dwie osobne instancje AS112 w Polsce. stało się to możliwe dzięki wspaniałym ludziom dobrej woli w ATMAN:

…oraz w EPIX:

o co w ogóle w tym AS112 chodzi?

as112

AS112 to międzynarodowy projekt który lokalnie obsługuje zapytania przychodzące ze źle skonfigurowanych lub źle działających klientów DNS (to może oznaczać Twojego domowego PeCeta ale także komputer w firmie). chodzi o zapytania które “wyciekają” z sieci lokalnych i zawierają zapytania w stylu “jaką nazwę ma 192.168.0.1?”. ponieważ pytania te nie zamykają się w sieci lokalnej, “wyciekają” i podróżują aż do samych serwerów root DNS. o ile samo pytanie ma sens, adresy prywatne zwykle nie są unikalne - i nikt na takie zapytania nie odpowie niczym sensownym. nie powinny się nawet pojawiać w publicznej przestrzeni internetowej. tak naprawdę, złośliwy aktor mógłby nieco namieszać będąc w stanie przechwytywać takie zapytania i odpowiadając na nie w odpowiednio sprytny sposób.

najważniejsze jest jednak to, że takie zapytania obciążają tylko istniejące usługi DNS i generują szum - powodując, że tracimy niepotrzebnie zasoby, w szczególności serwerów root DNS. mają one swoją pracę do wykonania i są częścią krytycznej infrastruktury utrzymującej cały internet. w najgorszym dla nich przypadku, rozbudowanie infrastruktury takiej jak AS112 pozwoli nieco odciążyć je przed atakiem DDoS.

AS112 odciąża serwery root DNS od tych zapytań i zamyka je na poziomie najbliższej lokalnej instancji (dzięki magii anycastu). instancja ta, nie robi nic innego tylko odpowiada na takie zapytania w imieniu serwerów root DNS. jeden z takich serwerów został skolokowany w serwerowni ATMAN, a drugi - punkcie wymiany ruchu EPIX. oba pracują pod kontrolą systemu FreeBSD, OpenFRR jako stosem BGP oraz serwerem BIND 9 jako serwerem nazw.

nie ma specjalnej magii w konfiguracji tych usług, więc w typowy transparentny sposób pozwólcie, że podzielę się informacją, jak poszczególne komponenty są skonfigurowane. jeśli szukasz większej ilości informacji i innych przykładów konfiguracji, warto zajrzeć do dwóch RFC jak również na stronę projektu AS112.

konfiguracja BIND 9

konfiguracja BINDa sprowadza się do paru podstawowych rzeczy - nasłuchiwania na odpowiednich interfejsach IP i odpowiadaniu na odpowiednie zapytania (i tylko na nie). należy wyłączyć rekursywne rozwiązywanie nazw i oczywiście transfery stref. pozostałe ustawienia są właściwie dowolne, zależne od Twoich celów - logowanie (bądź nie) zapytań, utwardzenie części konfiguracji i oczywiście radosną zabawę z odpowiadaniem przez BINDa na pytania o version, hostname i server-id ;)

tak więc konfiguracja:

[as112 /usr/local/etc/namedb]$ more named.conf
options {
// opcje - pomijamy te nieistotne

// nasze IP, na których nasłuchujemy - część usługi anycast:
        listen-on       { 192.175.48.1;      // prisoner.iana.org
                          192.175.48.6;      // blackhole-1.iana.org
                          192.175.48.42;     // blackhole-2.iana.org
                          192.31.196.1; };   // blackhole.as112.arpa
// nie, nie chcemy być resolverem DNS ;)
        recursion              no;
        minimal-responses      yes;
        minimal-any            yes;
        allow-transfer         { none; };
        version                "1.0.0";
        hostname               "AS112";
        server-id              "DNS";
};

// strefy, które serwujemy i odpowiadamy na pytania:

zone "10.in-addr.arpa" { type master; file "m/db.RFC-1918"; };

zone "16.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };
zone "17.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };
zone "18.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };
zone "19.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };
zone "20.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };
zone "21.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };
zone "22.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };
zone "23.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };
zone "24.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };
zone "25.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };
zone "26.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };
zone "27.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };
zone "28.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };
zone "29.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };
zone "30.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };
zone "31.172.in-addr.arpa" { type master; file "m/db.RFC-1918"; };

zone "168.192.in-addr.arpa" { type master; file "m/db.RFC-1918"; };

zone "254.169.in-addr.arpa" { type master; file "m/db.RFC-1918"; };

// nasza własna instancja z danymi identyfikującymi instancję AS112

zone "empty.as112.arpa" { type master; file "m/db.RFC-1918.empty"; };

zone "hostname.as112.net" { type master; file "m/db.hostname.as112.net"; };
zone "hostname.as112.arpa" { type master; file "m/db.hostname.as112.arpa"; };

pliki stref mają ustandaryzowaną zawartość - najpierw m/db.RFC-1918:

$TTL 1W
@ IN SOA prisoner.iana.org. hostmaster.root-servers.org. (
                         1 1W 1M 1W 1W );
     NS blackhole-1.iana.org.
     NS blackhole-2.iana.org.

następnie m/db.hostname.as112.net:

$TTL 1W
@ IN SOA as112.bromirski.net. info.bromirski.net. (
                         1 1W 1M 1W 1W );

     TXT "Nazwa Twojej instancji"
     TXT "Miasto, Polska"
     TXT "See http://as112.net/ for more information."
     TXT "See https://lukasz.bromirski.net/post/as-112/ for more information."
     NS blackhole-1.iana.org.
     NS blackhole-2.iana.org.

i prawie identyczna strefa m/db.hostname.as112.arpa dla domeny arpa:

$TTL 1W
@ IN SOA as112.bromirski.net. info.bromirski.net. (
                         1 1W 1M 1W 1W );

     TXT "Your local name for the instance"
     TXT "City, Poland"
     TXT "See http://as112.net/ for more information."
     TXT "See https://lukasz.bromirski.net/post/as-112/ for more information."
     NS blackhole.as112.arpa.

ostatni plik to strefa dla domeny as112.arpa z danymi kontaktowymi wskazującymi na NOC ICANN - w naszym przypadku, trzymamy go w pliku db.RFC-1918.empty:

$TTL    1W
@ IN SOA blackhole.as112.arpa. noc.dns.icann.org. (
                                  1       ; serial number
                                  1W      ; refresh
                                  1M      ; retry
                                  1W      ; expire
                                  1W )    ; negative caching TTL

     NS     blackhole.as112.arpa.

A tak w ogóle, jeśli chcesz aby serwer DNS udzielał odpowiedzi na zapytania do tej strefy dokładnie w tej kolejności, dodaj rrset-order { order fixed; }; do konfiguracji serwera named. generalnie nie jest to najlepszy pomysł, bo losowe ustawianie kolejności odpowiedzi pozwala odpowiednio rozłożyć obciążenie - w tym przypadku można jednak się o to pokusić.

konfiguracja OpenFRR

OpenFRR jest nam potrzebny do dwóch rzeczy:

  • zestawienia sesji BGP ze swoimi operatorami nadrzędnymi
  • rozgłoszenia prefiksów należących do projektu AS112

żeby to osiągnąć, użyjemy dwóch demonów z pakietu, konfigurowanych przez pliki bgpd.conf i staticd.conf.

tak więc, najpierw konfiguracja BGP z pliku bgpd.conf:

!
hostname as112.colo.bgpd
password bardzo-trudne-haslo
enable password jeszcze-trudniejsze-haslo
log file /usr/local/etc/frr/bgpd.log ! jesli pojawia sie problemy
service advanced-vty
service password-encryption
!
!
!
router bgp 112
 bgp router-id A.B.C.D ! router-ID twojego routera
 no bgp default ipv4-unicast
 neighbor 169.254.1.1 remote-as 65055     ! adres IPv4 routera operatora
 neighbor 169.254.1.1 description ISP-1   ! opis
 neighbor 169.254.1.1 ebgp-multihop 3     ! zwykle sesja jest typu eBGP multihop
 neighbor 2001:db8::1 remote-as 65055     ! adres IPv4 routera operatora
 neighbor 2001:db8::1 description ISP-1   ! opis
 neighbor 2001:db8::1 ebgp-multihop 3     ! zwykle sesja jest typu eBGP multihop
 !
 ! czasami tutaj dochodzą dodatkowe opcje, jak np. ustawienie
 ! BFD na sesjach czy interfejsu źródłowego z którego mają być
 ! zestawiane sesje
 !
 address-family ipv4 unicast
  ! konfiguracja specyficzna dla adresów IPv4
  network 192.31.196.0/24      ! pierwszy prefiks AS112
  network 192.175.48.0/24      ! drugi prefiks AS112
  neighbor 169.254.1.1 activate
  neighbor 169.254.1.1 prefix-list AS112-IN in
  neighbor 169.254.1.1 route-map AS112-v4-OUT out
 exit-address-family
 !
 address-family ipv6 unicast
  ! konfiguracja specyficzna dla adresów IPv6
  network 2001:4:112::/48      ! pierwszy prefiks AS112
  network 2620:4f:8000::/48    ! drugi prefiks AS112
  neighbor 2001:db8::1 activate
  neighbor 2001:db8::1 prefix-list AS112-IN in
  neighbor 2001:db8::1 route-map AS112-v6-OUT out
 exit-address-family
!
ip prefix-list AS112-v4 seq 5 permit 192.175.48.0/24
ip prefix-list AS112-v4 seq 10 permit 192.31.196.0/24
!
ipv6 prefix-list AS112-v6 seq 5 permit 2620:4f:8000::/48
ipv6 prefix-list AS112-v6 seq 10 permit 2001:4:112::/48
!
ip prefix-list AS112-IN seq 10 deny any
!
route-map AS112-v4-OUT permit 10
 ! ta route-mapa upewnia się, że rozgłaszamy tylko odpowiednie prefiksy
 ! i ustawia atrybuty (opcjonalnie ale elegancko)
 set origin igp
 set community 112:112
 match ip address prefix-list AS112-v4
route-map AS112-v6-OUT permit 10
 ! ta route-mapa upewnia się, że rozgłaszamy tylko odpowiednie prefiksy
 ! i ustawia atrybuty (opcjonalnie ale elegancko)
 set origin igp
 set community 112:112
 match ipv6 address prefix-list AS112-v6
!
line vty
!

natomiast plik staticd.conf kontroluje trasy statyczne, które OpenFRR dorzuca do konfiguracji hosta. jest to potrzebne procesowi BGP, który lubi mieć dokładny wpis routingu do swojego sąsiada i nie lubi tras domyślnych. korzyść z dodania tych tras w OpenFRR zamiast w lokalnych plikach rc.conf czy rc.conf.local jest taka, że po zamknięciu OpenFRR trasy automatycznie są kasowane. YMMV.

!
hostname as112.colo.staticd
password bardzo-trudne-haslo
enable password jeszcze-trudniejsze-haslo
!
ip route 169.254.1.1/32 A.B.C.D        ! trasa statyczna do sąsiada eBGP IPv4
                                       ! przez Twoją bramkę
ipv6 route 2001:db8::1/128 2001:db8::X ! trasa statyczna do sąsiada eBGP IPv4
                                       ! przez Twoją bramkę
!

ponieważ używamy FreeBSD a nie jakiejś koszmarnej, fundamentalnie zepsutej i generalnie szalonej dystrybucji Linuksa używającej systemd, konfiguracja dla named i OpenFRR znajduje się w lokalnym pliku systemowym /etc/rc.conf.local:

# BIND 9
named_enable="YES"

# OpenFRR
frr_enable="YES"
frr_flags="-A 127.0.0.1"
frr_daemons="bgpd staticd"

podsumowanie

co powinieneś zrobić, żeby skorzystać z tej usługi? całe piękno polega na tym, że nic. Twoi operatorzy sami skierują ruch do najbliższej dostępnej usługi projektu AS112. czy będzie to nasza? oczywiście to zależy skąd pytasz, ale jeśli z jednego z operatorów w Polsce - są pewne szanse. można to prosto sprawdzić wykonując:

dig +short hostname.as112.net txt
"AS112 ATMAN colo"
"Warszawa, Poland"
"See http://as112.net/ for more information."
"See https://lukasz.bromirski.net/post/as-112/ for more information."

jeśli wynik jest podobny jak powyżej - nie trzeba tłumaczyć :) mamy jeszcze inną instancję AS112 w Polsce - dzięki dobrym ludziom w gdyńskim Aplitt S.A..