Not cool. TIL: when you have a delegated zone to #azure, in bind for example:

sub.example.com.    IN  NS  ns1-05.azure-dns.com.
sub.example.com.    IN  NS  ns2-05.azure-dns.net.
sub.example.com.    IN  NS  ns3-05.azure-dns.org.
sub.example.com.    IN  NS  ns4-05.azure-dns.info.

and in azure someone decommissioned the zone (but the delegation remains), then every dumbass can hijack sub.example.com. You don't have to prove that you're entitled to use sub.example.com.
That opens a wide door to for example phishing: login.sub.example.com is a good starting point.

Well done, Microsoft!

in reply to Mark Nowiasz

Bei mir war das so: Die 4ma betriebt einen eigenen autoritativen Nameserver für example.com. Eine Fachabteilung möchte die Zone sub.example.com betreiben, bei Azur. Also ist sub.example.com delegiert.
Die Fachabteilung braucht sub.example.com nicht mehr und löscht sie bei Azure, ohne die 4men-IT zu informieren. Also bleiben die Delegetionseinträge in example.com bestehen, und jedermann kann sich bei Azure sub.example.com ohne weiteres schießen.
in reply to Rainer "friendica" Sokoll

Ich verstehe das so: Subdomain bei Azure,ndie wird dann durch den Owner woandershin umgezogen ohne dabei auch die Zone bei Azure zu löschen.

Somit zeigt DNS noch dorthin, Einträge bestehen weiterhin und MS erzwingt kein proof of ownership wenn dein Azure Nachbar-Tenant seine eigenen Einträge mit zuvor durch dich (den eigentlichen Owner) verwalteten Subdomains, oder neuen, ergänzt. Und er kann auch Einträge hinzufügen die es zuvor nicht gab.

total-unbedenklich.login.neu.mckinsey.digital zeigt somit etwa eine Thai online gambling Seite.

in reply to Carsten Raddatz

@Carsten Raddatz Auch bei dem Szenario sind die NS-Einträge inkorrekt und hätten bei dem Umzug/Löschen der Subdomain mitangepasst werrden müssen, das Äquivalent von dangling pointern in C.

Und ich glaube das ist kein spezielles Problem von Azure/Microsoft, ich fürchte so was würde auch bei den meisten Hostern klappen die NS-Einträge anbieten (AWS, Hetzner, GoDaddy...)

in reply to Rainer "friendica" Sokoll

@Carsten Raddatz Auch bei dem Szenario sind die NS-Einträge inkorrekt und hätten bei dem Umzug/Löschen der Subdomain mitangepasst werrden müssen, das Äquivalent von dangling pointern in C.

Und ich glaube das ist kein spezielles Problem von Azure/Microsoft, ich fürchte so was würde auch bei den meisten Hostern klappen die NS-Einträge anbieten (AWS, Hetzner, GoDaddy...)

in reply to Alexander Goeres 𒀯

Das weiß ich in der Tat nicht. Wir wurden angeschrieben.
Jetzt bauen wir uns selber ein Monitoring: Die Kollegen der Fachabteilung lesen aus, welche Subdomains *.example.com sie verwenden. Dann haben sie ein deploy token für das Gitlab-Repository, in dem die Zone example.com liegt, so daß sie sehen können, welche Zonen zu Azure delegiert sind.
Am Ende sind es zwei Dinge, die problematisch sind

  • es gibt/gab bei uns keinen Prozeß für das Löschen von Subdomains in Azure
  • Microsoft verlangt keinen Nachweis darüber, daß man berechtigt ist, sub.example.com zu verwenden
in reply to Rainer "friendica" Sokoll

@Rainer "friendica" Sokoll Letzteres ist aber vollkommen normal, wie soll das auch gehen, besonders bei verschachtelten Einträgen? Ich habe die Domain abi90.org (wieder) und 2000 hat nich jemand abgeschrieben der auch 1990 Abitur hatte und mich gefragt ob ich ihm eine Subdomain (ich weiß nicht mehr welche) für seine damalige Schule geben könne. Kein Problem, ich habe daher auch NS-Einträge erstellt und auf seinen Nameserver zeigen lassen. Da gab es auch keinen irgendwie gearteten Prozess dass ich als Inhaber der Domain zustimmen muss dass jemand anderes Zoneneinträge erstellt
in reply to Rainer "friendica" Sokoll

@Rainer "friendica" Sokoll Das wäre dann aber ein Prozess außerhalb der RfC und nichts verbindliches. Der bind hat einen solchen Prozess überhaupt nicht, ich kann ja da jede Zone die ich lustig bin anlegen ohne dass er es ablehnt. Eine solches Vorgehen wäre ein Einkonstrukt, analog zu T-Online die ein Impressum per http(s) für Mailserver verlangen.
in reply to Rainer "friendica" Sokoll

@Rainer "friendica" Sokoll Aber warum sollte man es? Mit den NS-Einträgen sagt man ja dass der/die Nameserver für die Subdomains zuständig sind und man nichts mehr damit am Hut hat, genauso so funktioniert doch DNS. Wenn man selbst auf die Einträge in der deligierten Zone angewiesen ist ist es nicht sonderlich clever diese an Nameserver zu deligieren den man selbst nicht kontrolliert.