garnicht?

wieso sollten sie auch?

Und warum nicht! DNSSEC wird der Standard!

https://www.denic.de/wissen/dnssec/

https://de.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

https://www.nic.at/de/wissenswertes/nicat-technologie/dns-und-dnssec

Vermutlich zukünftig sogar noch eine Stufe höher = DNS over TLS (DoT) - eine verschlüsselte Kommunikation zw. Anforderer und Name-Server.

https://de.wikipedia.org/wiki/DNS_over_TLS

Und die beiden A1 Bussinnes Nameserver beherrschen doch auch DNSSEC!

BIND named, NSD, unbound beherrschen DNSSEC.

Ich habe lokal einen BIND named DNSSEC als Cache & Resolve laufen - das zu konfigurieren ist keine Hexerei! Detto auch beim Resolver DNS unbound (den hatte ich auch schon mal laufen).

Am Mac ist das, dank Unix Unterbau, keine Hexerei das zum Laufen zu bringen! Soll ich Euch Support Hilfe anbieten?

Weil dann A1 nicht mehr die Antworten durch eigene austauschen kann, was zumindest eine Zeit lang gemacht wurde. 

Das entspricht aber nicht den Regeln.

ABER ich lasse am lokalen BIND named auch eine Liste von Spy & Add Domänen ins Leere laufen - trotzdem funktioniert DNSSEC für alle anderen Domänen!

Die at. Domäne sollte aber schon authentisch und unverfälscht sein. Detto auch die . (DNS Root)!

Liest hier denn kein DNS Admin mit?

Ja, die Anfragen werden nicht auf null gesetzt sondern auf einer andere Website umgeleitet

Könnte dieser Austausch der Antwort auf eine DNS-Anfrage die Ursache eines mir schon seit vielen Jahren bekannten Problems sein mit leidvollen Erfahrungen bei meiner ersten Konfrontation damit?

Ein A1-Smartphone ohne öffentliche IP-Adresse kann keine Verbindung zu einem A1-Anschluss über ddns aufbauen. Bekommt auch das A1-Handy eine öffentlich IP-Adresse, dann get es.

Kann es sein, dass das Handy vom A1-Nameserver statt der öffentlichen Ip-Adresse über ddns die entsprechende lokale Adresse im A1-Netz bekommt, was dann eben nicht funktionieren kann?

Warum missbraucht a1 den DNS dafür? Und welche Domänen sind davon betroffen?

Bei der Anti Spam Lösung mit BIND named wird ja auch umgeleitet und zwar nach 127.0.0.1

http://mirror1.malwaredomains.com/

http://mirror1.malwaredomains.com/files/spywaredomains.zones

Unter Strich gesehen ist das ein Grund nicht die von a1 default angebotenen DNS zu verwenden.

Mich hat nur gestört, dass bei der fb5730 und dem Original a1 Setting trotz anderer eingestellter und DNSSEC fähiger DNS sich die beiden per TR-069

195.3.96.67  ns1.aon.at. 
195.3.96.68     ns2.aon.at. 

vorgeschwindelt hatten und sich für at. zuständig erklärten!

So gehts nicht!

Das Problem für alle fb5730 Benutzer die keinen POTS Anschluss sondern IP Telefonie benutzen, sie kommen (meines Wissens) nicht um TR-069 herum und werden mit den nicht DNSSEC Nameserver „beglückt“ - egal was man als zusätzlichen DNS einstellt.

Ich hätte hier mal gerne mit einem der Nameserver Admin geplaudert  - damit meine ich nicht Jene die die Name-Server über eine WEB Oberfläche administrieren (Domain-Zonen einrichten), sondern jene die sie tatsächlich konfigurieren.

Über das dig Kommando selbst und das da zum Vorschein kommt (Abfragen gekürzt):

dig at. = ccTLD für Austria
dig . = root-servers.net.

dig (domain information groper) https://wiki.ubuntuusers.de/dig/

================

$ dig at. @195.3.96.67

; <<>> DiG 9.16.5 <<>> at. @195.3.96.67
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4919
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

$ dig . @195.3.96.67

; <<>> DiG 9.16.5 <<>> . @195.3.96.67
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32063
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

........

$ dig at. @195.3.96.68

; <<>> DiG 9.16.5 <<>> at. @195.3.96.68
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55979
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

$ dig . @195.3.96.68

; <<>> DiG 9.16.5 <<>> . @195.3.96.68
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59933
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

........

$ dig at. @213.33.98.136

; <<>> DiG 9.16.5 <<>> at. @213.33.98.136
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2642
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

$ dig . @213.33.98.136

; <<>> DiG 9.16.5 <<>> . @213.33.98.136
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1673
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

........

$ dig at. @213.33.99.70

; <<>> DiG 9.16.5 <<>> at. @213.33.99.70
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50441
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

$ dig . @213.33.99.70

; <<>> DiG 9.16.5 <<>> . @213.33.99.70
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10825
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

........

$ dig at. @80.120.17.70

; <<>> DiG 9.16.5 <<>> at. @80.120.17.70
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57928
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

$ dig . @80.120.17.70

; <<>> DiG 9.16.5 <<>> . @80.120.17.70
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1305
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

........
........

$ dig

; <<>> DiG 9.16.5 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6485
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 5d8808f3a2a5efad010000005f2d6f4a12945f4f29ba623c (good)
;; QUESTION SECTION:
;.                IN    NS

;; ANSWER SECTION:
.            508897    IN    NS    l.root-servers.net.
.            508897    IN    NS    d.root-servers.net.
.            508897    IN    NS    f.root-servers.net.
.            508897    IN    NS    a.root-servers.net.
.            508897    IN    NS    g.root-servers.net.
.            508897    IN    NS    h.root-servers.net.
.            508897    IN    NS    b.root-servers.net.
.            508897    IN    NS    j.root-servers.net.
.            508897    IN    NS    e.root-servers.net.
.            508897    IN    NS    i.root-servers.net.
.            508897    IN    NS    m.root-servers.net.
.            508897    IN    NS    c.root-servers.net.
.            508897    IN    NS    k.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.    508897    IN    A    198.41.0.4
b.root-servers.net.    508897    IN    A    199.9.14.201
c.root-servers.net.    508897    IN    A    192.33.4.12
tbc.
........

empty

Warum Beantwortet?

Ich sehe keine befriedigende Antwort seitens der a1 Name-Server Admins.

sehe leider nicht wer es markiert hat, aber ist repariert.

Ich hätte da eine Idee.

Ich rate jedem sich einen Server/Raspi mit Pihole und Unbound zu gönnen.

Ich habe  ebenso eine Raspberry mit PiHole installiert und im VLAN für die VMs Pfsense mit einem DNS Resolver

Da ich meist nur einen Mac aktiv betreibe, läuft der DNS auf diesem.

Bleibt nur das Handy, wenn ich per WLAN ins Internet gehe.

Bei meiner DNSSEC Anfrage geht es mir um Grundsätzliche Internet Sicherheit.