Schlagwort: dns

Smart TV

Heu­te kam ein neu­es Smart TV, das alte hat nach ca. 13 Jah­ren den Geist auf­ge­ge­ben (genau­er: ver­ständ­li­chen Ton auf­ge­ge­ben) Dyon heißt die Mar­ke, hat­te ich noch nie gehört, angeb­lich sogar ein deut­scher Her­stel­ler (https://www.dyon.eu/) — ich glau­be das nicht, ver­mut­lich kom­men die Gerä­te doch direkt aus China.

Da wir kein Anten­nen- oder Sat-TV haben, ging die Inbe­trieb­nah­me schnell von­stat­ten, auch Netz war sofort da:

Die 192.168.1.88 ist ein piho­le, der Fern­se­her soll ja auch was gutes bekommen.
Alles funk­tio­niert also, die diver­sen Strea­ming-Diens­te sind ein­ge­rich­tet und funktionieren.

Abschlie­ßend wer­fe ich noch einen Blick in die Logs des piho­le um zu sehen, zu wel­chen Heim­te­le­fo­nier-Sei­ten der Fern­se­her pet­zen möch­te. Stellt sich raus: Der Fern­se­her benutzt den piho­le gar nicht! (und auch nicht die 192.168.1.41)
Ein Ver­dacht kommt auf. Ich log­ge mich also auf dem Rou­ter ein und mache:

root@sokoll-router:/config# tcpdump -i switch0 -n host 192.168.1.92 and port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on switch0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:17:09.293692 IP 192.168.1.92.49962 > 8.8.8.8.53: 45092+ AAAA? logs.netflix.com. (34)
21:17:09.293699 IP 192.168.1.92.49962 > 8.8.8.8.53: 17557+ AAAA? nrdp.prod.cloud.netflix.com. (45)
21:17:09.293704 IP 192.168.1.92.49962 > 8.8.8.8.53: 15435+ A? nrdp51-appboot.netflix.com. (44)
21:17:09.293708 IP 192.168.1.92.49962 > 8.8.8.8.53: 49981+ AAAA? nrdp51-appboot.netflix.com. (44)
21:17:09.293715 IP 192.168.1.92.49962 > 8.8.8.8.53: 52581+ A? nrdp.nccp.netflix.com. (39)
21:17:09.293719 IP 192.168.1.92.49962 > 8.8.8.8.53: 42306+ AAAA? nrdp.nccp.netflix.com. (39)
21:17:09.293724 IP 192.168.1.92.49962 > 8.8.8.8.53: 27213+ A? api-global.netflix.com. (40)
21:17:09.321424 IP 192.168.1.92.49962 > 8.8.8.8.53: 60092+ A? logs.netflix.com. (34)
21:17:09.344818 IP 8.8.8.8.53 > 192.168.1.92.49962: 45092 6/0/0 CNAME logs.dradis.netflix.com., CNAME logs.eu-west-1.internal.dradis.netflix.com., CNAME apiproxy-logging-7d0bf81651765786.elb.eu-west-1.amazonaws.com., AAAA 2a05:d018:76c:b684::5a89:1099, AAAA 2a05:d018:76c:b680::5a89:1099, AAAA 2a05:d018:76c:b682::5a89:1099 (254)
21:17:09.346588 IP 8.8.8.8.53 > 192.168.1.92.49962: 17557 6/0/0 CNAME nrdp.prod.dradis.netflix.com., CNAME nrdp.prod.eu-west-1.internal.dradis.netflix.com., CNAME apiproxy-nrdp-prod-nlb-1-bc4243efc68f31ae.elb.eu-west-1.amazonaws.com., AAAA 2a05:d018:76c:b685:9ae6:e07a:670d:52e4, AAAA 2a05:d018:76c:b683:194f:a5df:2ad1:ab02, AAAA 2a05:d018:76c:b684:b7f5:7e97:3e99:751e (283)
21:17:09.346728 IP 8.8.8.8.53 > 192.168.1.92.49962: 52581 8/0/0 CNAME nrdp.nccp.dradis.netflix.com., CNAME nrdp.nccp.eu-west-1.origin.prodaa.netflix.com., A 52.19.104.71, A 52.49.155.216, A 54.76.160.164, A 52.210.130.122, A 52.210.124.147, A 52.18.41.61 (214)
21:17:09.346868 IP 8.8.8.8.53 > 192.168.1.92.49962: 49981 10/0/0 CNAME appboot.dradis.netflix.com., CNAME appboot.eu-west-1.origin.prodaa.netflix.com., AAAA 2a01:578:3::3410:ea4e, AAAA 2a01:578:3::34d3:322, AAAA 2a01:578:3::34d4:c576, AAAA 2a01:578:3::34d3:3154, AAAA 2a01:578:3::3430:8bf6, AAAA 2a01:578:3::369a:f1ed, AAAA 2a01:578:3::22f0:a04c, AAAA 2a01:578:3::36f6:b554 (343)

Au weia! Es wird unge­be­ten Goo­gles DNS verwendet!
Fra­gen kom­men auf: Das Teil erkennt die per DHCP zuge­wie­se­nen Name­ser­ver — und ver­wen­det sie nicht. War­um? Das­Teil hat kein v6 und fragt doch nach AAAA. Warum?
Nun, ich zise­lie­re mir eine Firewall-Regel:

ubnt@sokoll-router:~$ show configuration commands
[…]
set firewall group address-group google-dns address 8.8.4.4
set firewall group address-group google-dns address 8.8.8.8
[…]
set firewall name LAN_OUT rule 20 action reject
set firewall name LAN_OUT rule 20 description 'Dem Fernseher Google DNS verbieten'
set firewall name LAN_OUT rule 20 destination group address-group google-dns
set firewall name LAN_OUT rule 20 destination port 53
set firewall name LAN_OUT rule 20 log disable
set firewall name LAN_OUT rule 20 protocol udp
set firewall name LAN_OUT rule 20 source address 192.168.1.92
set firewall name LAN_OUT rule 20 source mac-address '18:84:c1:bf:66:f1'
[…]

Und das wirkt, tataa!

root@sokoll-router:/config# tcpdump -i switch0 -n host 192.168.1.92 and port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on switch0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:32:35.659906 IP 192.168.1.92.34723 > 8.8.8.8.53: 23537+ A? logs.netflix.com. (34)
21:32:35.659911 IP 192.168.1.92.34723 > 8.8.8.8.53: 44326+ AAAA? nrdp.prod.cloud.netflix.com. (45)
21:32:35.659916 IP 192.168.1.92.34723 > 8.8.8.8.53: 22112+ A? nrdp51-appboot.netflix.com. (44)
21:32:35.659920 IP 192.168.1.92.34723 > 8.8.8.8.53: 57120+ AAAA? nrdp51-appboot.netflix.com. (44)
21:32:35.659924 IP 192.168.1.92.34723 > 8.8.8.8.53: 44242+ A? nrdp.nccp.netflix.com. (39)
21:32:35.659928 IP 192.168.1.92.34723 > 8.8.8.8.53: 19783+ AAAA? nrdp.nccp.netflix.com. (39)
21:32:35.659932 IP 192.168.1.92.34723 > 8.8.8.8.53: 25321+ A? api-global.netflix.com. (40)
21:32:35.662950 IP 192.168.1.92.43839 > 8.8.8.8.53: 22191+ AAAA? api-global.netflix.com. (40)
21:32:35.662958 IP 192.168.1.92.43839 > 8.8.8.8.53: 64306+ A? secure.netflix.com. (36)
21:32:35.663031 IP 192.168.1.92.43839 > 8.8.8.8.53: 32983+ AAAA? secure.netflix.com. (36)
21:32:35.663041 IP 192.168.1.92.43839 > 8.8.8.8.53: 58766+ A? uiboot.netflix.com. (36)
21:32:35.663049 IP 192.168.1.92.43839 > 8.8.8.8.53: 59032+ AAAA? uiboot.netflix.com. (36)
21:32:35.663094 IP 192.168.1.92.43839 > 8.8.8.8.53: 47968+ A? customerevents.netflix.com. (44)
21:32:35.663132 IP 192.168.1.92.43839 > 8.8.8.8.53: 27882+ A? ichnaea.netflix.com. (37)
21:32:35.663181 IP 192.168.1.92.43839 > 8.8.8.8.53: 18226+ A? cdn-0.nflximg.com. (35)
21:32:35.663231 IP 192.168.1.92.43839 > 8.8.8.8.53: 20002+ A? nrdp.prod.ftl.netflix.com. (43)
21:32:35.663263 IP 192.168.1.92.43839 > 8.8.8.8.53: 42457+ AAAA? nrdp.prod.ftl.netflix.com. (43)
21:32:35.883642 IP 192.168.1.92.43839 > 8.8.8.8.53: 13421+ A? nrdp.prod.cloud.netflix.com. (45)
21:32:36.634192 IP 192.168.1.92.43839 > 8.8.8.8.53: 13421+ A? nrdp.prod.cloud.netflix.com. (45)
21:32:36.787647 IP 192.168.1.92.43839 > 8.8.8.8.53: 44242+ A? nrdp.nccp.netflix.com. (39)

Er befragt wei­ter­hin Goog­le, bekommt aber kei­ne Ant­wor­ten mehr 🤓
Und gleich­zei­tig füllt sich das Log vom piho­le. Und natür­lich funk­tio­niert das Smart am TV immer noch.

Hm, mir fällt gera­de auf, daß ich

set firewall name LAN_OUT rule 20 protocol udp

auf

set firewall name LAN_OUT rule 20 protocol all

ändern soll­te, nicht daß das Teil auf TCP umschwenkt irgendwann.

Was machen 99% der Smart­TV-Nut­zer? Die haben weder das Wis­sen noch die Tech­nik, dem Spio­nie­ren wenigs­tens ein wenig ent­ge­gen­zu­tre­ten. Klar könn­te man das Ether­net zie­hen und einen Fire­stick oder so direkt an HDMI anflan­schen. Aber ob der weni­ger spio­nie­ren würde?
Wobei ich sagen möch­te: Dem TV-Her­stel­ler wer­fe ich kei­ne Bös­ar­tig­keit vor, er lie­fert sei­ne Kun­den man­gels Sorg­falt ein­fach den Daten­kra­ken aus, was im End­ef­fekt aber egal ist. Das TV soll ein­fach das anneh­men, was man ihm sagt, und gut wäre es.

 

Ins Knie schießen für Fortgeschrittene

Ges­tern ging @workplace das Dra­ma los:
DNS-Reso­lu­ti­on für unse­re Hosts ging mal, mal nicht mit SRVFAIL. Unser eige­ner auto­ri­ta­ti­ver Ser­ver hat­te kei­ne Pro­blem, aber der Rest der Welt: 1.1.1.1, 8.8.8.8, 9.9.9.9 und so wei­ter. Alle wie ein Blin­ker: An-Aus-An-Aus.
Als anstän­di­ger Hob­by-Admin betrei­be ich die frag­li­che Zone natür­lich mit DNSSEC, seit vie­len Jah­ren völ­lig schmerzlos.
Doch ges­tern zeig­te mir Dns­viz viel rot:

Very uncool. Nun KANN das eigent­lich gar nicht pas­sie­ren, ich habe in mei­nem bind die Zone so konfiguriert:

zone "sagich.nicht" {                                                                                                                                                                                                                          
  type master;                                                                                                                                                                                                                           
  auto-dnssec maintain;                                                                                                                                                                                                                  
  key-directory "/keys";                                                                                                                                                                                                                 
  inline-signing yes;                                                                                                                                                                                                                    
  file "sagich.nicht";                                                                                                                                                                                                         };

Das gan­ze Sig­ning pas­siert also auto­ma­tisch, und das seit Jah­ren, und dar­an hat sich auch nichts geän­dert. Kru­zi­tür­kn! Ich bin kein DNS­SEC-Pro­fi, wie gesagt, das läuft seit Jah­ren sta­bil und ohne mensch­li­ches Eingreifen.

Heu­te früh dann noch mal mit fri­schem Tee einen Blick in die Run­de gewor­fen: Mein Pri­ma­ry hat eine Seri­al von 2021021014, wäh­rend der Secon­da­ry 2021070247 hat. Let’s do the math: 2021021014 < 2021070247. Wenn man Seri­al schreibt, hat sich die Schreib­wei­se YYYYMMDDzwei­stel­li­ge­sin­kre­ment bewährt. Es gibt im Fir­men-DNS (hof­fent­lich) nur zwei Men­schen, die da schrei­ben können/dürfen — einen Kol­le­gen und mich. Der höhe­ren Seri­al 2021070247 nach zu urtei­len, hat jemand am 07. 02. 2021 die Seri­al erhöht, um einen gewal­ti­gen Sprung. Was zur Fol­ge hat­te, daß der Secon­da­ry ab die­sem Zeit­punkt kei­ne Noti­fies mehr ent­ge­gen­nahm, war­um auch. Auch nicht die Noti­fies, daß sie die RRSIGs geän­dert haben…
Ich für mei­nen Teil kann mich nicht erin­nern, am 7. 2. im DNS geschmiert zu haben — was aber nicht all­zu­viel bedeu­tet, viel­leicht habe ja doch ich das vergeigt.
Jetzt müs­sen wir war­ten, bis der Admin des Secon­da­ries die Zone bei sich löscht und neu zieht, dann ist hof­fent­lich alles wie­der schön.

#sel­flart #dns #dns­sec