Talk:DNS Infrastructure

Jump to: navigation, search

Old discussion moved to Talk:DNS Infrastructure/Archive

Example DNS illustration[edit]

I made a graphic illustrating the DNS naming scheme. I want to update the DNS Infrastructure page and use this as an example.

Example for the DNS naming

Any suggestions? Any errors? Zeptomoon 12:41, 4 October 2013 (EEST)

I might integrate also the PTR records into the graphic. Zeptomoon 19:23, 4 October 2013 (EEST)
I like this kind of graphics but I think here they don't play so nice. There is ratio where if you have few info it is nice to have realistic illustration, like a home with a router and an antenna. But when you need to show a lot of information, a structured schema is easier for reading and understanding. Maybe I prefered to have a smaller example, or a more structured illustration. But again it is a matter of taste... Sque 01:26, 6 October 2013 (EEST)
Anyhow, if this schema is correct, then we can put it at the bottom as an example. If someone finds it confusing, he can stick to the text. Maybe we can make smaller graphics but I don't have the time now. If nobody thinks it makes the page worse, then I would suggest to put it at the bottom. Zeptomoon (talk) 19:35, 18 June 2014 (EEST)

Scope reachability - what server?[edit]

Should we define what kind of "server" is meant on the main page: [quote:] "Τουλάχιστον ένας server της ζώνης πρέπει να βρίσκετε στο εύρος διευθύνσεων του HWMN." I believe a DNS server is meant here, right? We had also agreed, that serving the domain <nodename>.her.wn can be delegated to a common server. This should be mentionad here as well, I think.

It is more a rhetorical statement, that at least one authoritative nameserver of your zone(that is the server) should be accesible by HWMN network. It was put there as a reminder like you have to eat when you are hungry. Maybe it is should not be there at all. Sque 01:29, 6 October 2013 (EEST)

Official Recursor Nameservers[edit]

As you noticed, I tried to distinguish the functionality of serving the her.wn zone, and providing nameservers for queries. The former will hold the zone and all authoritative nameservers of subzones, while the latter is the server that will be used by the network for querying. The later will also know how to reach zones of other networks that we may need in the future. So I am thinking to provide two standard dns servers a primary and a secondary. The primary will be the anycast so that by default your query will be redirected to the closer live server and the secondary will be a standard in the system. So these two IPs are:

  • a.root-servers.wn - fdd4:f629:b000:0001::000a - (unicast)
  • b.root-servers.wn - fdd4:f629:b000:0001::000b - (anycast)

Do you mind if I change the order and making .10 anycast and .11 unicast so that you easily remember to put as dns server and ? Sque 01:34, 6 October 2013 (EEST)

I think there is no problem to change the IPs of the primary (anycast) and the secondary (unicast) DNS-root-server at this stage, because not many people have used them yet, I believe. So it's now or never.. ;) If I understand correctly, then both the primary (anycast) and secondary (unicast) will be for querying only. The authoritative server (which has the original infos for her.wn) will have another IP and the DNS root-servers just knows where to ask, correct? So the root-servers will ask our authoritative server for the info on her.wn and for the info on ath.wn (AWMN) it will ask another authoritative server. Zeptomoon 12:33, 6 October 2013 (EEST)
Partially yes you are right. These server are not authoritative servers of the her.wn zone but they know where to search for others information. So it looks like root servers but they are not completely. A root server should be accepted by its subzones, like awmn conforms to put its nameservers records in our root server. Also root servers don't have to answer in recursive queries, thus they cannot be used by your client for querying. That's why these are called recursor servers. We do not have any root servers inside the network. But with these schema we can introduce root servers in the future with any user change, we will only update the recursor servers. Sque 18:37, 6 October 2013 (EEST)

Subzones schema[edit]

Till now it was proposed to automatically assign <node>.her.wn where user MUST add his network equipment RR and whetever else he/she wants. For public services we said to use <service>.net.her.wn. Well this looks too much opposite for me! :P And from experience I gather viewing AWMN nodes I found the following problems:

  • DNS are used primarly by users, so <services>.her.wn looks more natural
  • A user may have a silly name on node and he/she has no reason to use the same name to advertise a name. Examples of this nodes are sque1, sque-2, mountain.
  • A user may have multiple nodes with numbered names but wants an unumbered zone, like sque1, sque2 being the node names, but wants sque.her.wn for services.
  • A user may not need at all to serve services.

Because of these problems I propose this:

  • All network equipment should be put under <nodename>.net.her.wn. It IS information about the NETwork structure and it IS relevant only to NODES and not owners. The rules under this zone, will be the one that we have already agreed, nothing will change here.
  • All the users may request a <name>.her.wn and the hostmaster will approve or not. The rules for these names MUST be decided by hostmaster team.

