Re: Host command timing out sporadically

[Paul Marais]

I think its fixed... just not sure why...
I removed the 'recursion no' line and its much faster now and not timing out...

I used to have :
recursion no;
allow-query {   any;  };
allow-recursion {  192.168.2.0/24; 127.0.0.1; };
allow-query-cache {   192.168.2.0/24;  127.0.0.1; };

Now I have:
allow-query {   any;  };
allow-recursion {  192.168.2.0/24; 127.0.0.1; };
allow-query-cache {   192.168.2.0/24;  127.0.0.1; };




On May 2, 2012, at 7:24 PM, Lyle Giese wrote:

> If you have recursion turned off, then no it won't forward.  It tells your 
> named that if it doesn't already know the answer, tell the client I don't 
> know and won't ask anyone else.
> 
> But what about the second scenerio below?  You check on scenerio 1, but you 
> have not addressed #2.
> 
> Besides, the recursion setting in named is immaterial when doing dig +trace.  
> Once dig gets the addresses of the root server, it stops asking your local 
> copy of named and starts asking the root servers for itself and does not rely 
> any further on named.
> 
> Lyle
> 
> On 05/02/12 18:59, Paul Marais wrote:
>> 
>> I checked the firewall and I have rules to allow tcp & udp on port 53.
>> Is there anything I can do to get more information on why no connection is 
>> made to the root servers. 
>> 
>> I'm a bit confused.. if I have recursion off shouldn't my local named be 
>> forwarding the request to the name server in my "forwarders" section of the 
>> named options.
>> 
>> 
>> 
>> 
>> On May 2, 2012, at 3:48 PM, Lyle Giese wrote:
>> 
>>> Using dig +trace, dig is trying to accomplish the recursion that named 
>>> would do for you.  This tells us your local copy of named is answering 
>>> requests as that is where you received the list of root servers from.  But 
>>> when dig tries to ask the root name servers how to find gmail.com, dig is 
>>> unable to contact or get an answer from the root name servers.
>>> 
>>> This indicates one of two problems.
>>> 
>>> 1) firewall rules are not permitting both udp and tcp port 53 traffic(which 
>>> I doubt since it works sometimes).
>>> 2) your Internet connection is congested and dropping or delaying your 
>>> traffic to the point, dig gives up trying.
>>> 
>>> But the use of dig +trace shows much more diagnostic information which 
>>> points us to the real issue you have.
>>> 
>>> Lyle Giese
>>> LCR Computer Services, Inc.
>>> 
>>> On 05/02/12 16:36, Paul Marais wrote:
 
 Thanks Lyle,
 You're right - I started using the host command because it was giving me 
 the error I found in the postfix logs... 
 but as I just discovered dig +trace also give me the error...
 
 I am seeing lots of mailed messages to gmail accounts... and when I do a 
 trace I get the following:
 
 ; <<>> DiG 9.7.3 <<>> +trace mx gmail.com
 ;; global options: +cmd
 . 501632 IN NS m.root-servers.net.
 . 501632 IN NS c.root-servers.net.
 . 501632 IN NS h.root-servers.net.
 . 501632 IN NS b.root-servers.net.
 . 501632 IN NS e.root-servers.net.
 . 501632 IN NS j.root-servers.net.
 . 501632 IN NS k.root-servers.net.
 . 501632 IN NS g.root-servers.net.
 . 501632 IN NS f.root-servers.net.
 . 501632 IN NS i.root-servers.net.
 . 501632 IN NS l.root-servers.net.
 . 501632 IN NS a.root-servers.net.
 . 501632 IN NS d.root-servers.net.
 ;; Received 320 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
 
 ;; connection timed out; no servers could be reached
 
 
 If I leave the trace off, I see no error messages... but I get no answer 
 and I do see a warning:
 
 ; <<>> DiG 9.7.3 <<>> mx gmail.com
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32902
 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 5
 ;; WARNING: recursion requested but not available
 
 
 
 
 
 On May 2, 2012, at 1:42 PM, Lyle Giese wrote:
 
> On 05/02/12 12:12, Paul Marais wrote:
>> Hi,
>> I'm having an issue where my postfix server is having trouble with some 
>> lookups.
>> When I type 'host', 80% of the time I get decent reply speed, 
>> but for 20% I get a 5 second delay, or even a timeout.
>> 
>> My nameserver is configured to only allow recursion for hosts on my 
>> local network, and I have my ISP dns in my forwarders.
>> My resolv.conf has 127.0.0.1, my internal ip, and the ip for my isp DNS
>> 
>> Any help will be greatly appreciated.
>> 
>> Thanks
>> Paul
>> 
>> 
> Don't use host.  It's not telling us what is going wrong and it's only 
> doing an A record lookup of host name.
> 
> Postfix does an MX lookup for the domain and then an A record lookup for 
> the mail server(s) in the MX records.
> 
> Learn to use dig.
> 
> Do this:
> 
> dig mx example.com
> 
> If the a

Re: Host command timing out sporadically

[Lyle Giese]

If you have recursion turned off, then no it won't forward.  It tells 
your named that if it doesn't already know the answer, tell the client I 
don't know and won't ask anyone else.


But what about the second scenerio below?  You check on scenerio 1, but 
you have not addressed #2.


Besides, the recursion setting in named is immaterial when doing dig 
+trace.  Once dig gets the addresses of the root server, it stops asking 
your local copy of named and starts asking the root servers for itself 
and does not rely any further on named.


Lyle

On 05/02/12 18:59, Paul Marais wrote:

I checked the firewall and I have rules to allow tcp & udp on port 53.
Is there anything I can do to get more information on why no 
connection is made to the root servers.


I'm a bit confused.. if I have recursion off shouldn't my local named 
be forwarding the request to the name server in my "forwarders" 
section of the named options.





On May 2, 2012, at 3:48 PM, Lyle Giese wrote:

Using dig +trace, dig is trying to accomplish the recursion that 
named would do for you.  This tells us your local copy of named is 
answering requests as that is where you received the list of root 
servers from.  But when dig tries to ask the root name servers how to 
find gmail.com , dig is unable to contact or get an 
answer from the root name servers.


This indicates one of two problems.

1) firewall rules are not permitting both udp and tcp port 53 
traffic(which I doubt since it works sometimes).
2) your Internet connection is congested and dropping or delaying 
your traffic to the point, dig gives up trying.


But the use of dig +trace shows much more diagnostic information 
which points us to the real issue you have.


Lyle Giese
LCR Computer Services, Inc.

On 05/02/12 16:36, Paul Marais wrote:

Thanks Lyle,
You're right - I started using the host command because it was 
giving me the error I found in the postfix logs...

but as I just discovered dig +trace also give me the error...

I am seeing lots of mailed messages to gmail accounts... and when I 
do a trace I get the following:


; <<>> DiG 9.7.3 <<>> +trace mx gmail.com 
;; global options: +cmd
.501632INNSm.root-servers.net .
.501632INNSc.root-servers.net .
.501632INNSh.root-servers.net .
.501632INNSb.root-servers.net .
.501632INNSe.root-servers.net .
.501632INNSj.root-servers.net .
.501632INNSk.root-servers.net .
.501632INNSg.root-servers.net .
.501632INNSf.root-servers.net .
.501632INNSi.root-servers.net .
.501632INNSl.root-servers.net .
.501632INNSa.root-servers.net .
.501632INNSd.root-servers.net .
;; Received 320 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

;; connection timed out; no servers could be reached



If I leave the trace off, I see no error messages... but I get no 
answer and I do see a warning:


; <<>> DiG 9.7.3 <<>> mx gmail.com 
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32902
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 5
;; WARNING: recursion requested but not available





On May 2, 2012, at 1:42 PM, Lyle Giese wrote:


On 05/02/12 12:12, Paul Marais wrote:

Hi,
I'm having an issue where my postfix server is having trouble with 
some lookups.
When I type 'host', 80% of the time I get decent reply 
speed, but for 20% I get a 5 second delay, or even a timeout.


My nameserver is configured to only allow recursion for hosts on 
my local network, and I have my ISP dns in my forwarders.
My resolv.conf has 127.0.0.1, my internal ip, and the ip for my 
isp DNS


Any help will be greatly appreciated.

Thanks
Paul


Don't use host.  It's not telling us what is going wrong and it's 
only doing an A record lookup of host name.


Postfix does an MX lookup for the domain and then an A record 
lookup for the mail server(s) in the MX records.


Learn to use dig.

Do this:

dig mx example.com 

If the answer is mail.example.com  do this:

dig mx example.com 

if either fail do this:

dig +trace mx example.com 
or
dig +trace mail.example.com 

And see if you can catch the failure and then we can do more for 
you.  The other side of this may be that your Internet connection 
is overloaded and you are dropping packets or it's taking too long 
for the query to get out and get the response.


Lyle Giese
LCR Computer Services, Inc.

___
Please vis

Re: Host command timing out sporadically

[btb]

On May 02, 2012, at 18.41, Paul Marais wrote:

> So it looks like I just need to make postfix use a longer timeout perhaps.

or, you could just not use your isp's nameservers, and let bind do what it 
does.  it's unlikely that your isp's nameservers are doing you great favors, if 
any at all.  either way, recursion needs to be allowed for any clients [this 
includes localhost] which expect to be able to look up arbitrary information in 
dns.

-ben
___
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: Host command timing out sporadically

[Paul Marais]

I checked the firewall and I have rules to allow tcp & udp on port 53.
Is there anything I can do to get more information on why no connection is made 
to the root servers. 

I'm a bit confused.. if I have recursion off shouldn't my local named be 
forwarding the request to the name server in my "forwarders" section of the 
named options.




On May 2, 2012, at 3:48 PM, Lyle Giese wrote:

> Using dig +trace, dig is trying to accomplish the recursion that named would 
> do for you.  This tells us your local copy of named is answering requests as 
> that is where you received the list of root servers from.  But when dig tries 
> to ask the root name servers how to find gmail.com, dig is unable to contact 
> or get an answer from the root name servers.
> 
> This indicates one of two problems.
> 
> 1) firewall rules are not permitting both udp and tcp port 53 traffic(which I 
> doubt since it works sometimes).
> 2) your Internet connection is congested and dropping or delaying your 
> traffic to the point, dig gives up trying.
> 
> But the use of dig +trace shows much more diagnostic information which points 
> us to the real issue you have.
> 
> Lyle Giese
> LCR Computer Services, Inc.
> 
> On 05/02/12 16:36, Paul Marais wrote:
>> 
>> Thanks Lyle,
>> You're right - I started using the host command because it was giving me the 
>> error I found in the postfix logs... 
>> but as I just discovered dig +trace also give me the error...
>> 
>> I am seeing lots of mailed messages to gmail accounts... and when I do a 
>> trace I get the following:
>> 
>> ; <<>> DiG 9.7.3 <<>> +trace mx gmail.com
>> ;; global options: +cmd
>> . 501632 IN NS m.root-servers.net.
>> . 501632 IN NS c.root-servers.net.
>> . 501632 IN NS h.root-servers.net.
>> . 501632 IN NS b.root-servers.net.
>> . 501632 IN NS e.root-servers.net.
>> . 501632 IN NS j.root-servers.net.
>> . 501632 IN NS k.root-servers.net.
>> . 501632 IN NS g.root-servers.net.
>> . 501632 IN NS f.root-servers.net.
>> . 501632 IN NS i.root-servers.net.
>> . 501632 IN NS l.root-servers.net.
>> . 501632 IN NS a.root-servers.net.
>> . 501632 IN NS d.root-servers.net.
>> ;; Received 320 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
>> 
>> ;; connection timed out; no servers could be reached
>> 
>> 
>> If I leave the trace off, I see no error messages... but I get no answer and 
>> I do see a warning:
>> 
>> ; <<>> DiG 9.7.3 <<>> mx gmail.com
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32902
>> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 5
>> ;; WARNING: recursion requested but not available
>> 
>> 
>> 
>> 
>> 
>> On May 2, 2012, at 1:42 PM, Lyle Giese wrote:
>> 
>>> On 05/02/12 12:12, Paul Marais wrote:
 Hi,
 I'm having an issue where my postfix server is having trouble with some 
 lookups.
 When I type 'host', 80% of the time I get decent reply speed, 
 but for 20% I get a 5 second delay, or even a timeout.
 
 My nameserver is configured to only allow recursion for hosts on my local 
 network, and I have my ISP dns in my forwarders.
 My resolv.conf has 127.0.0.1, my internal ip, and the ip for my isp DNS
 
 Any help will be greatly appreciated.
 
 Thanks
 Paul
 
 
>>> Don't use host.  It's not telling us what is going wrong and it's only 
>>> doing an A record lookup of host name.
>>> 
>>> Postfix does an MX lookup for the domain and then an A record lookup for 
>>> the mail server(s) in the MX records.
>>> 
>>> Learn to use dig.
>>> 
>>> Do this:
>>> 
>>> dig mx example.com
>>> 
>>> If the answer is mail.example.com do this:
>>> 
>>> dig mx example.com
>>> 
>>> if either fail do this:
>>> 
>>> dig +trace mx example.com
>>> or
>>> dig +trace mail.example.com
>>> 
>>> And see if you can catch the failure and then we can do more for you.  The 
>>> other side of this may be that your Internet connection is overloaded and 
>>> you are dropping packets or it's taking too long for the query to get out 
>>> and get the response.
>>> 
>>> Lyle Giese
>>> LCR Computer Services, Inc.
>>> 
>>> ___
>>> 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

___
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: Host command timing out sporadically

[Barry Margolin]

In article ,
 Lyle Giese  wrote:

> On 05/02/12 12:12, Paul Marais wrote:
> > Hi,
> > I'm having an issue where my postfix server is having trouble with some 
> > lookups.
> > When I type 'host', 80% of the time I get decent reply speed, but 
> > for 20% I get a 5 second delay, or even a timeout.
> >
> > My nameserver is configured to only allow recursion for hosts on my local 
> > network, and I have my ISP dns in my forwarders.
> > My resolv.conf has 127.0.0.1, my internal ip, and the ip for my isp DNS
> >
> > Any help will be greatly appreciated.
> >
> > Thanks
> > Paul
> >
> >
> Don't use host.  It's not telling us what is going wrong and it's only 
> doing an A record lookup of host name.

I thought host does an A, , and MX lookup of host names by default; 
when given an IP, it converts it to the corresponding IN-ADDR.ARPA name 
and does a PTR lookup.  Does it also have a similar heuristic for IPv6 
addresses?

-- 
Barry Margolin
Arlington, MA
___
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: Host command timing out sporadically

[Lyle Giese]

Using dig +trace, dig is trying to accomplish the recursion that named 
would do for you.  This tells us your local copy of named is answering 
requests as that is where you received the list of root servers from.  
But when dig tries to ask the root name servers how to find gmail.com, 
dig is unable to contact or get an answer from the root name servers.


This indicates one of two problems.

1) firewall rules are not permitting both udp and tcp port 53 
traffic(which I doubt since it works sometimes).
2) your Internet connection is congested and dropping or delaying your 
traffic to the point, dig gives up trying.


But the use of dig +trace shows much more diagnostic information which 
points us to the real issue you have.


Lyle Giese
LCR Computer Services, Inc.

On 05/02/12 16:36, Paul Marais wrote:

Thanks Lyle,
You're right - I started using the host command because it was giving 
me the error I found in the postfix logs...

but as I just discovered dig +trace also give me the error...

I am seeing lots of mailed messages to gmail accounts... and when I do 
a trace I get the following:


; <<>> DiG 9.7.3 <<>> +trace mx gmail.com 
;; global options: +cmd
.501632INNSm.root-servers.net .
.501632INNSc.root-servers.net .
.501632INNSh.root-servers.net .
.501632INNSb.root-servers.net .
.501632INNSe.root-servers.net .
.501632INNSj.root-servers.net .
.501632INNSk.root-servers.net .
.501632INNSg.root-servers.net .
.501632INNSf.root-servers.net .
.501632INNSi.root-servers.net .
.501632INNSl.root-servers.net .
.501632INNSa.root-servers.net .
.501632INNSd.root-servers.net .
;; Received 320 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

;; connection timed out; no servers could be reached



If I leave the trace off, I see no error messages... but I get no 
answer and I do see a warning:


; <<>> DiG 9.7.3 <<>> mx gmail.com 
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32902
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 5
;; WARNING: recursion requested but not available





On May 2, 2012, at 1:42 PM, Lyle Giese wrote:


On 05/02/12 12:12, Paul Marais wrote:

Hi,
I'm having an issue where my postfix server is having trouble with 
some lookups.
When I type 'host', 80% of the time I get decent reply 
speed, but for 20% I get a 5 second delay, or even a timeout.


My nameserver is configured to only allow recursion for hosts on my 
local network, and I have my ISP dns in my forwarders.

My resolv.conf has 127.0.0.1, my internal ip, and the ip for my isp DNS

Any help will be greatly appreciated.

Thanks
Paul


Don't use host.  It's not telling us what is going wrong and it's 
only doing an A record lookup of host name.


Postfix does an MX lookup for the domain and then an A record lookup 
for the mail server(s) in the MX records.


Learn to use dig.

Do this:

dig mx example.com 

If the answer is mail.example.com  do this:

dig mx example.com 

if either fail do this:

dig +trace mx example.com 
or
dig +trace mail.example.com 

And see if you can catch the failure and then we can do more for you. 
 The other side of this may be that your Internet connection is 
overloaded and you are dropping packets or it's taking too long for 
the query to get out and get the response.


Lyle Giese
LCR Computer Services, Inc.

___
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: Host command timing out sporadically

[Paul Marais]

So I discovered that if I just do: dig gmail.com I get no answers... but thats 
most likely because my NS is set to not allow recursion... what I didn't 
realize is that dig was not forwarding the request to my isp's NS.

When force the lookup on my isp's NS ie: dig @206.168.216.6 mx gmail.com, I get 
replies... and every 5 to 10 replies, there are one or 2 lookups that take a 
few seconds, and I think its these slower replies that postfix is timing out on.

If I do the same lookups on my home computer I experience the same delay every 
5-10 lookups... so Im thinking my ISP's NS is just a little bogged down... and 
when postfix does a lookup at the same time... it gives up because the lookup 
takes too long and logs it as host not found... even though the NS finds it... 
postfix gave up before the reply came back.

So it looks like I just need to make postfix use a longer timeout perhaps.


On May 2, 2012, at 1:42 PM, Lyle Giese wrote:

> On 05/02/12 12:12, Paul Marais wrote:
>> Hi,
>> I'm having an issue where my postfix server is having trouble with some 
>> lookups.
>> When I type 'host', 80% of the time I get decent reply speed, but 
>> for 20% I get a 5 second delay, or even a timeout.
>> 
>> My nameserver is configured to only allow recursion for hosts on my local 
>> network, and I have my ISP dns in my forwarders.
>> My resolv.conf has 127.0.0.1, my internal ip, and the ip for my isp DNS
>> 
>> Any help will be greatly appreciated.
>> 
>> Thanks
>> Paul
>> 
>> 
> Don't use host.  It's not telling us what is going wrong and it's only doing 
> an A record lookup of host name.
> 
> Postfix does an MX lookup for the domain and then an A record lookup for the 
> mail server(s) in the MX records.
> 
> Learn to use dig.
> 
> Do this:
> 
> dig mx example.com
> 
> If the answer is mail.example.com do this:
> 
> dig mx example.com
> 
> if either fail do this:
> 
> dig +trace mx example.com
> or
> dig +trace mail.example.com
> 
> And see if you can catch the failure and then we can do more for you.  The 
> other side of this may be that your Internet connection is overloaded and you 
> are dropping packets or it's taking too long for the query to get out and get 
> the response.
> 
> Lyle Giese
> LCR Computer Services, Inc.
> 
> ___
> 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: Host command timing out sporadically

[Paul Marais]

Thanks Lyle,
You're right - I started using the host command because it was giving me the 
error I found in the postfix logs... 
but as I just discovered dig +trace also give me the error...

I am seeing lots of mailed messages to gmail accounts... and when I do a trace 
I get the following:

; <<>> DiG 9.7.3 <<>> +trace mx gmail.com
;; global options: +cmd
.   501632  IN  NS  m.root-servers.net.
.   501632  IN  NS  c.root-servers.net.
.   501632  IN  NS  h.root-servers.net.
.   501632  IN  NS  b.root-servers.net.
.   501632  IN  NS  e.root-servers.net.
.   501632  IN  NS  j.root-servers.net.
.   501632  IN  NS  k.root-servers.net.
.   501632  IN  NS  g.root-servers.net.
.   501632  IN  NS  f.root-servers.net.
.   501632  IN  NS  i.root-servers.net.
.   501632  IN  NS  l.root-servers.net.
.   501632  IN  NS  a.root-servers.net.
.   501632  IN  NS  d.root-servers.net.
;; Received 320 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

;; connection timed out; no servers could be reached


If I leave the trace off, I see no error messages... but I get no answer and I 
do see a warning:

; <<>> DiG 9.7.3 <<>> mx gmail.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32902
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 5
;; WARNING: recursion requested but not available





On May 2, 2012, at 1:42 PM, Lyle Giese wrote:

> On 05/02/12 12:12, Paul Marais wrote:
>> Hi,
>> I'm having an issue where my postfix server is having trouble with some 
>> lookups.
>> When I type 'host', 80% of the time I get decent reply speed, but 
>> for 20% I get a 5 second delay, or even a timeout.
>> 
>> My nameserver is configured to only allow recursion for hosts on my local 
>> network, and I have my ISP dns in my forwarders.
>> My resolv.conf has 127.0.0.1, my internal ip, and the ip for my isp DNS
>> 
>> Any help will be greatly appreciated.
>> 
>> Thanks
>> Paul
>> 
>> 
> Don't use host.  It's not telling us what is going wrong and it's only doing 
> an A record lookup of host name.
> 
> Postfix does an MX lookup for the domain and then an A record lookup for the 
> mail server(s) in the MX records.
> 
> Learn to use dig.
> 
> Do this:
> 
> dig mx example.com
> 
> If the answer is mail.example.com do this:
> 
> dig mx example.com
> 
> if either fail do this:
> 
> dig +trace mx example.com
> or
> dig +trace mail.example.com
> 
> And see if you can catch the failure and then we can do more for you.  The 
> other side of this may be that your Internet connection is overloaded and you 
> are dropping packets or it's taking too long for the query to get out and get 
> the response.
> 
> Lyle Giese
> LCR Computer Services, Inc.
> 
> ___
> 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: Host command timing out sporadically

