Generation / Automation / Scripting of DNS out of WiND

[jammin84]

CTWUG using a Powerdns / bind implementation.
WAFN using a bind generation script and then push to DNS server implementation.

I'll upload the WAFN version to /tools/dns-zones-bind-updater/

The WAFN version wont do anything unless its installed as a CRON and therefore can be "admin" enabled.

@spinza if you can do similar, where it needs to be "enabled" so either is optional, it would be appreciated.

[jammin84]

from @spinza Comments in PR #1

Bigger discussion again
I think this is again a bigger discussion. I think your dns zone setup would be quite complex for us.
We have many many nodes for example.

To me the best possible model is ip_addresses.hostname + '.' +nodes.name_ns '.' + dns_zones.name.

But there would be a join between ip_addresses and dns_zones. I.e. I want to set the ip address for this hostname.name_ns for this zone.

You'd lose duplicate names to some extent, but doesn't seem to be used that often. Note you could also just edit the name_ns field to the "easy version" of a node name.

Then we could based on your zone data add zone for wafn and zone for say wafn.co.au or so to make your dns available on the web.

Also we "calculate" reverse data based on ip_addresses/nodes data. Our nodes are too many so we can't give each node a /24 to have a separate reverse zone. We share a common address space with other wireless networks in South Africa (allowing peering). We "only" get 172.18 and 172.26.

[jammin84]

WAFN layout:
Only our AP nodes or special cases are allocated /24's not every node. The AP owner delegates out smaller ip to clients. The AP owner also controls the hostname / reverse for his /24 and subdomains of his domain.

How is this delegation controlled within CTWUG?
Side Note: If you're running out of /16 then why not delegate further /16's or larger /11?

Also my understanding of nodes.name_ns is that it is shown as "nameserver prefix" within the node info page. So how has the nameserver name got anything to do with a subdomain?

This way (going through Network > DNS zones section) they are requesting the subdomain of the TLD, making:

• an admin approval process for domain names
• removing typo errors (as you seem to come across often).
• zero duplicates

I dont see anything stopping the generation of a record for both your public and private NS.
test.node1SubDomain1.privateTld
test.node1SubDomain2.privateTld
can also be
test.node1SubDomain1.publicTld
test.node1SubDomain2.publicTld

[spinza]

Yeah actually I don't understand what designed process was with wind. It
does seem our process has become bastardised.

Guys edit a wiki we have and allocate ip ranges there and that's about it.
I'd prefer if it's in the database and easy to track and automate.

I need to understand what the original idea of how it is supposed to work.

And then how we will use it going fw.

On Wed, 16 Dec 2015, 05:59 jammin84 notifications@github.com wrote:

WAFN layout:
Only our AP nodes or special cases are allocated /24's not every node. The
AP owner delegates out smaller ip to clients. The AP owner also controls
the hostname / reverse for his /24 and subdomains of his domain.

How is this delegation controlled within CTWUG?
Side Note: If you're running out of /16 then why not delegate further
/16's or larger /11?

Also my understanding of nodes.name_ns is that it is shown as "nameserver
prefix" within the node info page. So how has the nameserver name got
anything to do with a subdomain?

This way (going through Network > DNS zones section) they are requesting
the subdomain of the TLD, making:

• an admin approval process for domain names
• removing typo errors (as you seem to come across often).
• zero duplicates

I dont see anything stopping the generation of a record for both your
public and private NS.
test.node1SubDomain1.privateTld
test.node1SubDomain2.privateTld
can also be
test.node1SubDomain1.publicTld
test.node1SubDomain2.publicTld

—
Reply to this email directly or view it on GitHub
#9 (comment).

[spinza]

BTW we have our DNS running directly off wind data for a couple of weeks now.

Addded views on the WIND data.
This is combined with some manual entries into a combined view.
SOA serial gets calculated off modification times (we have a auto updating modified column on nodes, ip_addreses, ip_cname). SOA serial = max of modification timestmaps on (node mod, ip_address, ip cname, manual entries).
PowerDNS reads this combined view and serves DNS based off it.

