alias/CNAME einrichten

Hi

Um den Traffic weiter zu senken habe ich ntp installiert, und mit hilfe aus diesem Forum Option 42 aktiviert, welche dafür sorgt dass der Pi-Hole mittels DHCP Server den Clients die Zeit aufdiktiert. Wie das geht lest ihr hier:

Allerdings habe ich bemerkt das der NTP Trafik dadurch nicht komplett verschwindet. Um das zu beheben möchte ich nun für den Pi-Hole verscheiden alias/CNAME einrichten.

host pi.hole
CNAME pihole.meine.fld
alias time.android.com
alias time-ios.apple.com

https://support.dnsimple.com/articles/differences-between-a-cname-alias-url/

Weiß hier zufällig jemand wie das mit Pi-Hole5 geht?

Nein, geht noch nicht, ist aber schon in Bearbeitung

Du könntest natürlich versuchen, das über Local DNS Records zu lösen.

1 Like

Mit einem CNAME-Record delegierst Du die Auflösung eines Hostnamens auf einen weiteren Hostnamen (in Deinem Fall aufpihole.meine.tld).
Das wäre z.B. dann sinnvoll, wenn das Delegationsziel nur über einen Pool von IP-Adressen erreichbar wäre oder wenn sich die IP-Adresse ständig ändern würde.
Bei einer Auflösung im Heimnetz ist Pi-hole für gewöhnlich immer unter derselben IP-Adresse erreichbar.

Mit der von yubiuser vorgeschlagenen Definition entsprechender lokaler DNS-Einträge könntest Du also die gewünschte Auflösung von time.android.com und time-ios.apple.com auf Pi-holes IP-Adresse definieren.

Ich würde einen RPI allerdings nicht unbedingt als Zeitserver empfehlen: Wegen der fehlenden Hardware-Echtzeituhr (RTC) ist der RPi gezwungen, sich die Zeit aus dem Internet zu besorgen. Da dies nur periodisch geschieht, kann es dabei durchaus zu größeren Abweichungen kommen, und insbesondere nach einem Reboot kann es dann auch schon einmal einige Minuten dauern, bis die Zeit wieder korrekt ist.
Für Pi-hole ist das im normalen DNS-Betrieb vernachlässigbar. Habe ich nur Fernseher, Smartphones und PCs im Heimnetz, geht das ebenso. Anders sieht das für Pi-hole schon aus, wenn man DNSSEC zur Echtheitsvalidierung der DNS-Records einsetzt - hier kommt es auf eine korrekte Uhrzeit an.

Wenn meine anderen Geräte im Netz jedoch kritisch von einer korrekten Zeit abhängig wären (Heizungssteuerung, Fütterungsautomat, Bewässerung,..), würde ich sie die Uhrzeit nicht über einen RPi beziehen lassen, oder meinen RPi um eine RTC-Hardware erweitern.

1 Like

@Bucking_Horn
Die Idee gefällt mir, hast du irgendwelche Erfahrungswerte? Schatze das die RasClock wohl reichen, und auch ins's ArgonOne passen würde. Wenn du aber die Wahl hättest, und die Butgetfreiheit gegeben wäre, für was würdest du dich entscheiden? ..also für den Pi4 meine ich. :grin: :grin:

@yubiuser
Die Zukunft gefällt mir. :wink:

Wäre schon wenn das Projekt sich nicht nur auch CNAME beschränken, und auch andere DNS-Records wie ALIAS, SSHFP, TLSA, DNSKEY usw. berücksichtigen würde.

Die derzeitige Lösung mit A- und AAAA-Record scheint zwar auch zu funktionieren, und womöglich auch besser als Option 42, dennoch irgenwie nicht so ganz zufriedenstellend. :wink:

Feature requests sind willkommen :wink:

1 Like

Muss zugeben das mach schon laune..

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Raspbian <<>> time.android.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57433
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;time.android.com.		IN	A

;; ANSWER SECTION:
time.android.com.	2	IN	A       Local.Pi.Hole.IP