[Lyle Giese]

On 05/02/12 12:12, Paul Marais wrote:

Hi,
I'm having an issue where my postfix server is having trouble with some lookups.
When I type 'host', 80% of the time I get decent reply speed, but for 
20% I get a 5 second delay, or even a timeout.

My nameserver is configured to only allow recursion for hosts on my local 
network, and I have my ISP dns in my forwarders.
My resolv.conf has 127.0.0.1, my internal ip, and the ip for my isp DNS

Any help will be greatly appreciated.

Thanks
Paul


Don't use host.  It's not telling us what is going wrong and it's only 
doing an A record lookup of host name.


Postfix does an MX lookup for the domain and then an A record lookup for 
the mail server(s) in the MX records.


Learn to use dig.

Do this:

dig mx example.com

If the answer is mail.example.com do this:

dig mx example.com

if either fail do this:

dig +trace mx example.com
or
dig +trace mail.example.com

And see if you can catch the failure and then we can do more for you.  
The other side of this may be that your Internet connection is 
overloaded and you are dropping packets or it's taking too long for the 
query to get out and get the response.


Lyle Giese
LCR Computer Services, Inc.

___
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: Host command timing out sporadically

[Jeremy C. Reed]

On Wed, 2 May 2012, Paul Marais wrote:

> I'm having an issue where my postfix server is having trouble with some 
> lookups.
> When I type 'host ', 80% of the time I get decent reply speed, but 
> for 20% I get a 5 second delay, or even a timeout.
> 
> My nameserver is configured to only allow recursion for hosts on my local 
> network, and I have my ISP dns in my forwarders.
> My resolv.conf has 127.0.0.1, my internal ip, and the ip for my isp DNS
> 
> Any help will be greatly appreciated.

You may want to give us some specific examples. 
___
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: new here

[btb]

On May 02, 2012, at 14.41, David wrote:

> so far they are telling me that their systems require the forwards.
> I think they have it backwards..

please keep replies on the list.

yes, it certainly seems so.  if you indeed have been assigned a /22 and a /23, 
then a number of things should happen [all of which are quite routine]-  the 
address space should be swip'd to you, as per iana's policies, and the arpa 
zones which accompany said address space should be delegated to you.  if there 
is some compelling reason to not follow this long established convention, i'd 
ask your provider to explain themselves.

-ben

___
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: new here

[john]

Hi David,

I think first your ISP needs to fix there delegation. If we look at
their chain we see
dig ns 16.98.in-addr.arpa +short
ns2-auth.windstream.net.
ns1-auth.windstream.net.
ns4-auth.windstream.net.
ns3-auth.windstream.net.

however the authoritive server has a different set

dig ns 16.98.in-addr.arpa +short @ns1-auth.windstream.net.
padnsauth02.admin.windstream.net.
nednsauth02.admin.windstream.net.
padnsauth01.admin.windstream.net.
nednspri01.admin.windstream.net.
nednsauth01.admin.windstream.net.

Unfortunately querying for any of the above gives a Serve Fail
dig ns 16.98.in-addr.arpa +short @ns1-auth.windstream.net. | while read
line ; do dig $line ; done | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53909
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43623
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53120
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37551
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6656

This appears to be caused by a refuse at the windstream.net domain
dig nednsauth01.admin.windstream.net. @NS1-AUTH.WINDSTREAM.NET.

; <<>> DiG 9.7.3-P3 <<>> ns nednsauth01.admin.windstream.net.
@NS1-AUTH.WINDSTREAM.NET.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 403
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

This is probably caused because admin.windstream.net. is in an internal
view[1].  You ISP Needs to fix there in zone nsset to point to the
external addresses.  the ones referred to by the parent are all
authoritative so they should probably be using them

dig ns 16.98.in-addr.arpa +short  | while read line ; do dig soa
16.98.in-addr.arpa @$line ; done | grep flags
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0



On 5/2/12 7:01 PM, David wrote:
> Here is what they show on their logs:
> 
> 01-May-2012 09:07:30.868 transfer of '104-22.16.98.in-addr.arpa/IN' from
> 98.16.104.14#53: connected using 207.91.5.70#40513
> 01-May-2012 09:07:30.971 transfer of '104-22.16.98.in-addr.arpa/IN' from
> 98.16.104.14#53: failed while receiving responses: NOTAUTH
> 01-May-2012 09:07:30.971 transfer of '104-22.16.98.in-addr.arpa/IN' from
> 98.16.104.14#53: end of transfer
After this its hard to guess what they are doing internally.  It looks
like they want you to set up a domain of 104-22.16.98.in-addr.arpa.
Which they will transfer from you.  After the transfer they would need
to merge the zone into the parent.  RFC 2317 style delegations dose not
work for netblocks larger the a /25.  Although i would guess from the
below that they are, as ben suggested, trying to do this.

dig ns 104-22.16.98.in-addr.arpa @NS1-AUTH.WINDSTREAM.NET.

; <<>> DiG 9.7.3-P3 <<>> ns 104-22.16.98.in-addr.arpa
@NS1-AUTH.WINDSTREAM.NET.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18018

dig ns 104.16.98.in-addr.arpa @NS1-AUTH.WINDSTREAM.NET.

; <<>> DiG 9.7.3-P3 <<>> ns 104.16.98.in-addr.arpa @NS1-AUTH.WINDSTREAM.NET.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4761
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

Unfortunatly before you can continue to trouble shoot this you would
need to get your ISP to fix their stuff.  You should also ask what they
are trying to do in requesting a transfer of 104-22.16.98.in-addr.arpa
from you, instead of just delegating all of the /24 blocks to your servers.