This PowerDNS is fairly slow ,given the size of our zones (10k records). So we have a bind on the same machine syncing to powerdns (operating on non-standard port). Other dns "slaves" and clients can lookup with this server. The other dns slaves are masters too in the sense that they sync to each other too. So as soon as one has a new serial they notify each other and update each other till they all have it. Also some update via the internet where available at the particular slave. So lots of resilience if we have networks that get isolated (due to power cuts or similar).

I think you are running multiple DNS servers that have different zones right? We run with all dns have the whole zone. I think that might be a difference between our setups.

Only small bug is that deletes don't update the serial. In fact it could theoretically decrease it. Could make a trigger for deletes to update some record, but given changes occur so frequently the serial will be updated soon enough.

[jammin84]

your powerDNS method utilising views is a good idea.

I dont understand if your other DNS servers are utilising Anycast or not?? How do network segments know which DNS to use, as i imagine there would be lots in your scenario?

For us, every Anycast server thinks its the master and runs it own hosted copy of the latest zone file (pushed out by the tool only when a change occurs in WiND).

Anycast allows a network wide single IP for DNS. all clients queries will just use the closest (by hops) available server. Which in itself gives failover protection if there is a network split or if a DNS (bgp session) server goes down the queries go to the next available one automatically.

[jammin84]

re: running whole zones.

Our setup runs as TLD. ie *.wafn
For every users domain/s in WiND they have the option of hosting it on the Anycast servers or hosting it on their own DNS server.

This is via the NS selection found in
Node Edit > Network > DNS Zones > Responsible Nameservers (NS)*

[spinza]

Yes all our servers are authoritive for everything. They are also anycast
servers on 172.18.1.1.
PDNS reads the database.
Bind running on same server uses AXFR to transfer from PDNS.
All the other AXFR from that master-master (and each other).

We don't have people hosting only their own dns. If they want to, they can
volunteer a server, typically a spare Pi or similar and I link it in to
sync into this framework and it becomes another anycast server. But then
it's auth for the whole ctwug.za.net plus reverse zones plus the internet
view. Not just somepart.ctwug.za.net.

On Wed, 27 Jan 2016 at 10:26 jammin84 notifications@github.com wrote:

re: running whole zones.

Our setup runs as TLD. ie *.wafn
For every users domain/s in WiND they have the option of hosting it on the
Anycast servers or hosting it on their own DNS server.

This is via the NS selection found in
Node Edit > Network > DNS Zones > Responsible Nameservers (NS)*

—
Reply to this email directly or view it on GitHub
#9 (comment).

[spinza]

I can share our configs with you. Can you access gitlab.ctwug.za.net?

On Wed, 27 Jan 2016 at 10:39 Louis Rossouw lrossouw@gmail.com wrote:

Yes all our servers are authoritive for everything. They are also anycast
servers on 172.18.1.1.
PDNS reads the database.
Bind running on same server uses AXFR to transfer from PDNS.
All the other AXFR from that master-master (and each other).

We don't have people hosting only their own dns. If they want to, they
can volunteer a server, typically a spare Pi or similar and I link it in to
sync into this framework and it becomes another anycast server. But then
it's auth for the whole ctwug.za.net plus reverse zones plus the internet
view. Not just somepart.ctwug.za.net.

On Wed, 27 Jan 2016 at 10:26 jammin84 notifications@github.com wrote:

re: running whole zones.

Our setup runs as TLD. ie *.wafn
For every users domain/s in WiND they have the option of hosting it on
the Anycast servers or hosting it on their own DNS server.

This is via the NS selection found in
Node Edit > Network > DNS Zones > Responsible Nameservers (NS)*

—
Reply to this email directly or view it on GitHub
#9 (comment).

[jammin84]

@spinza interested in sharing that config with this project as an optional method?

[jammin84]

@spinza I've created a login in gitlab.ctwug.za.net. I think you need to share that project with me so I can see it.

[spinza]

I have the bind configs. Look at bind_configs project (it's public). One of those syncs to pdns and then shares with the rest of the slaves. Our slaves are all masters and sync to each other. They all carry the complete records on wind.

The powerdns bit is not yet in a on gitlab. I will share that with you. I'm travelling tonight so will get to it later this week only.