Hi Friends,
I am in the middle of creating my design doc for DNS. My aim is to hide my primary NS from external world. And I am planning to use only secondary servers for query handling.

I have created XYZ.com zone and added two NS RRs which are secondary servers. I am forced to give my primary NS details when creating SOA record. Whether the primary NS RR, which we have given in the SOA RR will be safe for the internet (threats) or not?

One more added question. Whether I need to register my primary Name server in APNIC? Because, primary name server wont be published to the external world. Whether its really needed to register this in the APNIC?

>> I have created XYZ.com zone and added two NS RRs which are secondary servers. I am forced to give my primary NS details when creating SOA record. Whether the primary NS RR, which we have given in the SOA RR will be safe for the internet (threats) or not?

You can put whatever you want in your SOA area.

>>One more added question. Whether I need to register my primary Name server in APNIC? Because, primary name server wont be published to the external world. Whether its really needed to register this in the APNIC?

No
--
What you should do:
main.yourdomain.com -- main DNS server, unpublished
ns1.yourdomain.com -- your "primary" NS for the SOA/APNIC, but it is truly just the "main slave" in your setup.
ns2.yourdomain.com -- another slave

Set up the zones on the main (unpublished) server and set up the two child nameservers as slaves to your primary.

Effectively "ns1" is your main nameserver as far as the internet is concenered, and as far as BIND or whatever DNS daemon you are running is concerend it is "main"

Thanks scott. Appreciate your valuable time.

If we made the secondary NS(ns1.yourdomain.com) to act as primary NS for the SOA/APNIC, it may confuse a little. We will add the secondary refresh details in the SOA RR. How our new configuration will address this?

I don't understand what you are asking? Could you please clarify a little

Sorry for not explain it in detail.

I am really having some doubts in using this configuration which you suggested.

I made the secondary NS(ns1.yourdomain.com) to act as primary NS for SOA/APNIC as you suggested. Now, I feel the configuration is little confusing for me.

1. Whether the DDNS updates will happen without any problem?
2. How this secondary NS will contact the primary NS for the zone transfer request?

Is this is the only way (legal way) to hide the primary from the external world or this is one of the method. If there are more than one, please share the rest (hope you know the rest).

Cyril.

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;
};

Thanks a lot Scott.
It was very useful.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.