Re: oddity with trubuiltpambula.com.au
On Mon, 2020-04-20 at 13:06 +1000, Mark Andrews wrote: > Note there isn’t a “additional lookup occurring” because what you are > seeing is a referral and a answer. Yes, I realised that after sending my email. r.au returned the webcity nameservers, and one of those returned the NS details requested. After being twice told by the webcity people that everything was fine, they escalated it and have informed me that they have corrected the delegation: "We have received an update from our higher support that the name servers have been synced correctly to show the right name servers added in the account." Well - almost. The zone is delegated in .au to three webcity nameservers, but those nameservers return only the first two webcity nameservers when asked. So not quite 100% consistent, but good enough. Thanks, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170 Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Batch updating all DNS records on my Bind server
On Sat, Apr 18, 2020 at 12:52 PM Tony Finch wrote: > > @lbutlr wrote: > > > > 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 > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > 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 > bind-users@lists.isc.org > 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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Batch updating all DNS records on my Bind server
On 2020-04-20 10:33, Warren Kumari wrote: On Sat, Apr 18, 2020 at 12:52 PM Tony Finch wrote: @lbutlr wrote: > > 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 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." 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 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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND-9.16.1 memory leak?
On 2020-04-17 06:45, sth...@nethelp.no wrote: > We have what appears to be a significant memory leak in BIND-9.16.1. > > Environment: > FreeBSD 12.1-STABLE. > BIND-9.16.1 installed from packages. > Also uses libuv-1.35.0 installed from packages. > Authoritative only. > Around 800 zones of varying sizes. DNSSEC in use. Additional datum, as I am seeing the same thing: - FreeBSD 12.1-RELEASE-p3 - BIND-9.16.1 compiled from ports/poudriere via a local package build server (no options changed, though, so it likely could have been installed from the FreeBSD package repo). - Authoritative only - `rndc status` reports 1058 zones (69 automatic) - Host is a VM with 16GiB allocated and 4 CPU cores - named running for approx 2.5 weeks (wall-clock) Current BIND status (from `top`): PID USERNAMETHR PRI NICE SIZERES STATEC TIMEWCPU COMMAND 1707 bind 14 520 5312M 5260M sigwai 2 34.4H 5.79% named A recursive-only server, running the same versions of all software, on an identically-provisioned VM, running for the same amount of wall-clock time (approximately 2.5 weeks) looks like this: PID USERNAMETHR PRI NICE SIZERES STATEC TIMEWCPU COMMAND 1485 bind 14 520 927M 890M sigwai 3 89.6H 32.86% named The recursive memory footprint looks normal. Contrast that with a separate server: - FreeBSD 11.3-RELEASE-p7 - BIND 9.14.11 compiled from ports/poudriere via a local package build server (no options changed, though, so it likely could have been installed from the FreeBSD package repo). - Authoritative only + recursive only running in a separate jail - Same configuration as above, only a bit busier - Host is standalone with 96GiB RAM and 8 cores In the `top` output below, both the jailed named processes are shown. The busier one is the authoritative-only: PID USERNAME THR PRI NICE SIZERES STATE C TIMEWCPU COMMAND 896 bind 18 520 956M 927M sigwai 0 99.2H 30.03% named 1584 bind 18 520 1171M 1080M sigwai 2 166.2H 13.47% named It definitely looks like a memory leak in 9.16.1 when configured as authoritative-only. The leak seems slow enough as to be manageable, but the footprint does appear to growing monotonically (and is still growing--by another 4M as I wrote this email). michael ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Batch updating all DNS records on my Bind server
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 KEY; // Allow the machine to update these records
for itself
};
Mark
> On 21 Apr 2020, at 03:23, Chuck Aurora wrote:
>
> On 2020-04-20 10:33, Warren Kumari wrote:
>> On Sat, Apr 18, 2020 at 12:52 PM Tony Finch wrote:
>>> @lbutlr wrote:
>>> >
>>> > 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
>
> 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."
>
>> 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
>
> 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
> bind-users@lists.isc.org
> 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: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Batch updating all DNS records on my Bind server
On Apr 20, 2020, at 18:11, Mark Andrews wrote: > > 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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
