How familiar are you with running a DNS server, or are you wanting this DNS configuration on public companies? I saw your other post regarding various DNS companies, but not necessarily DNS software.
>>Now, I feel the configuration is little confusing for me.
You're running a non-standard DNS configuration, so it will be a little confusing.
Whether the DDNS updates will happen without any problem?
The DNS servers will update fine, don't worry.
>>How this secondary NS will contact the primary NS for the zone transfer request?
They will use zone-file transfers. When you update the DNS zone on the master then the slave servers will get notified and download the new zone.
>>Is this is the only way (legal way) to hide the primary from the external world or this is one of the method
This is really the only way, and it makes sense.
Let me elaborate on something.
1. You do not register the SOA with APNIC. You register your DNS servers, ie: ns1.domain.com and ns2.domain.com have authority over "domain.com". And oh by the way ns1.domain.com is 1.2.3.4 and ns2.domain.com is 4.3.2.1 (these are called glues)
I even run mis-matched glues on my DNS servers. It was an experiment that I never changed. Look at this:
sk@sk:~$ dig ns1.warche.st @SUNIC.SUNET.SE
; <<>> DiG 9.4.0 <<>> ns1.warche.st @SUNIC.SUNET.SE
; (2 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22543
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;ns1.warche.st. IN A
;; AUTHORITY SECTION:
warche.st. 86400 IN NS ns2.warche.st.
warche.st. 86400 IN NS ns1.warche.st.
These are the glues. The non-authorative DNS server is giving IP addresses for the destination domain. These "glue" DNS and make the protocol work:
;; ADDITIONAL SECTION:
ns1.warche.st. 86400 IN A 208.42.233.178
ns2.warche.st. 86400 IN A 72.16.178.117
sk@sk:~$ dig ns1.warche.st @ns2.warche.st
; <<>> DiG 9.4.0 <<>> ns1.warche.st @ns2.warche.st
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6978
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
;; QUESTION SECTION:
;ns1.warche.st. IN A
;; ANSWER SECTION:
ns1.warche.st. 3600 IN A 208.42.228.219
;; AUTHORITY SECTION:
warche.st. 3600 IN NS ns2.warche.st.
warche.st. 3600 IN NS ns1.warche.st.
warche.st. 3600 IN NS ns3.warche.st.
;; ADDITIONAL SECTION:
ns2.warche.st. 3600 IN A 72.16.178.119
ns3.warche.st. 3600 IN A 208.42.228.219
Notice in the first DNS lookup ns2. was .119, and in the second it was .117? You can even run mis-matched glues with DNS and it works perfectly OK. DNS is a very trusting protocol
>>
Next -- The SOA record is really used by the DNS daemon to initialize zone transfers but not really use for resolving. If I wanted to force my domains to update:
$TTL 1H; Default TTL (bind 8 needs this, bind 9 ignores it)
@ IN SOA ns1.warche.st. root.warche.st. (
20041170; serial
30M ; Refresh
300 ; Retry
4W ; Expire
1H ) ; Min TTL
I would bump the red serial# in the above post, and reload the zone files:
sk:/etc/bind/zones# rndc reload
server reload successful
This triggered my DNS servers to begin updating:
Sep 18 00:46:11 sk named[18355]: general: info: zone warche.st/IN: loaded serial 20041170
Sep 18 00:46:11 sk named[18355]: notify: info: zone warche.st/IN: sending notifies (serial 20041170)
Sep 18 00:46:11 sk named[18355]: xfer-out: info: client 72.16.178.119#45199: transfer of 'warche.st/IN': AXFR-style IXFR started
Sep 18 00:46:11 sk named[18355]: xfer-out: info: client 72.16.178.119#45199: transfer of 'warche.st/IN': AXFR-style IXFR ended
Because on the master server I had a list of the slave servers to update. You can tell the master server to "push out updates" when the serial# is changed OR you can wait for the slave to periodically poll the master. I chose pushing them out, and you would configure it like:
sk:/etc/bind# grep -i warche\.st named.conf.local -A5
zone "warche.st" {
type master;
file "/etc/bind/zones/warche.st";
allow-transfer { 72.16.178.119; 72.16.178.117; localhost; 208.42.228.219; };
allow-query { any; };
also-notify { 72.16.178.119; 208.42.228.219; };
check-names ignore;
};
Marked Solved 
Offline 
