Zdravim,
snazim se podle navodu IPv6-only síť s NAT64 zprovoznit na Turris Omnia 2020 (DNS resolver KNOT) preklad IPv6 na IPv4.
Resolver KNOT mi bohuzel i po nastaveni dle navodu stale vraci originalni IPv6 misto fiktivni 64:ff9b::/96. Mate prosim nekdo zkusenost s nastavenim DNS64 ?
Dekuji JKon
Ahoj,
můžeš prosím více rozepsat, co myslíš tím
Resolver KNOT mi bohuzel i po nastaveni dle navodu stale vraci originalni IPv6 misto fiktivni
64:ff9b::/96.
případně poslat více detailů?
Kdyz na klasickem PC zprovoznim TAYGA + BIND6 (jako DNS64), tak pri dotazu na IPv6 na www.seznam.cz dostanu “falesnou IPv6”:
dig www.seznam.cz AAAA
; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.seznam.cz AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30363
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.seznam.cz. IN AAAA
;; ANSWER SECTION:
www.seznam.cz. 92 IN AAAA 64:ff9b::4d4b:4ab0
www.seznam.cz. 92 IN AAAA 64:ff9b::4d4b:4bb0
www.seznam.cz. 92 IN AAAA 64:ff9b::4d4b:4aac
www.seznam.cz. 92 IN AAAA 64:ff9b::4d4b:4bac
kterou TAYGA prevede na IPv4 (prave IPv6 necha byt).
Ovsem kdyz na Turrisu nastavim KNOT dle navodu:
/etc/kresd/dns64.conf
modules.load('dns64')
dns64.config('64:ff9b::')
tak na dotaz IPv6 dostanu pravou IPv6:
dig www.seznam.cz AAAA
; <<>> DiG 9.16.18 <<>> www.seznam.cz AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12760
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.seznam.cz. IN AAAA
;; ANSWER SECTION:
www.seznam.cz. 300 IN AAAA 2a02:598:4444:1::1
www.seznam.cz. 300 IN AAAA 2a02:598:4444:1::2
www.seznam.cz. 300 IN AAAA 2a02:598:3333:1::1
www.seznam.cz. 300 IN AAAA 2a02:598:3333:1::2
takze TAYGA nezacne IPv6 prekladat na IPv4.
Moje konfigurace Knot resolveru je takováto:
# cat /etc/kresd/dns64.config
modules.load('dns64')
dns64.config('64:ff9b::')
# cat /etc/config/resolver
…
config resolver 'kresd'
…
option include_config '/etc/kresd/dns64.config'
Jinak pro doménová jména, která mají nativní IPv6 adresu se DNS64 nepoužije, takže to, že resolver vrací originální IPv6 místo fiktivní 64:ff9b::/96 není závada, ale vlastnost. Abyste dostal tuto syntetickou adresu, je třeba se zeptat na doménové jméno bez IPv6 adresy, například:
# dig ipv4only.arpa aaaa +short
64:ff9b::c000:ab
64:ff9b::c000:aaSeznam je dostupný po IPv6. Není žádný důvod se k němu připojovat přes NAT64.
Jaké máte nastavení toho BINDu? Tohle rozhodně není standardní chování.
Nase sit (provider) nema IPv6, bohuzel SW, ktery je na vnitrni siti vyzaduje IPv6, takze potrebuju veskery IPv6 provoz (vcetne napr. seznamu, googlu …) prevezt na IPv4.
Podle
jsem nastavil:
setup TAYGA: /etc/tayga.conf
tun-device nat64
ipv4-addr 10.6.0.1
prefix 64:ff9b::/96
dynamic-pool 10.6.0.0/24
data-dir /var/spool/tayga
setup DNS64: /etc/bind/named.conf
options {
# Ubuntu BIND's default options.
# Might need to tweak this if you use some other distribution.
directory "/var/cache/bind";
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
# Make sure our nameserver is not abused by external
# malicious users.
allow-query { any; };
# This enables DNS64.
dns64 64:ff9b::/96 {
clients { any; };
exclude { any; };
};
};
Aha, ten návod jaksi předpokládá router Turris s IPv6 konektivitou.
V takovém případě opravdu potřebujete BIND, ten jediný je možné nastavit tak, aby syntetizoval AAAA záznamy i v případě, kdy dané jméno má AAAA záznam – to dělá právě ta volba exclude { any; };
Ostatní DNS resolvery tuto funkci nemají.
Druhá možnost je zavést do dané sítě IPv6, třeba tunelem.
Aha, tak tim se to vysvetluje 
Dekuji moc spolupraci 
Když o tom tak přemýšlím, napadá mě, že bez IPv6 konektivity nebude router nabízet výchozí bránu do lokální sítě, takže zařízení v lokální síti se nejspíš s NAT64 stejně nebudou chtít spojit.
Ano, je to tak, branu pro IPv6 jsem na klientech musel nastavit rucne i kdyz IPv6 pres DHCP dostali :-/
No, přidat tu vlastnost do kresd je relativně jednoduché, jen patchnutím dns64.lua (při zachování ostatních vlastností/nedostatků dns64 modulu). Ale není mi jasné jestli tohle je extrémní případ (který má možná navíc jiné lepší řešení), nebo se skutečně občas stává že se taková věc hodí.
Myslím, že to je dost okrajový požadavek. Já osobně bych mnohem víc ocenil podporu pro PTR záznamy a možnost provádět syntézu jen pro určitou část klientů.
Mohl bych poprosit o kontretni settings pro dns64.lua ? (trochu se v tom zracim …)
Což to samozřejmě, v tom modulu chybí části které jsou dle RFC povinné (třeba to PTR). Akorát ty nejsou jako tenhle případ, kdy jsem napsal nějaké řešení za minutu (které neovlivňuje normální nastavení).
Nastavení samo o sobě nestačí. Upravit/přepsat lokálně /usr/lib/knot-resolver/kres_modules/dns64.lua naštěstí není těžké, jen to každý update přemaže, takže to určitě nebude uspokojivé (pokud se to nedostane do skutečného releasu).
Soubor/úprava by mohla vypadat třeba takto (popsáno v commit message): master...dns64-force · Knot projects / Knot Resolver · GitLab
Mockrat dekuji za cas i ochotu, patch dela presne co potrebuji tj. KNOT vraci pro vsechny AAAA dotazy syntetickou/falesnou IPv6
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.
Jen přidám odkaz, ty tři featury zmíněné tady jsou řešeny v modules/dns64: new features (!1201) · Merge requests · Knot projects / Knot Resolver · GitLab
Tu force = true volbu jsem nakonec vyhodil. RFC vyžaduje (MUST) možnost pro zákaz některých IPv6 prefixů v odpovědích, což je teď implementováno výše a tak se zákaz pro ::/0 chová stejně jako ta navrhovaná implementace force = true. Takže výsledkem bude i situace konzistentnější s BIND.