diff --git a/.gitbook/assets/owndnsflow (1).png b/.gitbook/assets/owndnsflow (1).png
new file mode 100644
index 0000000..7470ce4
Binary files /dev/null and b/.gitbook/assets/owndnsflow (1).png differ
diff --git a/.gitbook/assets/owndnsflow (2).png b/.gitbook/assets/owndnsflow (2).png
new file mode 100644
index 0000000..7470ce4
Binary files /dev/null and b/.gitbook/assets/owndnsflow (2).png differ
diff --git a/.gitbook/assets/owndnsflow.png b/.gitbook/assets/owndnsflow.png
index 4e68c15..7470ce4 100644
Binary files a/.gitbook/assets/owndnsflow.png and b/.gitbook/assets/owndnsflow.png differ
diff --git a/SUMMARY.md b/SUMMARY.md
index c1b7e38..d36509b 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -19,6 +19,7 @@
     * [IP Access](index/configurations/ip-access.md)
     * [Domains](index/configurations/domains/README.md)
       * [Own DNS Server](index/configurations/domains/own-dns-server.md)
+      * [Discussions Subdomains](index/configurations/domains/discussions-subdomains.md)
     * [Routes](index/configurations/routes.md)
   * [Developer](index/developer/README.md)
     * [Ideas, requests and bugs](index/developer/ideas-requests-and-bugs.md)
diff --git a/index/configurations/domains/discussions-subdomains.md b/index/configurations/domains/discussions-subdomains.md
new file mode 100644
index 0000000..fee2505
--- /dev/null
+++ b/index/configurations/domains/discussions-subdomains.md
@@ -0,0 +1,24 @@
+# Discussions Subdomains
+
+I read in an article that Google finds it better if a page is not part of a subdomain. Which can contribute to a better ranking. This cannot now be substantiated with facts as to whether this is really the case. But I found the discussion about it interesting.
+
+Let's think this through. A big company really shouldn't offer a site running under a subdomain that is part of a third party domain. In any case, in my opinion, this state of affairs paints the wrong picture. The first question that comes up would be, doesn't the company have enough money for a main domain?
+
+This is an attitude that should be considered correct. However, this is only my opinion.
+
+But now comes the big thing, I think subdomains are important and necessary. If a company offers internal services/portal. Which are not available to the public, then that's the way to go.
+
+I could now create a subdomain under a Nextcloud is running. First of all, it would be an unknown service for third parties (bad people, I mean hackers). The domain would be unknown, since the service going through the reverse proxy cannot be resolved without the subdomain name.
+
+## Benefits of a Subdomain
+
+* So it's another hurdle and can be seen as a security feature.
+* Subdomains are also easy to manage.
+*   Recognition is easier for users by grouping the main domain.
+
+
+
+## Conclusion
+
+It's one thing when we present something important, something for the public. I would totally understand Google along the way. But we can't do without it in the future either.
+
diff --git a/index/configurations/domains/own-dns-server.md b/index/configurations/domains/own-dns-server.md
index 333a77e..a4fb5d2 100644
--- a/index/configurations/domains/own-dns-server.md
+++ b/index/configurations/domains/own-dns-server.md
@@ -20,7 +20,7 @@ Example if you own the <mark style="background-color:purple;">example.com</mark>
 
 <figure><img src="../../../.gitbook/assets/owndnsflow.png" alt=""><figcaption></figcaption></figure>
 
-A domain <mark style="background-color:purple;">example.com</mark> gets an <mark style="background-color:red;">NS</mark> (name server) record from the provider. These records can only point to domain names. In addition, we create a sub domain <mark style="background-color:purple;">dyn.example.com</mark> whose <mark style="background-color:red;">A</mark> record gets the IP from our DynDNS client/or fixed IP. DNS servers are backwards resolving. That means if a <mark style="background-color:purple;">sub1.example.com</mark> is called but not found, <mark style="background-color:purple;">example.com</mark> is called. However, this does not return an <mark style="background-color:red;">A</mark> record, only the <mark style="background-color:red;">NS</mark> record. Now the client knows he must request a DNS server under the domain <mark style="background-color:purple;">dyn.example.com</mark>. With its IP resolution it gets the IP from the FlyingFish DNS server. Then the client asks this DNS server again and gets <mark style="background-color:purple;">sub1.example.com</mark> an <mark style="background-color:red;">A</mark> record.
+A domain <mark style="background-color:purple;">example.com</mark> gets an <mark style="background-color:red;">NS</mark> (name server) record from the provider. These records can only point to domain names. In addition, we create a subdomain <mark style="background-color:purple;">dyn.example.com</mark> who's <mark style="background-color:red;">A</mark> record gets the IP from our DynDNS client/or fixed IP. DNS servers are backwards resolving. That means if a <mark style="background-color:purple;">sub1.example.com</mark> is called but not found, <mark style="background-color:purple;">example.com</mark> is called. However, this does not return an <mark style="background-color:red;">A</mark> record, only the <mark style="background-color:red;">NS</mark> record. Now the client knows he must request a DNS server under the domain <mark style="background-color:purple;">dyn.example.com</mark>. With its IP resolution it gets the IP from the FlyingFish DNS server. Then the client asks this DNS server again and gets <mark style="background-color:purple;">sub1.example.com</mark> an <mark style="background-color:red;">A</mark> record.
 
 In the diagram you can see how the flow works: