Discussion:
Batch updating all DNS records on my Bind server
(too old to reply)
@lbutlr
2020-04-18 15:23:56 UTC
Permalink
We are making some changes to our NSP account and the NSP is threatening to change our IP block. This means I will have to update all the domains on the system (all using DNSSEC). We are still arguing with them since there is no technical reason for forcing this change on us, but chances are they will prove to be inflexible.

Is it possible to batch update all the domains? Looking at nsupdate it looks like I have to step through and do every domain individually.

The only occurrence of ‘batch’ on the nsupdate man page is:

-v Use TCP even for small update requests. By default, nsupdate uses
UDP to send update requests to the name server unless they are too
large to fit in a UDP request in which case TCP will be used. TCP
may be preferable when a batch of update requests is made.
--
'They say that whoever pays the piper calls the tune.' 'But,
gentlemen,' said Mr Saveloy, 'whoever holds a knife to the
piper's throat writes the symphony.' --Interesting Times
Reindl Harald
2020-04-18 15:34:18 UTC
Permalink
Post by @lbutlr
We are making some changes to our NSP account and the NSP is threatening to change our IP block. This means I will have to update all the domains on the system (all using DNSSEC). We are still arguing with them since there is no technical reason for forcing this change on us, but chances are they will prove to be inflexible.
Is it possible to batch update all the domains? Looking at nsupdate it looks like I have to step through and do every domain individually.
-v Use TCP even for small update requests. By default, nsupdate uses
UDP to send update requests to the name server unless they are too
large to fit in a UDP request in which case TCP will be used. TCP
may be preferable when a batch of update requests is made.
well, where is the issue iterate all your domains in a bash script as
you don't seem to have some sql backed admin interface?

a global ipchange is something you should have pre-scripted unless you
have a provider independent ip-range
@lbutlr
2020-04-18 15:39:27 UTC
Permalink
Post by Reindl Harald
Post by @lbutlr
Is it possible to batch update all the domains? Looking at nsupdate it looks like I have to step through and do every domain individually.
well, where is the issue iterate all your domains in a bash script as
you don't seem to have some sql backed admin interface?
“nsupdate does not support batch updates” would have been shorter.
--
showing snuffy is when Sesame Street jumped the shark
Reindl Harald
2020-04-18 15:44:52 UTC
Permalink
Post by @lbutlr
Post by Reindl Harald
Post by @lbutlr
Is it possible to batch update all the domains? Looking at nsupdate it looks like I have to step through and do every domain individually.
well, where is the issue iterate all your domains in a bash script as
you don't seem to have some sql backed admin interface?
“nsupdate does not support batch updates” would have been shorter
dunno if it can but i fail to imagine how that should work - how does it
know about your domains at all?

the loaded zones can be a wild mix of forward and reverse zones, what
exactly should it replace

doing something with 10, 200, 1000 zones is where admin software has
it's place - in the backend i coded in 2008 i can write pure hostnames
of our own zone as value for A records

when generate a zone from the database wthis will be replaced by the
current ip in our own one and an additional button triggers "rebuild all
zones from scratch"

more or less one night the days back and maybe with the "virtual CNMAE
for A records" or however one will call it a second night and the reason
for that was, well, a ipchange for the whole network
Tony Finch
2020-04-18 16:52:00 UTC
Permalink
Post by @lbutlr
Is it possible to batch update all the domains? Looking at nsupdate it
looks like I have to step through and do every domain individually.
An UPDATE request can change many records, so long as they are all in the
same zone, and so long as they fit in the 64KB limit of DNS message size.
I find one request is usually enough for routine changes, but if you are
doing a bulk update to a large zone, you will need to split the changes
across mulitiple update requests.

You might find nsdiff helpful, both to verify that your bulk changes are
what you expect, and because it will split large updates into multiple
requests automatically. It's still one-zone-at-a-time, though. A
quick-and-dirty starting point might be roughly

dig axfr $zone |
sed 's/oldprefix/newprefix/' |
nsdiff $zone /dev/stdin |
nsupdate -l

https://dotat.at/prog/nsdiff/

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/
North Utsire, South Utsire: Variable 3 or less. Smooth or slight, occasionally
moderate at first. Fair. Good.
Warren Kumari
2020-04-20 15:33:22 UTC
Permalink
Post by Tony Finch
Post by @lbutlr
Is it possible to batch update all the domains? Looking at nsupdate it
looks like I have to step through and do every domain individually.
An UPDATE request can change many records, so long as they are all in the
same zone, and so long as they fit in the 64KB limit of DNS message size.
I find one request is usually enough for routine changes, but if you are
doing a bulk update to a large zone, you will need to split the changes
across mulitiple update requests.
You might find nsdiff helpful, both to verify that your bulk changes are
what you expect, and because it will split large updates into multiple
requests automatically. It's still one-zone-at-a-time, though. A
quick-and-dirty starting point might be roughly
dig axfr $zone |
sed 's/oldprefix/newprefix/' |
nsdiff $zone /dev/stdin |
nsupdate -l
https://dotat.at/prog/nsdiff/
Another option may be:
rndc sync
rndc freeze
rndc sync
[sed and awk[0] ]
rndc thaw

?

W
[0]: Now at this point I should have remembered that profound truism:
“Some people, when confronted with a Unix problem, think ‘I know,
I’ll use sed.’ Now they have two problems.” jwz - 12 Dec 1992
Post by Tony Finch
Tony.
--
North Utsire, South Utsire: Variable 3 or less. Smooth or slight, occasionally
moderate at first. Fair. Good.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
Chuck Aurora
2020-04-20 17:23:22 UTC
Permalink
Post by Warren Kumari
Post by Tony Finch
Post by @lbutlr
Is it possible to batch update all the domains? Looking at nsupdate it
looks like I have to step through and do every domain individually.
An UPDATE request can change many records, so long as they are all in
the
same zone, and so long as they fit in the 64KB limit of DNS message
size.
I find one request is usually enough for routine changes, but if you
are
doing a bulk update to a large zone, you will need to split the
changes
across mulitiple update requests.
You might find nsdiff helpful, both to verify that your bulk changes
are
what you expect, and because it will split large updates into multiple
requests automatically. It's still one-zone-at-a-time, though. A
quick-and-dirty starting point might be roughly
dig axfr $zone |
sed 's/oldprefix/newprefix/' |
nsdiff $zone /dev/stdin |
nsupdate -l
https://dotat.at/prog/nsdiff/
rndc sync
rndc freeze
rndc sync
[sed and awk[0] ]
rndc thaw
The problem with freeze and thaw is that you lose your history. I like
having history, and it won't hurt to have that in the future, when
dealing with the ISP's next capricious reassignment. "On 2020-04-23[1]
you moved us from x.x.x.x to y.y.y.y, and now again to z.z.z.z? We are
paying for a static IP address, what does 'static' mean?"

Another problem with that choice is that the zones are signed, and named
will have to re-sign the whole zone in one go. I think (not sure) that
with nsupdate the signing will happen one record at a time; or at least,
only the relevant A / TXT(SPF) records with the changed IP address will
need to be signed. Given that there are lots of zones being done in a
loop, there could be a very high load on the server and drain on its
pool of entropy.

So yeah, I'd go with Tony's plan here. But I suppose the bottom line
for this list is, "nsupdate can't do batches, you have to script it."
Post by Warren Kumari
W
“Some people, when confronted with a Unix problem, think ‘I know,
I’ll use sed.’ Now they have two problems.” jwz - 12 Dec 1992
LOL, yes, I thought that quote was about regular expressions, but
either way it sure fits.


[1] Shakespeare's death, 404 years ago; birth, 456 years ago, that day.
What would the Bard do? "To sed, or not to sed, ..."
Mark Andrews
2020-04-21 00:11:25 UTC
Permalink
Really all machines should be updating their own address records in the
DNS. Have each machine create a KEY record with its name. Install the
KEY record in the DNS. Use SIG(0) signed UPDATE requests to update the
address records.

update-policy {
grant * self . A AAAA KEY; // Allow the machine to update these records for itself
};

Mark
Post by Chuck Aurora
Post by Warren Kumari
Post by Tony Finch
Post by @lbutlr
Is it possible to batch update all the domains? Looking at nsupdate it
looks like I have to step through and do every domain individually.
An UPDATE request can change many records, so long as they are all in the
same zone, and so long as they fit in the 64KB limit of DNS message size.
I find one request is usually enough for routine changes, but if you are
doing a bulk update to a large zone, you will need to split the changes
across mulitiple update requests.
You might find nsdiff helpful, both to verify that your bulk changes are
what you expect, and because it will split large updates into multiple
requests automatically. It's still one-zone-at-a-time, though. A
quick-and-dirty starting point might be roughly
dig axfr $zone |
sed 's/oldprefix/newprefix/' |
nsdiff $zone /dev/stdin |
nsupdate -l
https://dotat.at/prog/nsdiff/
rndc sync
rndc freeze
rndc sync
[sed and awk[0] ]
rndc thaw
The problem with freeze and thaw is that you lose your history. I like
having history, and it won't hurt to have that in the future, when
dealing with the ISP's next capricious reassignment. "On 2020-04-23[1]
you moved us from x.x.x.x to y.y.y.y, and now again to z.z.z.z? We are
paying for a static IP address, what does 'static' mean?"
Another problem with that choice is that the zones are signed, and named
will have to re-sign the whole zone in one go. I think (not sure) that
with nsupdate the signing will happen one record at a time; or at least,
only the relevant A / TXT(SPF) records with the changed IP address will
need to be signed. Given that there are lots of zones being done in a
loop, there could be a very high load on the server and drain on its
pool of entropy.
So yeah, I'd go with Tony's plan here. But I suppose the bottom line
for this list is, "nsupdate can't do batches, you have to script it."
Post by Warren Kumari
W
“Some people, when confronted with a Unix problem, think ‘I know,
I’ll use sed.’ Now they have two problems.” jwz - 12 Dec 1992
LOL, yes, I thought that quote was about regular expressions, but
either way it sure fits.
[1] Shakespeare's death, 404 years ago; birth, 456 years ago, that day.
What would the Bard do? "To sed, or not to sed, ..."
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org
LuKreme
2020-04-21 02:04:57 UTC
Permalink
Post by Mark Andrews
Really all machines should be updating their own address records in the
DNS. Have each machine create a KEY record with its name. Install the
KEY record in the DNS. Use SIG(0) signed UPDATE requests to update the
address records.
This will be the third IP change in 26 years. Maybe the fourth.

Sent from my iPhone

Loading...