change the SOA

Kevin Darcy kcd at daimlerchrysler.com
Fri Jan 27 00:09:08 UTC 2006


Aleksander wrote:

>Thanks for the replies,
>
>When I register a domain, the registrar requires the nameserver to match 
>the SOA's name, that's the reason I have the auto-generated-blah stuff 
>in the whois database. I thought the SOA was the record that is the 
>first thing queried when resolving to IPs. Guess I was wrong.
>
>About the temp. name servers. The current whois entry lists the 
>auto-generated-blah.example.com as the primary nameserver, which is also 
>the SOA record's name. I want to get rid of that and have just 
>example.com as the nameserver.
>
>If I remove the auto-generated-blah.example.com nameserver entry, things 
>will break i presume. 
>
You are required to have at least 2 nameservers for every domain. If you 
have 2 functional nameservers in addition to 
auto-generated-blah.example, then removing 
auto-generated-blah.example.com shouldn't break anything.

>Changing the SOA's name on the other hand won't, 
>correct? 
>
I hate to give iron-clad guarantees on things like that. The only 
*standards-defined* things which use SOA.MNAME are Dynamic Update and 
NOTIFY, as previously noted. If, however, some custom app cares about 
SOA.MNAME then you could potentially break that app.

>If so, I could start changing the SOA names right away without 
>fear that something will break, that so? That way I could have normal 
>nameserver entries at the registrar before the IP change.
>
>The ripe entries are the resposibility of the ISP. The PTR zones are at 
>the ISP too after all, so is the slave/secondary nameserver. Changing 
>the net block only, to get additional public IP's, not changing ISP.
>
>And some general questions:
>I've read quite a few DNS and BIND tutorials so far, but still don't 
>understand how exatly DNS name resolving takes place. When "local" DNS 
>servers don't know anything about a queried domain, say example.com, 
>they query the root dns servers. Now how do these know where to search 
>for? Do they do whois queries, to get the nameservers? Or do all DNS 
>servers perform whois queries? 
>
No, WHOIS is a separate database and is not involved in normal DNS 
resolution.

The various registries, however, have databases for delegation and glue 
records and ideally, WHOIS will reflect those databases faithfully 
(although I've seen some pretty crazy stuff in the gTLD WHOIS).

>Exatly when are the records for my 
>nameservers from the registrar updated? 
>
When your registrar submits the update to the database which feeds the 
gTLD servers.

>And these are names, not IP's, 
>
Actually, they typically are *both*. There's a bit of a chicken-and-egg 
situation, if you think about it, in delegating a .com domain (for 
example) to a nameserver whose name is also in the same domain. So 
registries typically ask for both the names of the nameservers, and 
their IPs, so that extra "glue" records can be generated in the TLD 
zones for the cases where they are needed.

>The TTL for the domains is set to 5 days at the moment, I should change 
>it one week before the IP change to how much? I've seen figures like 15 
>minutes and the like, is 15 minutes OK? It's not google.com, so not too 
>much extra DNS traffic I guess.
>
Low TTLs (e.g. less than an hour) are somewhat anti-social (they make 
everyone's nameservers work harder), and should be limited to migrations 
and high-availability/load-balancing situations.

>My current plan looks like this:
>
>1.
>    a) Change the SOA records.
>    b) Add new NS record and leave auto-generated-blah.example.com NS 
>intact.
>    c) Set TTL to something small, say 15 minutes.
>    d) Tell the registrar to change primary NS.
>
>2.
>    a) A week later change the A records to new IP's.
>    b) Wait 20 minutes to have the slave and anybody else the new A records.
>    c) Let the ISP change IPs, PTR, ripe and whatever (this will have to 
>negotiated first ofc., but it's still possible).
>    d) remove auto-generated-blah.example.com NS record.
>
>The result would be a maximum of an hour downtime due to DNS. Is that 
>correct and/or plausible?
>
I think you're underestimating how adaptable nameserver-to-nameserver 
interactions are. They fail over quickly and transparently. Just add the 
new NS'es, make the switch and delete the old NSes when you're done. You 
just need to make sure that there is a resolvable set of NS'es serving 
the zone at all times (taking into account cache-persistence/TTL), both 
in the delegation records and at the zone's apex. Because of the way 
registries work, you can't guarantee 100% lockstep at all times between 
your delegation info and your apex info, but as an end result, those two 
should contain the same dataset.

                                                                         
                                                   - Kevin




More information about the bind-users mailing list