Re: DNSSEC ZSK rollover
Evan Hunt wrote: > > It is intentional; it spreads out the work of resigning over a longer > period of time to reduce the load on the server. (And a lot of people > prefer smaller IXFRs anyway.) We have tweaked sig-signing-nodes and sig-signing-signatures to make incremental signing work in larger chunks. We also have a wee patch (by Chris Thompson) which makes the re-signing jitter more clumpy, so RRsets are re-signed if their scheduled time is within 5 minutes of the current time instead of 5 seconds. This patch might be an answer to a comment in this code which says: /* XXXMPA increase number of RRsets signed pre call */ https://git.csx.cam.ac.uk/x/ucs/ipreg/bind9.git/commitdiff/2eba83e63a8206d32e12f9f6b763fcdf63294b52 Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or moderate, but rough in southwest Viking. Showers later. Good, occasionally poor later. ___ 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: How does named log update request
liumingxing wrote: > As we know, named Logging of all dynamic update transactions. In the > update channel file, how I can know when the server receives update > request? Only at debug level 3, for example: 2015-09-01.11:25:55.851 client: debug 3: client 127.0.0.1#60986/key local-ddns: view auth: update Other preliminary update checks are at debug level 8, e.g.: 2015-09-01.11:32:32.162 update: debug 8: client 127.0.0.1#60986/key local-ddns: view auth: updating zone 'dotat.at/IN': update section prescan OK Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or moderate, but rough in southwest Viking. Showers later. Good, occasionally poor later. ___ 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
A tale of two nameservers - resolution problems
I have one nameserver running bind 9.8.2 and a new one running 9.9.4.
Both can resolve www.ietf.org
Only the 9.8.2 can resolve 0.centos.pool.ntp.org
I literally rsynced all the of the conf and zone files from the old to
the new, then changed all of the server name references. I have done
this before. I have another box running the 9.8.2 code that I built the
same way and it resolves both fqdns just fine.
I am a lost at what is the problem. Both have the same named.conf:
//
//
include "/etc/named/named.acl";
options
{
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
allow-query{ localhost; };
allow-query-cache{ localhost; };
recursion no;
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
//dnssec-enable yes;
//dnssec-validation yes;
//dnssec-lookaside auto;
dnssec-enable no;
dnssec-validation no;
/* Path to ISC DLV key */
//bindkeys-file "/etc/named.iscdlv.key";
//managed-keys-directory "/var/named/dynamic";
};
logging
{
/* If you want to enable debugging, eg. using the 'rndc trace' command,
* named will try to write the 'named.run' file in the $directory
(/var/named).
* By default, SELinux policy does not allow named to modify the
/var/named directory,
* so put the default debug log file in data/ :
*/
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
view "internal"
{
include "/etc/named/named.internal";
};
view"external"
{
include "/etc/named/named.external";
};
include "/etc/named/rndc.key";
==
and named.internal has:
/* This view will contain zones you want to serve only to "internal" clients
* that have addresses that are not on your directly attached LAN
interface subnets:
*/
match-clients{ httnets; };
match-destinations{ httnets; };
allow-query{ httnets; };
allow-query-cache{ httnets; };
allow-recursion{ httnets; };
recursion yes;
empty-zones-enable yes;
//include "/etc/named/named.trusted.key";
include "/etc/named.rfc1912.zones";
zone "." IN {
type hint;
file "named.root";
};
// These are your "authoritative" internal zones:
zone "htt-consult.com" {
type master;
file "httin-consult.com.zone";
};
etc.
==
Is the dnssec disabled possibly the problem? Like required now?
___
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: A tale of two nameservers - resolution problems
If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?
John
On Tue, Sep 1, 2015 at 9:09 AM, Robert Moskowitz wrote:
> I have one nameserver running bind 9.8.2 and a new one running 9.9.4.
>
> Both can resolve www.ietf.org
>
> Only the 9.8.2 can resolve 0.centos.pool.ntp.org
>
> I literally rsynced all the of the conf and zone files from the old to the
> new, then changed all of the server name references. I have done this
> before. I have another box running the 9.8.2 code that I built the same way
> and it resolves both fqdns just fine.
>
> I am a lost at what is the problem. Both have the same named.conf:
>
> //
> //
>
> include "/etc/named/named.acl";
>
> options
> {
> listen-on port 53 { any; };
> listen-on-v6 port 53 { any; };
>
> allow-query{ localhost; };
> allow-query-cache{ localhost; };
> recursion no;
>
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
>
> //dnssec-enable yes;
> //dnssec-validation yes;
> //dnssec-lookaside auto;
>
> dnssec-enable no;
> dnssec-validation no;
>
> /* Path to ISC DLV key */
> //bindkeys-file "/etc/named.iscdlv.key";
>
> //managed-keys-directory "/var/named/dynamic";
>
>
> };
> logging
> {
> /* If you want to enable debugging, eg. using the 'rndc trace' command,
> * named will try to write the 'named.run' file in the $directory
> (/var/named).
> * By default, SELinux policy does not allow named to modify the
> /var/named directory,
> * so put the default debug log file in data/ :
> */
> channel default_debug {
> file "data/named.run";
> severity dynamic;
> };
> };
>
> view "internal"
> {
>
> include "/etc/named/named.internal";
>
> };
> view"external"
> {
>
> include "/etc/named/named.external";
>
> };
>
> include "/etc/named/rndc.key";
>
> ==
> and named.internal has:
>
> /* This view will contain zones you want to serve only to "internal" clients
> * that have addresses that are not on your directly attached LAN interface
> subnets:
> */
> match-clients{ httnets; };
> match-destinations{ httnets; };
> allow-query{ httnets; };
> allow-query-cache{ httnets; };
> allow-recursion{ httnets; };
> recursion yes;
> empty-zones-enable yes;
>
> //include "/etc/named/named.trusted.key";
> include "/etc/named.rfc1912.zones";
>
> zone "." IN {
> type hint;
> file "named.root";
> };
>
> // These are your "authoritative" internal zones:
>
> zone "htt-consult.com" {
> type master;
> file "httin-consult.com.zone";
> };
>
> etc.
>
>
> ==
>
>
> Is the dnssec disabled possibly the problem? Like required now?
___
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: A tale of two nameservers - resolution problems
On 09/01/2015 09:20 AM, John Miller wrote:
If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?
I don't believe this and I have some serious problems.
Part of my challenge is I am running the new server on an armv7 board
that does not have a rtc. So when the system boots, the time is jan 1
1970. The first thing you want to run is ntp to set the time, but
requires named running and resolving.
For the 'fun' of it, I used 'date' to set the time to now, and then no
problem resolving 0.centos.pool.ntp.org. So there is something about
that resolution that does not like the early date.
So I am caught in a time bind here!
Is there anyway to get bind not to be particular about system time at first?
John
On Tue, Sep 1, 2015 at 9:09 AM, Robert Moskowitz wrote:
I have one nameserver running bind 9.8.2 and a new one running 9.9.4.
Both can resolve www.ietf.org
Only the 9.8.2 can resolve 0.centos.pool.ntp.org
I literally rsynced all the of the conf and zone files from the old to the
new, then changed all of the server name references. I have done this
before. I have another box running the 9.8.2 code that I built the same way
and it resolves both fqdns just fine.
I am a lost at what is the problem. Both have the same named.conf:
//
//
include "/etc/named/named.acl";
options
{
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
allow-query{ localhost; };
allow-query-cache{ localhost; };
recursion no;
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
//dnssec-enable yes;
//dnssec-validation yes;
//dnssec-lookaside auto;
dnssec-enable no;
dnssec-validation no;
/* Path to ISC DLV key */
//bindkeys-file "/etc/named.iscdlv.key";
//managed-keys-directory "/var/named/dynamic";
};
logging
{
/* If you want to enable debugging, eg. using the 'rndc trace' command,
* named will try to write the 'named.run' file in the $directory
(/var/named).
* By default, SELinux policy does not allow named to modify the
/var/named directory,
* so put the default debug log file in data/ :
*/
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
view "internal"
{
include "/etc/named/named.internal";
};
view"external"
{
include "/etc/named/named.external";
};
include "/etc/named/rndc.key";
==
and named.internal has:
/* This view will contain zones you want to serve only to "internal" clients
* that have addresses that are not on your directly attached LAN interface
subnets:
*/
match-clients{ httnets; };
match-destinations{ httnets; };
allow-query{ httnets; };
allow-query-cache{ httnets; };
allow-recursion{ httnets; };
recursion yes;
empty-zones-enable yes;
//include "/etc/named/named.trusted.key";
include "/etc/named.rfc1912.zones";
zone "." IN {
type hint;
file "named.root";
};
// These are your "authoritative" internal zones:
zone "htt-consult.com" {
type master;
file "httin-consult.com.zone";
};
etc.
==
Is the dnssec disabled possibly the problem? Like required now?
___
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: A tale of two nameservers - resolution problems
Am 01.09.2015 um 15:31 schrieb Robert Moskowitz: On 09/01/2015 09:20 AM, John Miller wrote: If you check pcap, logs, etc., is the server's following delegation for 0.centos.pool.ntp.org? Where do outbound packets stop? I don't believe this and I have some serious problems. Part of my challenge is I am running the new server on an armv7 board that does not have a rtc. So when the system boots, the time is jan 1 1970. The first thing you want to run is ntp to set the time, but requires named running and resolving. For the 'fun' of it, I used 'date' to set the time to now, and then no problem resolving 0.centos.pool.ntp.org. So there is something about that resolution that does not like the early date. So I am caught in a time bind here! Is there anyway to get bind not to be particular about system time at first? what about /etc/hosts and using a "ntpdate customname" at boot *before* ntpd and named are started - what i honestly don't understand is why you are punishing yourself with that ARM crap over years (given all the troubles on other lists) signature.asc Description: OpenPGP digital signature ___ 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: A tale of two nameservers - resolution problems
On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz wrote: > > > On 09/01/2015 09:20 AM, John Miller wrote: >> >> If you check pcap, logs, etc., is the server's following delegation >> for 0.centos.pool.ntp.org? Where do outbound packets stop? > > > I don't believe this and I have some serious problems. > > Part of my challenge is I am running the new server on an armv7 board that > does not have a rtc. So when the system boots, the time is jan 1 1970. The > first thing you want to run is ntp to set the time, but requires named > running and resolving. > > For the 'fun' of it, I used 'date' to set the time to now, and then no > problem resolving 0.centos.pool.ntp.org. So there is something about that > resolution that does not like the early date. > > So I am caught in a time bind here! > > Is there anyway to get bind not to be particular about system time at first? Hopefully this isn't a production server... rtc's kind of important ;-) I'll ditto here and say: static /etc/hosts entries or static IPs in ntp.conf. John ___ 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: A tale of two nameservers - resolution problems
Am 01.09.2015 um 16:28 schrieb John Miller: On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz wrote: On 09/01/2015 09:20 AM, John Miller wrote: If you check pcap, logs, etc., is the server's following delegation for 0.centos.pool.ntp.org? Where do outbound packets stop? I don't believe this and I have some serious problems. Part of my challenge is I am running the new server on an armv7 board that does not have a rtc. So when the system boots, the time is jan 1 1970. The first thing you want to run is ntp to set the time, but requires named running and resolving. For the 'fun' of it, I used 'date' to set the time to now, and then no problem resolving 0.centos.pool.ntp.org. So there is something about that resolution that does not like the early date. So I am caught in a time bind here! Is there anyway to get bind not to be particular about system time at first? Hopefully this isn't a production server... rtc's kind of important ;-) I'll ditto here and say: static /etc/hosts entries or static IPs in ntp.conf additionally every network normally should have it's own ntpd using the public pool and act as source for all other machines, just because to be nice too the "pool.ntp.org" and hence any other box needs just an IP address for doing "ntpdate xx.xx.xx.xx" *before* it's own ntpd starts so you just need to make sure the correct order * ntpdate xx.xx.xx.xx * start ntpd * start named signature.asc Description: OpenPGP digital signature ___ 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: A tale of two nameservers - resolution problems
On Tue, Sep 1, 2015 at 10:38 AM, Reindl Harald wrote: > > Am 01.09.2015 um 16:28 schrieb John Miller: > >> On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz >> wrote: >> >>> >>> On 09/01/2015 09:20 AM, John Miller wrote: >>> If you check pcap, logs, etc., is the server's following delegation for 0.centos.pool.ntp.org? Where do outbound packets stop? >>> >>> >>> I don't believe this and I have some serious problems. >>> >>> Part of my challenge is I am running the new server on an armv7 board >>> that >>> does not have a rtc. So when the system boots, the time is jan 1 1970. >>> The >>> first thing you want to run is ntp to set the time, but requires named >>> running and resolving. >>> >>> For the 'fun' of it, I used 'date' to set the time to now, and then no >>> problem resolving 0.centos.pool.ntp.org. So there is something about >>> that >>> resolution that does not like the early date. >>> >>> So I am caught in a time bind here! >>> >>> Is there anyway to get bind not to be particular about system time at >>> first? >>> >> >> >> Hopefully this isn't a production server... rtc's kind of important >> ;-) I'll ditto here and say: static /etc/hosts entries or static IPs >> in ntp.conf >> > > additionally every network normally should have it's own ntpd using the > public pool and act as source for all other machines, just because to be > nice too the "pool.ntp.org" and hence any other box needs just an IP > address for doing "ntpdate xx.xx.xx.xx" *before* it's own ntpd starts > > so you just need to make sure the correct order > > * ntpdate xx.xx.xx.xx > * start ntpd > * start named > > Can I suggest that rather than use /etc/hosts, every server should have more than one resolver listed in /etc/resolv.conf. The first can be 127.0.0.1, but the second should be another DNS resolver as backup. -- Bob Harold ___ 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: A tale of two nameservers - resolution problems
On 09/01/2015 09:36 AM, Reindl Harald wrote: Am 01.09.2015 um 15:31 schrieb Robert Moskowitz: On 09/01/2015 09:20 AM, John Miller wrote: If you check pcap, logs, etc., is the server's following delegation for 0.centos.pool.ntp.org? Where do outbound packets stop? I don't believe this and I have some serious problems. Part of my challenge is I am running the new server on an armv7 board that does not have a rtc. So when the system boots, the time is jan 1 1970. The first thing you want to run is ntp to set the time, but requires named running and resolving. For the 'fun' of it, I used 'date' to set the time to now, and then no problem resolving 0.centos.pool.ntp.org. So there is something about that resolution that does not like the early date. So I am caught in a time bind here! Is there anyway to get bind not to be particular about system time at first? what about /etc/hosts and using a "ntpdate customname" at boot *before* ntpd and named are started - One of the obvious punts I am looking at. what i honestly don't understand is why you are punishing yourself with that ARM crap over years (given all the troubles on other lists) Because it is FUN!!! Other reasons too, but those are long to get into. ___ 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: A tale of two nameservers - resolution problems
On 09/01/2015 10:28 AM, John Miller wrote: On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz wrote: On 09/01/2015 09:20 AM, John Miller wrote: If you check pcap, logs, etc., is the server's following delegation for 0.centos.pool.ntp.org? Where do outbound packets stop? I don't believe this and I have some serious problems. Part of my challenge is I am running the new server on an armv7 board that does not have a rtc. So when the system boots, the time is jan 1 1970. The first thing you want to run is ntp to set the time, but requires named running and resolving. For the 'fun' of it, I used 'date' to set the time to now, and then no problem resolving 0.centos.pool.ntp.org. So there is something about that resolution that does not like the early date. So I am caught in a time bind here! Is there anyway to get bind not to be particular about system time at first? Hopefully this isn't a production server... rtc's kind of important ;-) Lack of a battery for the system clock is the norm for arm boards. They pretty much expect network time. This is a problem with designing a mobile arm solution. I'll ditto here and say: static /etc/hosts entries or static IPs in ntp.conf. Definitely the obvious punt. ___ 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: A tale of two nameservers - resolution problems
On 09/01/2015 10:38 AM, Reindl Harald wrote: Am 01.09.2015 um 16:28 schrieb John Miller: On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz wrote: On 09/01/2015 09:20 AM, John Miller wrote: If you check pcap, logs, etc., is the server's following delegation for 0.centos.pool.ntp.org? Where do outbound packets stop? I don't believe this and I have some serious problems. Part of my challenge is I am running the new server on an armv7 board that does not have a rtc. So when the system boots, the time is jan 1 1970. The first thing you want to run is ntp to set the time, but requires named running and resolving. For the 'fun' of it, I used 'date' to set the time to now, and then no problem resolving 0.centos.pool.ntp.org. So there is something about that resolution that does not like the early date. So I am caught in a time bind here! Is there anyway to get bind not to be particular about system time at first? Hopefully this isn't a production server... rtc's kind of important ;-) I'll ditto here and say: static /etc/hosts entries or static IPs in ntp.conf additionally every network normally should have it's own ntpd using the public pool and act as source for all other machines, But this is the system that will be the internal ntp server :) At least at first. One of the base boards I can add has the battery on it. But I would only pay for that for this server. This is one of the other obvious punts: get a battery rtc. just because to be nice too the "pool.ntp.org" and hence any other box needs just an IP address for doing "ntpdate xx.xx.xx.xx" *before* it's own ntpd starts There will be a lot of arm IoT boxes in the next few years needing their time on boot. Of course booting will not be that frequent, but it will interesting to see how it plays out. And check devices like the esp8266, as $6 IoT device. It also gets its time once connected. so you just need to make sure the correct order * ntpdate xx.xx.xx.xx * start ntpd * start named I will be looking more into this. Obvious when you get ones nose dragged into time wrong on boot. This is actually a broader problem on arm SoC booting. Your logs all have the wrong time for the boot messages until there is a network to get time. I have some ideas for a process that will set time a boot to the time of the last poweroff. at least that is 'close enough' for starters. ___ 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: A tale of two nameservers - resolution problems
On 01/09/15 17:46, Robert Moskowitz wrote: > > There will be a lot of arm IoT boxes in the next few years needing > their time on boot. Of course booting will not be that frequent, but > it will interesting to see how it plays out. And check devices like > the esp8266, as $6 IoT device. It also gets its time once connected. This will be very interesting when all those boxes have fixed addresses in IPv4 and the environment goes to IPv6. Or those addresses disappear for whatever reason. Obsolete devices? > >> so you just need to make sure the correct order >> >> * ntpdate xx.xx.xx.xx >> * start ntpd >> * start named > > I will be looking more into this. Obvious when you get ones nose > dragged into time wrong on boot. This is actually a broader problem > on arm SoC booting. Your logs all have the wrong time for the boot > messages until there is a network to get time. I have some ideas for > a process that will set time a boot to the time of the last poweroff. > at least that is 'close enough' for starters. > > ___ > 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 -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" ___ 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: A tale of two nameservers - resolution problems
In article , Robert Moskowitz wrote: > I will be looking more into this. Obvious when you get ones nose > dragged into time wrong on boot. This is actually a broader problem on > arm SoC booting. Your logs all have the wrong time for the boot > messages until there is a network to get time. I have some ideas for a > process that will set time a boot to the time of the last poweroff. at > least that is 'close enough' for starters. I believe that's the solution Apple adopted for the AppleTV, which has no rtc and couldn't use a certificate to connect to a wireless network because the certificate wasn't valid in 1970. Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ 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
Solved - Re: A tale of two nameservers - resolution problems
On 09/01/2015 12:16 PM, Sam Wilson wrote: In article , Robert Moskowitz wrote: I will be looking more into this. Obvious when you get ones nose dragged into time wrong on boot. This is actually a broader problem on arm SoC booting. Your logs all have the wrong time for the boot messages until there is a network to get time. I have some ideas for a process that will set time a boot to the time of the last poweroff. at least that is 'close enough' for starters. I believe that's the solution Apple adopted for the AppleTV, which has no rtc and couldn't use a certificate to connect to a wireless network because the certificate wasn't valid in 1970. On the Fedora-arm list I was told about systemd-timesyncd. Much better for these systems than chronyd which is suppose to be the replacement for ntpdate... I am looking into this; it sounds exactly what I need. Plus when you make your os image you can: touch //var/lib/systemd/clock chown systemd-timesync:systemd-timesync //var/lib/systemd/clock And firstboot will have a rather current time. Oh course this assumes the image builders include systemd-timesync as part of the base install. ___ 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
response to SOA query was unsuccessful
Hello, I met a strange issue with adding a zone to BIND that I can't understand for, :) I have two nameservers, say they are: ns1.example.com ns2.example.com There are dozens of zones resolved by these two. But, the zone example.com itself is resolved by registrar's DNS servers. For example, example.com.10800 IN NS ns1.registrar.net. example.com.10800 IN NS ns2.registrar.net. Now I want to change the zone to be resolved by ns1.example.com and ns2.example.com. Before change the glues in registrar's control panel, I edited named.conf and added a zone file to /var/cache/bind/ for example.com, reload BIND in master. It seems fine. But when I tried to add a record to this zone via nsupdate, it got failed, the log shows: [20150828142228] response to SOA query was unsuccessful [20150828142228] response to SOA query was unsuccessful [20150828142231] response to SOA query was unsuccessful [20150828142231] response to SOA query was unsuccessful Why this happens and how to fixup it? Thanks. regards. ___ 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: response to SOA query was unsuccessful
In message <55e64e21.8090...@runbox.com>, Ken Peng writes: > Hello, > > I met a strange issue with adding a zone to BIND that I can't understand > for, :) > > I have two nameservers, say they are: > > ns1.example.com > ns2.example.com > > There are dozens of zones resolved by these two. > > But, the zone example.com itself is resolved by registrar's DNS servers. > For example, > > example.com.10800 IN NS ns1.registrar.net. > example.com.10800 IN NS ns2.registrar.net. > > Now I want to change the zone to be resolved by ns1.example.com and > ns2.example.com. > > Before change the glues in registrar's control panel, I edited > named.conf and added a zone file to /var/cache/bind/ for example.com, > reload BIND in master. It seems fine. But when I tried to add a record > to this zone via nsupdate, it got failed, the log shows: > > [20150828142228] response to SOA query was unsuccessful > > [20150828142228] response to SOA query was unsuccessful > > [20150828142231] response to SOA query was unsuccessful > > [20150828142231] response to SOA query was unsuccessful > > Why this happens and how to fixup it? Thanks. First thing. Stop this example.com garbage. If you want people to help you give them real names. That way they can go and test the servers involved and give you specific answers. * Did you read the logs on the servers and correct any errors reported? * Did you check that they were actually serving the new zone? * Did you point nsupdate at the correct servers? You are in the process of moving them so the automatic discovery of the servers won't work. > regards. > ___ > 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: response to SOA query was unsuccessful
On 2015/9/2 星期三 9:34, Mark Andrews wrote: * Did you read the logs on the servers and correct any errors reported? Yes I watched the nameserver's log all the time when I did those. They were nothing special happened. * Did you check that they were actually serving the new zone? I don't think they were working correctly. When I added the zone file to a slave which is with higher version than master, after reloading, the strange thing happened. This zone file was deleted by the nameserver automatically. * Did you point nsupdate at the correct servers? You are in the process of moving them so the automatic discovery of the servers won't work. Yes, I run nsupdate always in the master, and point the remote server to 127.0.0.1. Thanks for any helps :) ___ 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: Re: How does named log update request
HI, FINCH, In which level named log the receiving time and responding time of a update request? :) Mingxing, Liu email：liumingx...@cnnic.cn tel：（010）58812467 From: Tony Finch Date: 2015-09-01 18:34 To: liumingxing CC: bind-users Subject: Re: How does named log update request liumingxing wrote: > As we know, named Logging of all dynamic update transactions. In the > update channel file, how I can know when the server receives update > request? Only at debug level 3, for example: 2015-09-01.11:25:55.851 client: debug 3: client 127.0.0.1#60986/key local-ddns: view auth: update Other preliminary update checks are at debug level 8, e.g.: 2015-09-01.11:32:32.162 update: debug 8: client 127.0.0.1#60986/key local-ddns: view auth: updating zone 'dotat.at/IN': update section prescan OK Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or moderate, but rough in southwest Viking. Showers later. Good, occasionally poor later. ___ 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