Sque 22:00, 21 October 2013 (EEST)

Mostly I agree with the things above. Here are some thoughts I have:
  • I think if we want a separate subdomain-space for node equipment it would be more natural to use <nodename>.node.her.wn rather than .net.her.wn as subdomain. The entire FQDNs will be longer, but they will be used for debugging and I guess we can handle that. (gw-sque.zeptomoon.node.her.wn.)
  • The question is: How many sub-domains do we give per persion? One per person (case 1) or as many as the user wants to set up services (case 2)?
  1. (Pro case 1) In case 2 if HWMN grows then there might be many people wanting the same subdomain (e.g. files.her.wn). So it will be a first-come-first-served kind of thing as with the .com domains. The good ones are all taken by now even if they are not used by anyone. (e.g. [1]) In case 1 the exhausting of the name-space will be very slow or will basically not happen...
  2. (Pro case 2) Domain names for services will be a little bit longer in case 1, e.g. myfiles.zeptomoon.her.wn instead of zeptofiles.her.wn in case 2.
  3. (Pro case 1) It will be obvious, who is responsible for the (public) service in case 1, i.e. the person with the respective nickname. In case 2 it could only be found somewhere in some database or wiki page or so.
My conclusion:
  • Every user may apply for only one subdomain like <username>.her.wn, e.g. zeptomoon.her.wn - So you better choose it wisely! ;)
  • Services run by individuals will be on a sub-subdomain under their subdomain like <service>.<username>.her.wn or under their subdomain like <protocol>://<username>.her.wn, e.g. webdav://files.zeptomoon.her.wn or under the subdomain: e.g. ftp://zeptomoon.her.wn
  • Services run collectively and democratically get a subdomain like <service>.her.wn, e.g. http://wind.her.wn (we must compile a list of reserved names for this!!)
  • Every node will also get a subdomain according to <nodename>.her.wn - that may (if wanted so) be the same as the <username>. Node equipment will be registered under a the subdomain of the node like gw-<peer>.<nodename>.her.wn, e.g. gw-captjoe.rogdia.her.wn. If a user has multiple nodes, she will get multiple subdomains for the multiple nodes, one for each node, e.g. maxoffice.her.wn and maxhome.her.wn and the equipment will be gw-rogdia.maxhome.her.wn and gw-rogdia.maxoffice.her.wn. A user may (choose to) use the same <username> as for his <nodename> so that they are the same and the situation would be as it usually is right now: Both exists gw-sque.zeptomoon.her.wn and files.zeptomoon.her.wn. This has the small disadvantage that nodenames and usernames are in the same name-space, but I think that's not a problem.
Zeptomoon 22:53, 24 October 2013 (EEST)
Last night, among others, we talked with Sque for the suggested change to move all node network-devices into <node>.net.her.wn and i agree with the proposal.
Although it makes names little longer, it has a very nice technical merit:
We can choose to store all net-device names in a single zone, net.her.wn, managed by replicated DNS-slaves in various nodes so as to provide names for the whole network topology even on link failures.
Note that it is nice to know IPs even for unreachable devices because you can use different tricks to access them (tunnel-hoping, NATed VPN, calling-a-friend). | Moved here from an email of User:ankostis
@ankostis: Just to clarify: (A) What's the advantage of having the nodes in <node>.net.her.wn instead of having them in <node>.her.wn? (B) What means "managed by replicated DNS-slaves"? Can you explain that a bit? Zeptomoon 11:57, 25 October 2013 (EEST)
I don't care if it is nodes.her.wn or net.her.wn so much. But I think "net" is more accurate name as there can go anything related with network infrasture, may be ips that we gave through vpns to other networks or staff like that, which may not have a node owner. This zone can be in the future prohibit delegation to other nameservers, and a central management interface (windv2) may generate and manage the names of interfaces etc etc. If this zone is not delegated then every nameserver (master or slave) will carry ALL the information for forward mapping. This can help if we setup multiple slaves in the network and we have a network split.
However I am not sure how the reverse mapping will play for the net.her.wn. I mean we cannot guarantee the same, or maybe we can... I have to sort this out. But again I am still on using the <find-a-name>.her.wn for all network equipment.
As for services, the first come first serve is a problem and I am willing to find another proposal. It will be innovative and will promote a flat peering network. But again the named services like service.user.her.wn will promote fame and ownership rather than services. I believe we should not promote ppl to put their names on services, but they are free to do it if they want. No good ideas at the moment. Sque 23:17, 25 October 2013 (EEST)