regards
john

[1]also suggested as we get Refused for the following
dig  NS admin.windstream.net. @NS1-AUTH.WINDSTREAM.NET.

___
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: new here

[Ben Croswell]

Allow-transfer is not the same as forwarding.

Are they wanting to secondary from you?

If so you need to ensure they can do queries against your master for the
zones so they can request soa to check the serial number.

Also it appears they are trying to xfer the cidr block with a different
name than you are loading it as.
You load 104.16.98.in-addr.arpa. they are transferring
104-22.16.98.in-addr.arpa.
-Ben Croswell
On May 2, 2012 1:18 PM, "David"  wrote:

> **
> Hello All,
>  I am new here but have been watching the list for a while.
> I run a small WISP and we have just moved to a new carrier.
> They have provided us with a cdir ipv4 block of /22 and a /23.
> I am trying to get my reverse DNS working correctly but they will not point
> their servers to my authoritative servers to tell these blocks where to
> find
> their reverse. They told me to place forwards in my servers which I have
> done.
>
> FYI: I am running Bind 9 latest stable on my systems not sure what the
> carrier is running.
>
> Here is what they show on their logs:
>
> 01-May-2012 09:07:30.868 transfer of '104-22.16.98.in-addr.arpa/IN' from
> 98.16.104.14#53: connected using 207.91.5.70#40513
> 01-May-2012 09:07:30.971 transfer of '104-22.16.98.in-addr.arpa/IN' from
> 98.16.104.14#53: failed while receiving responses: NOTAUTH
> 01-May-2012 09:07:30.971 transfer of '104-22.16.98.in-addr.arpa/IN' from
> 98.16.104.14#53: end of transfer
>
> Here is what My logs show:
>
>  02-May-2012 15:28:29.979 security: client 162.40.117.250#6483: query
> (cache) '104-22.16.98.in-addr.arpa/SOA/IN' denied
> 02-May-2012 15:28:30.133 xfer-out: client 162.40.117.250#43378: bad zone
> transfer request: '104-22.16.98.in-addr.arpa/IN': non-authoritative zone
> (NOTAUTH)
>
> Here is what the named.conf zone looks like
>
> zone "104.16.98.in-addr.arpa" {
> type master;
> file "/var/named/98.16.104.rev";
> allow-transfer {
> 166.102.165.15;
> 162.39.164.14;
> 207.91.5.70;
> 162.40.117.250;
> };
> I placed the forwarders to allow transfer on this zone but I think the
> zone name is no good.
>
> Thanks
> Dave
>
>
> ___
> 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: new here

[btb]

On 2012.05.02 13.01, David wrote:

Hello All,
  I am new here but have been watching the list for a while.
I run a small WISP and we have just moved to a new carrier.
They have provided us with a cdir ipv4 block of /22 and a /23.
I am trying to get my reverse DNS working correctly but they will not point
their servers to my authoritative servers to tell these blocks where to
find
their reverse. They told me to place forwards in my servers which I have
done.


this all seems terribly and unnecessarily convoluted.  the 6 arpa zones 
for this address space should simply be delegated to your nameservers. 
you are saying that your provider will not do this?



FYI: I am running Bind 9 latest stable on my systems not sure what the
carrier is running.

Here is what they show on their logs:

01-May-2012 09:07:30.868 transfer of '104-22.16.98.in-addr.arpa/IN' from
98.16.104.14#53: connected using 207.91.5.70#40513
01-May-2012 09:07:30.971 transfer of '104-22.16.98.in-addr.arpa/IN' from
98.16.104.14#53: failed while receiving responses: NOTAUTH
01-May-2012 09:07:30.971 transfer of '104-22.16.98.in-addr.arpa/IN' from
98.16.104.14#53: end of transfer


they appear to be attempting classless arpa delegation, but with net 
blocks larger than /24.  this seems odd to me.



Here is what My logs show:

02-May-2012 15:28:29.979 security: client 162.40.117.250#6483: query
(cache) '104-22.16.98.in-addr.arpa/SOA/IN' denied
02-May-2012 15:28:30.133 xfer-out: client 162.40.117.250#43378: bad zone
transfer request: '104-22.16.98.in-addr.arpa/IN': non-authoritative zone
(NOTAUTH)

Here is what the named.conf zone looks like

zone "104.16.98.in-addr.arpa" {
 type master;
 file "/var/named/98.16.104.rev";
 allow-transfer {
 166.102.165.15;
 162.39.164.14;
 207.91.5.70;
 162.40.117.250;
 };


they want you to have a zone named "104-22.16.98.in-addr.arpa", yet you 
have instead proclaimed a zone named "104.16.98.in-addr.arpa".  why they 
want this, though, is a mystery to me.



I placed the forwarders to allow transfer on this zone but I think the
zone name is no good.


i'm not sure what they're/you're referring to with forwarders here, but 
it's not really relevant given the context so far.


-ben
___
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

Host command timing out sporadically

[Paul Marais]

Hi,
I'm having an issue where my postfix server is having trouble with some lookups.
When I type 'host ', 80% of the time I get decent reply speed, but 
for 20% I get a 5 second delay, or even a timeout.

My nameserver is configured to only allow recursion for hosts on my local 
network, and I have my ISP dns in my forwarders.
My resolv.conf has 127.0.0.1, my internal ip, and the ip for my isp DNS

Any help will be greatly appreciated.

Thanks
Paul

___
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

new here

[David]

Hello All,
 I am new here but have been watching the list for a while.
I run a small WISP and we have just moved to a new carrier.
They have provided us with a cdir ipv4 block of /22 and a /23.
I am trying to get my reverse DNS working correctly but they will not point
their servers to my authoritative servers to tell these blocks where to 
find
their reverse. They told me to place forwards in my servers which I have 
done.


FYI: I am running Bind 9 latest stable on my systems not sure what the 
carrier is running.


Here is what they show on their logs:

01-May-2012 09:07:30.868 transfer of '104-22.16.98.in-addr.arpa/IN' from 
98.16.104.14#53: connected using 207.91.5.70#40513
01-May-2012 09:07:30.971 transfer of '104-22.16.98.in-addr.arpa/IN' from 
98.16.104.14#53: failed while receiving responses: NOTAUTH
01-May-2012 09:07:30.971 transfer of '104-22.16.98.in-addr.arpa/IN' from 
98.16.104.14#53: end of transfer


Here is what My logs show:

02-May-2012 15:28:29.979 security: client 162.40.117.250#6483: query 
(cache) '104-22.16.98.in-addr.arpa/SOA/IN' denied
02-May-2012 15:28:30.133 xfer-out: client 162.40.117.250#43378: bad zone 
transfer request: '104-22.16.98.in-addr.arpa/IN': non-authoritative zone 
(NOTAUTH)


Here is what the named.conf zone looks like

zone "104.16.98.in-addr.arpa" {
type master;
file "/var/named/98.16.104.rev";
allow-transfer {
166.102.165.15;
162.39.164.14;
207.91.5.70;
162.40.117.250;
};
I placed the forwarders to allow transfer on this zone but I think the 
zone name is no good.


Thanks
Dave

<>___
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: named validating @0x...: ... SOA: no valid signature found

[Mark Andrews]

In message , "Brian J. Murrell" writes:
> Not having dipped my toe into DNSSEC yet (yes, I know, but time is
> always so scarce)...
> 
> So I am seeing a bunch of this sort of thing in my BIND logs now:
> 
> 04:02:18 named validating @0xb0f58988: 124.in-addr.arpa SOA: no valid sig=
> nature found
> 04:02:18 named validating @0xb0f58988: 124.in-addr.arpa NSEC: no valid si=
> gnature found
> 04:02:18 named validating @0xb0f58988: 227.124.in-addr.arpa NSEC: no vali=
> d signature found
> 04:03:30 named validating @0xb0f58988: net SOA: no valid signature found
> 04:03:30 named validating @0xb0f58988: a1rt98bs5qgc9nfi51s9hci47uljg6jh.n=
> et NSEC3: no valid signature found
> 04:03:30 named validating @0xb0f58988: 5VI63OJ105LD6R767I45IDJR5Q55T1R1.n=
> et NSEC3: no valid signature found
> 04:03:30 named validating @0xb0f58988: EEE0K4ONQCCHCJQTQ5VJD52NKJTEHAJN.n=
> et NSEC3: no valid signature found
> 04:03:30 named validating @0xb0f4d8c0: uk SOA: no valid signature found
> 04:03:30 named validating @0xb21ea7c0: u1fmklfv3rdcnamdc64sekgcdp05bbiu.u=
> k NSEC3: no valid signature found
> 04:03:30 named validating @0xb0f67990: pl SOA: no valid signature found
> 04:03:30 named validating @0xb18914a0: RVLFSE0643QVHS3RI8VPKGANFBCJVJ06.p=
> l NSEC3: no valid signature found
> 04:03:31 named validating @0xb0f949d0: GSV9U2BOSCL9B9TQAL1UAV4BNVI9EVUE.p=
> l NSEC3: no valid signature found
> 04:03:31 named validating @0xb21cc520: org SOA: no valid signature found
> 04:03:31 named validating @0xb18f2c08: org SOA: no valid signature found
> 04:03:31 named validating @0xb21ea7c0: fk47636n6psb8mv7rdu6tpdhas69cbjp.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb0fe6528: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb0f61960: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb21cc520: 4rkhv4s4situ82j70sp5tq5utm12o2t8.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb18f2c08: ic8a82pge1m0qdob5sce1e3613hqr7br.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb0f949d0: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb0f949d0: vai6s58iqmjmin7ju8mq61aju3q4ms5h.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb0f949d0: org SOA: no valid signature found
> 04:03:31 named validating @0xb18914a0: vai6s58iqmjmin7ju8mq61aju3q4ms5h.o=
> rg NSEC3: no valid signature found
> 04:03:31 named validating @0xb21e1518: vai6s58iqmjmin7ju8mq61aju3q4ms5h.o=
> rg NSEC3: no valid signature found
> 04:09:43 named validating @0xb0f58988: 117.in-addr.arpa SOA: no valid sig=
> nature found
> 04:09:43 named validating @0xb0f58988: 117.in-addr.arpa NSEC: no valid si=
> gnature found
> 04:09:43 named validating @0xb0f58988: 240.117.in-addr.arpa NSEC: no vali=
> d signature found
> 04:13:52 named validating @0xb0f58988: 27.in-addr.arpa SOA: no valid sign=
> ature found
> 04:13:52 named validating @0xb0f58988: 22.115.27.in-addr.arpa NSEC: no va=
> lid signature found
> 04:13:52 named validating @0xb0f58988: 99.114.27.in-addr.arpa NSEC: no va=
> lid signature found
> 04:15:16 named validating @0xb0f58988: 117.in-addr.arpa SOA: no valid sig=
> nature found
> 04:15:16 named validating @0xb0f58988: 117.in-addr.arpa NSEC: no valid si=
> gnature found
> 04:15:16 named validating @0xb0f58988: 99.20.117.in-addr.arpa NSEC: no va=
> lid signature found
> 04:15:48 named validating @0xb0f58988: org SOA: no valid signature found
> 04:15:48 named validating @0xb0f58988: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.o=
> rg NSEC3: no valid signature found
> 04:15:48 named validating @0xb0f58988: osfek8jf3dv7trcfcuheumjh9bpmjkeq.o=
> rg NSEC3: no valid signature found
> 04:15:48 named validating @0xb0f58988: vai6s58iqmjmin7ju8mq61aju3q4ms5h.o=
> rg NSEC3: no valid signature found
> 
> And am wondering what they are really telling me.  Are they all
> different flavours of "zone is not signed" or are they more like
> "zone is supposed to be signed but there are problems with it"?
> 
> Cheers,
> b.

The zones are signed.  Possible reason are:

* a firewall blocking EDNS queries.
* using a non DNSSEC enabled forwarder so you don't get signatures.
* a firewall blocking fragmented UDP and named falling back to
  plain DNS.
* other packet loss causing named to fallback to plain DNS.

Mark
-- 
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

named validating @0x...: ... SOA: no valid signature found

[Brian J. Murrell]

Not having dipped my toe into DNSSEC yet (yes, I know, but time is
always so scarce)...

So I am seeing a bunch of this sort of thing in my BIND logs now:

04:02:18 named validating @0xb0f58988: 124.in-addr.arpa SOA: no valid signature 
found
04:02:18 named validating @0xb0f58988: 124.in-addr.arpa NSEC: no valid 
signature found
04:02:18 named validating @0xb0f58988: 227.124.in-addr.arpa NSEC: no valid 
signature found
04:03:30 named validating @0xb0f58988: net SOA: no valid signature found
04:03:30 named validating @0xb0f58988: a1rt98bs5qgc9nfi51s9hci47uljg6jh.net 
NSEC3: no valid signature found
04:03:30 named validating @0xb0f58988: 5VI63OJ105LD6R767I45IDJR5Q55T1R1.net 
NSEC3: no valid signature found
04:03:30 named validating @0xb0f58988: EEE0K4ONQCCHCJQTQ5VJD52NKJTEHAJN.net 
NSEC3: no valid signature found
04:03:30 named validating @0xb0f4d8c0: uk SOA: no valid signature found
04:03:30 named validating @0xb21ea7c0: u1fmklfv3rdcnamdc64sekgcdp05bbiu.uk 
NSEC3: no valid signature found
04:03:30 named validating @0xb0f67990: pl SOA: no valid signature found
04:03:30 named validating @0xb18914a0: RVLFSE0643QVHS3RI8VPKGANFBCJVJ06.pl 
NSEC3: no valid signature found
04:03:31 named validating @0xb0f949d0: GSV9U2BOSCL9B9TQAL1UAV4BNVI9EVUE.pl 
NSEC3: no valid signature found
04:03:31 named validating @0xb21cc520: org SOA: no valid signature found
04:03:31 named validating @0xb18f2c08: org SOA: no valid signature found
04:03:31 named validating @0xb21ea7c0: fk47636n6psb8mv7rdu6tpdhas69cbjp.org 
NSEC3: no valid signature found
04:03:31 named validating @0xb0fe6528: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org 
NSEC3: no valid signature found
04:03:31 named validating @0xb0f61960: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org 
NSEC3: no valid signature found
04:03:31 named validating @0xb21cc520: 4rkhv4s4situ82j70sp5tq5utm12o2t8.org 
NSEC3: no valid signature found
04:03:31 named validating @0xb18f2c08: ic8a82pge1m0qdob5sce1e3613hqr7br.org 
NSEC3: no valid signature found
04:03:31 named validating @0xb0f949d0: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org 
NSEC3: no valid signature found
04:03:31 named validating @0xb0f949d0: vai6s58iqmjmin7ju8mq61aju3q4ms5h.org 
NSEC3: no valid signature found
04:03:31 named validating @0xb0f949d0: org SOA: no valid signature found
04:03:31 named validating @0xb18914a0: vai6s58iqmjmin7ju8mq61aju3q4ms5h.org 
NSEC3: no valid signature found
04:03:31 named validating @0xb21e1518: vai6s58iqmjmin7ju8mq61aju3q4ms5h.org 
NSEC3: no valid signature found
04:09:43 named validating @0xb0f58988: 117.in-addr.arpa SOA: no valid signature 
found
04:09:43 named validating @0xb0f58988: 117.in-addr.arpa NSEC: no valid 
signature found
04:09:43 named validating @0xb0f58988: 240.117.in-addr.arpa NSEC: no valid 
signature found
04:13:52 named validating @0xb0f58988: 27.in-addr.arpa SOA: no valid signature 
found
04:13:52 named validating @0xb0f58988: 22.115.27.in-addr.arpa NSEC: no valid 
signature found
04:13:52 named validating @0xb0f58988: 99.114.27.in-addr.arpa NSEC: no valid 
signature found
04:15:16 named validating @0xb0f58988: 117.in-addr.arpa SOA: no valid signature 
found
04:15:16 named validating @0xb0f58988: 117.in-addr.arpa NSEC: no valid 
signature found
04:15:16 named validating @0xb0f58988: 99.20.117.in-addr.arpa NSEC: no valid 
signature found
04:15:48 named validating @0xb0f58988: org SOA: no valid signature found
04:15:48 named validating @0xb0f58988: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org 
NSEC3: no valid signature found
04:15:48 named validating @0xb0f58988: osfek8jf3dv7trcfcuheumjh9bpmjkeq.org 
NSEC3: no valid signature found
04:15:48 named validating @0xb0f58988: vai6s58iqmjmin7ju8mq61aju3q4ms5h.org 
NSEC3: no valid signature found

And am wondering what they are really telling me.  Are they all
different flavours of "zone is not signed" or are they more like
"zone is supposed to be signed but there are problems with it"?

Cheers,
b.



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