Re: Re: How does named log update request

2015-09-02 Thread Tony Finch
liumingxing  wrote:

> In which level named log the receiving time and responding time of a 
> update request?

3

2015-09-01.11:32:32.162 client: debug 3: client 127.0.0.1#60986/key local-ddns: 
view auth: update
2015-09-01.11:32:32.164 client: debug 3: client 127.0.0.1#60986/key local-ddns: 
view auth: send

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: DNS Negative Caching (Harshith)

2015-09-02 Thread Harshith Mulky
I thank you all for providing me such valuable information on DNS Negative 
Caching
I would have never thought that so many things would be Applied in deciding 
what would be cached

I once again thank each one of you and appreciate for the time and valuable 
feedback

Cheers
Harshith

> From: bind-users-requ...@lists.isc.org
> Subject: bind-users Digest, Vol 2189, Issue 1
> To: bind-users@lists.isc.org
> Date: Tue, 1 Sep 2015 12:00:01 +
> 
> Send bind-users mailing list submissions to
>   bind-users@lists.isc.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.isc.org/mailman/listinfo/bind-users
> or, via email, send a message with subject or body 'help' to
>   bind-users-requ...@lists.isc.org
> 
> You can reach the person managing the list at
>   bind-users-ow...@lists.isc.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bind-users digest..."
> 
> 
> Today's Topics:
> 
>1. Re: DNS Negative Caching (Chris Buxton)
>2. How does named log update request (liumingxing)
>3. Re: DNS Negative Caching (Rich Goodson)
>4. Re: DNSSEC ZSK rollover (Tony Finch)
>5. Re: How does named log update request (Tony Finch)
> 
> 
> --
> 
> Message: 1
> Date: Mon, 31 Aug 2015 07:19:33 -0700
> From: Chris Buxton 
> To: Barry Margolin 
> Cc: comp-protocols-dns-b...@isc.org
> Subject: Re: DNS Negative Caching
> Message-ID: <9ca7db5c-6e06-4ec8-a216-16a926cba...@buxtonfamily.us>
> Content-Type: text/plain; charset=us-ascii
> 
> On Aug 28, 2015, at 5:27 PM, Barry Margolin  wrote:
> 
> > Note that if a server is authoritative-only, caching is mostly 
> > irrelevant, so the negative cache TTL doesn't much apply. In this case, 
> > the SOA Minimum is just being used as the default TTL.
> 
> No, that is not correct. When responding negatively, the authoritative server 
> uses the negative caching TTL (the Minimum field) as the TTL of the SOA 
> record in the authority section.
> 
> Chris
> 
> --
> 
> Message: 2
> Date: Mon, 31 Aug 2015 22:36:30 +0800
> From: liumingxing 
> To: bind-users 
> Subject: How does named log update request
> Message-ID: <2015083122362973447...@cnnic.cn>
> Content-Type: text/plain; charset="gb2312"
> 
> hi,
> In my server, I found update need longer time, So I want to check why by 
> checking logs.
>   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?
> 
> 
> 
> 
> 
> 
> Mingxing, Liu
>  
> mail?liumingx...@cnnic.cn
> tel??010?58812467
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> 
> 
> --
> 
> Message: 3
> Date: Mon, 31 Aug 2015 10:23:54 -0500
> From: Rich Goodson 
> To: Harshith Mulky 
> Cc: "bind-users@lists.isc.org" 
> Subject: Re: DNS Negative Caching
> Message-ID: 
> Content-Type: text/plain; charset="windows-1252"
> 
> I have a feeling that the discussion regarding SOA fields didn?t really 
> answer your question, Harshith.
> 
> Yes, negative results (NXDOMAIN) are usually cached for the amount of time 
> specified in the last field of the SOA. This field was originally named 
> ?Minimum?, but is since used for NXDOMAIN TTL.
> 
> The default amount of time that NXDOMAIN answers will be cached on iterative 
> resolvers for the zone shown below is 3 hours.  
> 
> In your lwresd config file, however, you have man-ncache-ttl defined as 300 
> seconds.  I have not used lwresd much, but I know it supports BIND style 
> config files, so I assume that  lwresd will override the value sent by the 
> authoritative server and only cache NXDOMAIN answers for your zone for 5 
> minutes, just like BIND would do, given that same config directive.
> 
> You can test this behavior by doing ?dig? commands against your lightweight 
> resolver to see what TTL it has cached for a particular zone or RR.
> 
> ?Rich
> 
> > On Aug 25, 2015, at 5:46 AM, Harshith Mulky  
> > wrote:
> > 
> > I have a confusion on how the clients respond to and cache when 
> > particularly we receive negative replies from a DNS Server, particularly 
> > NXDOMAIN or SERVFAIL responses
> > 
> > on the DNS Zone file we have these records
> > $ORIGIN e164.arpa.
> > @   IN SOA  picardvm2.e164.arpa. e164-contacts.e164.arpa.  (
> > 2002022404 ; serial
> > 3H ; refresh
> > 15 ; retry
> > 1w ; expire
> > 3h ; minimum
> >)
> > 
> > so 3h is basically the amount of time clients are asked to cache negative 
> > results.
> > 
> > Now on the client side at lwresd.conf, if I have 
> > 
> > max-n

BIND 9.10.2-P3 with GeoIP on Solaris

2015-09-02 Thread greg.rabil
Hi folks,
I am attempting to build BIND 9.10.2-P3 with support for GeoIP on Solaris, but 
I want a statically linked version of the 'named' binary.  On Linux, when I 
build the GeoIP library, I specify the '-disable-shared' configure flag, and 
then when I use the GeoIP install directory as the value for the '-with-geoip' 
when building BIND, all works fine and, as expected, I end up with a 'named' 
binary that is statically linked with the GeoIP library.  However, if I follow 
this process on Solaris, the BIND configure step fails with:

checking GeoIP.h usability... yes
checking GeoIP.h presence... yes
checking for GeoIP.h... yes
checking for library containing GeoIP_open... no
configure: error: GeoIP library not found

If I rebuild GeoIP library without '-disable-shared', then BIND configure and 
make complete successfully, but then I have a runtime dependency on the GeoIP 
library, which I'm trying to avoid.

I am hoping someone on the list has a workaround or other suggestion to 
accomplish this?

Thanks,
Greg
This email contains BT information which may be privileged or confidential. It 
is meant only for the individual(s) or entity named above. If you are not the 
intended recipient, note that disclosing, copying, distributing or using this 
information is prohibited. If you have received this email in error, please let 
me know immediately on the email above. Thank you. We monitor our email system 
and may record your emails.
BT Americas Inc. 415 Eagleview Blvd., Suite 112, Exton, PA 19341
BT Americas Inc. is a wholly owned subsidiary of British Telecommunications plc.

___
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

RHEL, Centos, Fedora rpm 9.10.2-P4

2015-09-02 Thread Carl Byington
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

http://www.five-ten-sg.com/mapper/bind contains links to the source
rpms, and build instructions.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlXnX1cACgkQL6j7milTFsEnfwCcC9nJa9YqAHCKiQbPdggOlZoK
ZqoAnjBmoRpZD8aSM4rT6a+AUejwp6M+
=PAy+
-END PGP 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


Final on - Re: A tale of two nameservers - resolution problems

2015-09-02 Thread Robert Moskowitz

I have learned a bit in the past time period.

First, adding a 2nd DNS server, in this case my ISP's, got around this 
timing problem, becuase the 'right fix' is not available yet.


The answer is to stop using old ntpd and use modern chronyd.  But more 
than that, ver 2.1.1 which is available in Fedora 22, but not (yet) in 
Centos 7 (perhaps 7.2).  You start chrony with the -s option; this tells 
it you have a bad, or no rtc, and to regularly save the time to a file 
which is read when chrony starts up.  I have tested this out on F22 and 
it works as advertised.


There is also systemd-timesync, but Fedora/redhat went the chrony route, 
and I got more help figuring it out.


On to the next fun challenge.

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.

Sam



___
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