;; Query time: 0 msec (!11)
;; SERVER: Local.Pi.Hole.IP#53(Local.Pi.Hole.IP)
;; WHEN: Mon Jun 22 07:24:02 CEST 2020
;; MSG SIZE  rcvd: 61

..und bringt auch einiges. Speziell im zusammenspiel mit LAN und IoT im selbe Netz. Bei mir ist der Prozentsatz der geblockten recht tief. So um die 5% oder weniger. Das liegt primär am Hausleit-Server der jeden Schritt mit der Cloud Synchronisiert, und den vielen NTP abfragen. Letzteres auf den Pi zu leiten erhöht Performance, Zuverlässigkeit und den Prozentsatz der geblockten.

btw
/etc/ntp.conf ist bei mir so eingerichtet


# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Leap seconds definition provided by tzdata
leapfile /usr/share/zoneinfo/leap-seconds.list

# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
#pool 0.debian.pool.ntp.org iburst
#pool 1.debian.pool.ntp.org iburst
#pool 2.debian.pool.ntp.org iburst
#pool 3.debian.pool.ntp.org iburst
server pool.ntp.org
server time.nist.gov
server clock.isc.org



# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Needed for adding pool entries
restrict source notrap nomodify noquery

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

..und /etc/dnsmasq.d/05-pihole-custom-dhcp.conf habe ich so eingerichtet.

# DNS
# dhcp-option=6,10.0.0.1 10.0.0.2
# NTP Server
dhcp-option=42,Local.Pi.Hole.IP
# SIP Server
# dhcp-option=120,10.0.0.3
# Time Offset in Seconds from UTC
dhcp-option=2,3600

Ansonsten bin ich -damals noch mit Pi-Hole 4- zu weiten teilen dieser Anleitung gefolgt
https://forum.kuketz-blog.de/viewtopic.php?f=42&t=3067

Hardware-Empfehlungen finde ich immer wenig repräsentativ, schliesslich verbaut man die Sachen nicht tausendfach und kann mit seinem Exemplar sowohl Glück als auch Pech haben. Und dann kommt es ja auch immer auf die Umstände vor Ort an, bereits vorhandene HATs oder Platzangebot im bestehenden Gehäuse kann da z.B. ein limitierender Faktor sein.

Ich würde mich nach einem preiswerten Modul auf Basis eines DS3231 umsehen. Die sind meist nicht viel größer als eine Knopfzelle und derzeit für drei bis vier Euro zu haben (ohne Batterie).

1 Like

Ok, passt. :+1:
Dann schnapp ich mir die High Accuracy Pi RTC (DS3231) von Seeed. :wink:
Wollt's auch bloß wißen wegen GPS und zeugs. Aber so passt das recht gut. Vielen dank.

Ich würde mal sagen, ist hier abgeschlossen. Lösung kommt dann in Zukunft. Für euch gut so?

Für mich ja.

1 Like

Ich halte in Deinem Fall yubiusers Empfehlung zur Anlage von Custom DNS records für die korrekte Lösung - warum, habe ich schon erläutert. Für die zusätzliche Indirektion/Delegation über CNAME sehe ich im geschilderten Szenario keinen Grund.

Daher fände ich es passender, den Titel zu ändern (z-B. auf NTP-Syncs für time.android.com und time-ios.apple.com im Heimnetz auf Pi-hole umleiten) und yubiusers Beitrag als Lösung zu markieren.

Es sei denn, Du hast Dich mit bislang mit noch einem anderen Grund für Deinen CNAME-Wunsch zurückgehalten. :wink:

Ist ne sache der Redundanz. Mein Netzwerk ist so ausgerichtet daß Dnsmasq ausfallen darf. Desweiteren sind LAN/WAN Adressen so wie IPv4/6 nicht im selben pool, es sei den sie werden durch ein CNAME vereint. Wobei jetzt nicht die Idee sein soll, google.com öffentlich auf mein Pi umzuleiten. :wink: