Re: Understanding TTL in "rndc dumpdb"-output

2018-10-23 Thread Tom 

Hi Michal
Thank you for this feedback.

I've checked the serve-stale status, which is currently off.
# rndc serve-stale status
_default: off (stale-answer-ttl=1 max-stale-ttl=604800)
_bind: off (stale-answer-ttl=1 max-stale-ttl=604800)

Is this a normal behavior, that in the "rndc dumpdb" nevertheless the 
TTL in the form of "serve-stale" is shown (even if the 
serve-stale-status = off)?


Thank you.
Tom


On 23.10.18 10:25, Michał Kępień wrote:

After querying my resolver for "testbla11.example.com", I receive a NXDOMAIN
response with a minimum-ttl (in the soa) of 3600.
When I afterwards dump the cache of my resolver (9.12.2-P1) with "rndc
dumpdb" and look for the negative ttl, then a value much bigger than 3600 is
shown (608363):
# grep testbla /var/named/data/named_dump.db
testbla11.example.com.  608363  \-ANY   ;-$NXDOMAIN

This number decrements every second.

What is this number? The same behavior for positive answers too. The
A-record for "www.google.com" has a TTL for 300 seconds. In the "rndc
dumpdb"-output I have a value for 605082.


This happens due to the serve-stale feature being available in BIND 9.12
and later, with max-stale-ttl set to 604800 by default (note that this
does *not* mean serving stale answers is enabled by default).  The TTLs
you are seeing in the cache dump essentially indicate how much longer
any given record will be kept in the cache database.  The serve-stale
"offset" is indicated in a comment near the top of the dump; I am fairly
sure it will say "; using a 604800 second stale ttl" in your case.


___
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: Strange DIG behavior on Windows 10: - SOLVED (sorta)

2018-10-23 Thread Timothy Metzinger 
One machine had resolv.conf in ISC BIND 9\etc, the other didn't.

So I suspect that in spite of the release notes about resolv.conf not being 
needed... it really is.  Perhaps it isn't if you install the full BIND service 
but is needed if you only install the tools.

-Original Message-
From: bind-users  On Behalf Of Timothy 
Metzinger
Sent: Tuesday, October 23, 2018 8:13 PM
To: bind-users@lists.isc.org
Subject: RE: Strange DIG behavior on Windows 10:

I see NO outgoing bits on the wire, bolstering my theory that DIG isn't finding 
name servers in the registry.  NSLOOKUP works fine.   There's no difference 
between the working and non working PC in the name servers listed in all the 
interfaces in ifconfig /all.   Registry values for 
HKLM\system\currentcontrolset\services\tcpip\parameters\dhcpnameserver are 
identical.

I've deinstalled and reinstalled BIND.  This is so weird.

-Original Message-
From: bind-users  On Behalf Of Grant Taylor 
via bind-users
Sent: Tuesday, October 23, 2018 6:55 PM
To: bind-users@lists.isc.org
Subject: Re: Strange DIG behavior on Windows 10:

On 10/23/2018 04:21 PM, Timothy Metzinger wrote:
> At this point I'm stumped and welcome any suggestions.

Trust the bits on the wire.

What sort of outgoing DNS queries do you see when you run dig on the 
problematic system without specifying the DNS server?

Can you find that server listed anywhere in the output of ifconfig /all? 
  (I think that's the command, it's been too long.)



--
Grant. . . .
unix || die

___
Please visit 
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users&data=02%7C01%7C%7C96b65a2a3a894aa4c70c08d639458cfd%7C84df9e7fe9f640afb435%7C1%7C0%7C636759368205811310&sdata=Ub1YqLysdo6XTh%2FKN3npPF3rTSNL0JZmaqrRv5vrUQs%3D&reserved=0
 to unsubscribe from this list

bind-users mailing list
bind-users@lists.isc.org
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users&data=02%7C01%7C%7C96b65a2a3a894aa4c70c08d639458cfd%7C84df9e7fe9f640afb435%7C1%7C0%7C636759368205811310&sdata=Ub1YqLysdo6XTh%2FKN3npPF3rTSNL0JZmaqrRv5vrUQs%3D&reserved=0
___
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: Strange DIG behavior on Windows 10:

2018-10-23 Thread Timothy Metzinger 
I see NO outgoing bits on the wire, bolstering my theory that DIG isn't finding 
name servers in the registry.  NSLOOKUP works fine.   There's no difference 
between the working and non working PC in the name servers listed in all the 
interfaces in ifconfig /all.   Registry values for 
HKLM\system\currentcontrolset\services\tcpip\parameters\dhcpnameserver are 
identical.

I've deinstalled and reinstalled BIND.  This is so weird.

-Original Message-
From: bind-users  On Behalf Of Grant Taylor 
via bind-users
Sent: Tuesday, October 23, 2018 6:55 PM
To: bind-users@lists.isc.org
Subject: Re: Strange DIG behavior on Windows 10:

On 10/23/2018 04:21 PM, Timothy Metzinger wrote:
> At this point I'm stumped and welcome any suggestions.

Trust the bits on the wire.

What sort of outgoing DNS queries do you see when you run dig on the 
problematic system without specifying the DNS server?

Can you find that server listed anywhere in the output of ifconfig /all? 
  (I think that's the command, it's been too long.)



--
Grant. . . .
unix || die

___
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: Strange DIG behavior on Windows 10:

2018-10-23 Thread Grant Taylor via bind-users 

On 10/23/2018 04:21 PM, Timothy Metzinger wrote:

At this point I’m stumped and welcome any suggestions.


Trust the bits on the wire.

What sort of outgoing DNS queries do you see when you run dig on the 
problematic system without specifying the DNS server?


Can you find that server listed anywhere in the output of ifconfig /all? 
 (I think that's the command, it's been too long.)




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic 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: Strange DIG behavior on Windows 10:

2018-10-23 Thread Timothy Metzinger 
That's a good Avenue to explore I will see if I can find any differences

Tim Metzinger
703.963.3015


From: bind-users  on behalf of Kevin Darcy 

Sent: Tuesday, October 23, 2018 6:44:52 PM
To: bind-users@lists.isc.org
Subject: Re: Strange DIG behavior on Windows 10:

To be honest, I don't have a lot of experience running dig on Windows, but I 
assume it would use the same resolvers as everything else, in which case 
they're either statically defined (typically through Control Panel) or assigned 
via DHCP.

One thing to consider, though: on Windows, resolvers tend to be assigned 
*per-interface*. It's possible that you have some interface that has assigned 
resolvers that you can't reach (due to firewall rules, routing issues, etc.). 
The resolvers that get chosen may then be dependent on the binding order of the 
interfaces, or other factors. For that matter, you might be trying to use IPv6 
resolvers, even though IPv6 may not be routable from your LAN. Check out 
ipconfig /all.

  - 
Kevin

On Tue, Oct 23, 2018 at 6:22 PM Timothy Metzinger 
mailto:tim.metzin...@outlook.com>> wrote:

I have two windows 10 pro boxes, both with Bind 9.12.3 tools installed.  On one 
machine, entering “dig” by itself gives me back the root server list as 
expected.  On the other machine, I get an error that says no name servers could 
be contacted.

However, if I specify the local name server on that second machine by entering 
dig 
@192.168.1.250,
 I get the root server list.

My logic says that since I can talk to the recursive server, I don’t have a 
firewall issue.  Instead, BIND is not finding the list of name servers (by 
reading the registry)?   I tried putting in a resolv.conf file in 
c:\windows\system32\drivers\etc with contents:

nameserver 192.168.1.250
nameserver 192.168.1.251
nameserver 8.8.8.8

And that made no difference.  Running the command prompt as an administrator 
makes no difference.   At this point I’m stumped and welcome any suggestions.

Timothy Metzinger

___
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
___
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: Strange DIG behavior on Windows 10:

2018-10-23 Thread Kevin Darcy 
To be honest, I don't have a lot of experience running dig on Windows, but
I assume it would use the same resolvers as everything else, in which case
they're either statically defined (typically through Control Panel) or
assigned via DHCP.

One thing to consider, though: on Windows, resolvers tend to be assigned
*per-interface*. It's possible that you have some interface that has
assigned resolvers that you can't reach (due to firewall rules, routing
issues, etc.). The resolvers that get chosen may then be dependent on the
binding order of the interfaces, or other factors. For that matter, you
might be trying to use IPv6 resolvers, even though IPv6 may not be routable
from your LAN. Check out ipconfig /all.


  - Kevin

On Tue, Oct 23, 2018 at 6:22 PM Timothy Metzinger 
wrote:

>
>
> I have two windows 10 pro boxes, both with Bind 9.12.3 tools installed.
> On one machine, entering “dig” by itself gives me back the root server list
> as expected.  On the other machine, I get an error that says no name
> servers could be contacted.
>
>
>
> However, if I specify the local name server on that second machine by
> entering dig @192.168.1.250, I get the root server list.
>
>
>
> My logic says that since I can talk to the recursive server, I don’t have
> a firewall issue.  Instead, BIND is not finding the list of name servers
> (by reading the registry)?   I tried putting in a resolv.conf file in
> c:\windows\system32\drivers\etc with contents:
>
>
>
> nameserver 192.168.1.250
>
> nameserver 192.168.1.251
>
> nameserver 8.8.8.8
>
>
>
> And that made no difference.  Running the command prompt as an
> administrator makes no difference.   At this point I’m stumped and welcome
> any suggestions.
>
>
>
> Timothy Metzinger
>
>
> ___
> 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
>
___
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

Strange DIG behavior on Windows 10:

2018-10-23 Thread Timothy Metzinger 

I have two windows 10 pro boxes, both with Bind 9.12.3 tools installed.  On one 
machine, entering "dig" by itself gives me back the root server list as 
expected.  On the other machine, I get an error that says no name servers could 
be contacted.

However, if I specify the local name server on that second machine by entering 
dig @192.168.1.250, I get the root server list.

My logic says that since I can talk to the recursive server, I don't have a 
firewall issue.  Instead, BIND is not finding the list of name servers (by 
reading the registry)?   I tried putting in a resolv.conf file in 
c:\windows\system32\drivers\etc with contents:

nameserver 192.168.1.250
nameserver 192.168.1.251
nameserver 8.8.8.8

And that made no difference.  Running the command prompt as an administrator 
makes no difference.   At this point I'm stumped and welcome any suggestions.

Timothy Metzinger

___
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: Understanding TTL in "rndc dumpdb"-output

2018-10-23 Thread Michał Kępień 
> After querying my resolver for "testbla11.example.com", I receive a NXDOMAIN
> response with a minimum-ttl (in the soa) of 3600.
> When I afterwards dump the cache of my resolver (9.12.2-P1) with "rndc
> dumpdb" and look for the negative ttl, then a value much bigger than 3600 is
> shown (608363):
> # grep testbla /var/named/data/named_dump.db
> testbla11.example.com.608363  \-ANY   ;-$NXDOMAIN
> 
> This number decrements every second.
> 
> What is this number? The same behavior for positive answers too. The
> A-record for "www.google.com" has a TTL for 300 seconds. In the "rndc
> dumpdb"-output I have a value for 605082.

This happens due to the serve-stale feature being available in BIND 9.12
and later, with max-stale-ttl set to 604800 by default (note that this
does *not* mean serving stale answers is enabled by default).  The TTLs
you are seeing in the cache dump essentially indicate how much longer
any given record will be kept in the cache database.  The serve-stale
"offset" is indicated in a comment near the top of the dump; I am fairly
sure it will say "; using a 604800 second stale ttl" in your case.

-- 
Best regards,
Michał Kępień
___
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