Domains Management

To manage a domain simply click on the domain name in the zone's list. So in this section you control all DNS records of a selected zone. At top you have a link to get Back to the zones list and a Domain link that guide us to zone definitions. At body you have a list of all possible DNS records to configure, each one with a Insert button. Now all records will be presented supposing that we are managing the forward zone of domain.com:

Machines: This is called the A record (address record). It's used to map hostnames to IP's. E.g.:
```
       pc01         192.168.69.96
       ipbrick      192.168.69.1
       slave01      192.168.69.2
```
So pc01.domain.com will resolve to 192.168.69.199. In order to get the base domain domain.com associated to some IP you need to insert a machine record like that:
```
       domain.com.  192.168.69.1
```
Aliases: This is called the CNAME record (canonical name record). It's an alternative name for some existing machine record (this option is only available for a forward name resolution zone). E.g.:
```
       webmail      ipbrick
       im           ipbrick
       contacts     ipbrick
       voip         ipbrick
       mailsrv2     slave01
```
Name Servers: It's the NS record (name server record). Here we manage the list of DNS servers for the zone. If a zone has master and slave servers, the master should have that information defined here. E.g.:
```
       domain.com   ipbrick.domain.com
       domain.com   slave01.domain.com
```
Let's suppose that the same IPBrick's are serving other zone called easylinux.com. So the configuration would be:
```
       easylinux.com   ipbrick.domain.com
       easylinux.com   slave01.domain.com
```
Mail Servers: This is called the MX record (mail exchange record) and it's a crucial record. We can say what server or servers are the mail servers for the present domain. You can have several registrations each with different internal positive values. The values indicate which registration to use first. The registration with the lowest value is always the first one to be used. The names to be introduced here must always be the e-mail server FQDN (this option is only available for a forward name resolution zone). For example:
```
       10 ipbrick.domain.com
       20 mailsrv2.domain.com
```
VoIP Servers: It's one SRV record (service locator) for new protocols, including VoIP (SIP). The value to be introduced here is the FQDN of the VoIP server (this option is only available for a forward name resolution zone). For example:
```
       voip.domain.com
```
Instant Message Server: It's also a SRV record for Jabber protocol and by default the address is im.domain.com. The alias im exist by default;

The SRV records for VoIP and IM are very easy to configure if IPBrick is the DNS server, because we only need to type the FQDN of the server. If the private/public zones are managed by different DNS servers and we want to use that services in IPBrick you need to really specify all the SRV records that are being used, and pointing them to IPBrick.

Example for VoIP:
```
_sips._tcp.domain.com.     IN     SRV   1   0   5061   voip.domain.com.
_sip._tcp.domain.com.      IN     SRV   1   0   5060   voip.domain.com.
_sip._udp.domain.com.      IN     SRV   1   0   5060   voip.domain.com.
```
Example for IM:
```
_jabber._tcp.domain.com. 86400 IN SRV 5 0 5269 voip.domain.com.
_xmpp-server._tcp.domain.com. 86400 IN SRV 5 0 5269 voip.domain.com.
_xmpp-client._tcp.domain.com. 86400 IN SRV 5 0 5222 voip.domain.com.
```
Valid records for sending mail (SPF): In this field we can use the SPF in order to specify what records are valid for mail sending. So this configuration here will be the IPBrick's mail server answer to the external mail servers that are using the SPF protection. The configuration can be done at Basic Options (Figure 7.36):
- Registered mail servers: The domain MX records can be valid (pass), invalid (fail) or undefined (not present at TXT record)
- Registered machines: The domain A records can be valid, invalid or undefined;
- Domains: Other domains that are valid (corresponding to the senders address);
- Networks: Valid sender networks;
All the rest is invalidated (mechanism -all).

Figure 7.36: Support Services - DNS - SPF basic options

After the configuration, from the Basic Options, going to Advanced Options will present the TXT record. There it's possible to edit directly the TXT record, so other specific SPF mechanisms and qualifiers can be used (Figure 7.37).

Figure 7.37: Support Services - DNS - SPF advanced options

TXT record example:
```
    domain.com.    IN     TXT    "v=spf1 a mx -all"
```
In that configuration, if someone in Internet asks for the mail authenticity, only the mail sended by the domain MX and A records will be valid. The rest will be invalidated.

**Figure 7.38:** Support Services - DNS - Zone Management 1/2

**Figure 7.39:** Support Services - DNS - Zone Management 2/2

**Figure 7.40:** Support Services - DNS - Reverse zone

Mass Operations for machine record

The Export feature will export all the data to a .csv file. The Mass operations option permit an import of a .csv file. You can edit a .csv file in a spreadsheet application, choosing the ; to split the columns. When doing a export we can see all the fields present:

action: Options available:
- I: To insert a machine record in DNS;
- U: To update a machine record in DNS;
- D: To delete a machine record in DNS;
idzone: Zone identifier;
zonename: Zone name;
iddnsina: A record identifier;
name: A record name;
ip: A record IP;
addtorev: Option to add the record or not to reverse DNS zone. Value 1 yes, 0 no.

Example of a .cvs file content for mass operations import option:

      action;idzone;zonename;iddnsina;name;ip;addtorev
      N;1;domain.com;1;ipbrick;172.29.1.154;1
      N;1;domain.com;2;pc2;172.29.1.32;1
      I;1;domain.com;3;pc3;172.29.1.33;1
      I;1;domain.com;4;pc4;172.29.1.34;1

Note: The private reverse zones can exist at DNS LAN servers, but the public reverse zones are maintained at .arpa^7.9. The configuration of that public zones are configured at ISP DNS servers, so all the costumers public IP's can be mapped to the respective FQDN. It's called a PTR record and actually they became very important, because the number of mail servers that make that reverse zone verification is increasing. Example: Mapping the IP 195.23.45.33 with name ipbrick.companyx.com. The ISP will insert a record like that:

   33.45.23.195.in-addr.arpa.     IN    PTR   195.23.45.33

Footnotes

... .arpa^7.9: Internet Address and Routing Parameter Area

IPBRICK