Re: named validating @0x...: ... SOA: no valid signature found
In message jnrabn$olm$1...@dough.gmane.org, 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
new here
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
attachment: dmilholen.vcf___
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
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
Re: new here
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 dmilho...@wletc.com 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
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
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: Host command timing out sporadically
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 hostname', 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: Host command timing out sporadically
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 'hosthostname', 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
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 http://gmail.com ;; global options: +cmd .501632INNSm.root-servers.net http://m.root-servers.net. .501632INNSc.root-servers.net http://c.root-servers.net. .501632INNSh.root-servers.net http://h.root-servers.net. .501632INNSb.root-servers.net http://b.root-servers.net. .501632INNSe.root-servers.net http://e.root-servers.net. .501632INNSj.root-servers.net http://j.root-servers.net. .501632INNSk.root-servers.net http://k.root-servers.net. .501632INNSg.root-servers.net http://g.root-servers.net. .501632INNSf.root-servers.net http://f.root-servers.net. .501632INNSi.root-servers.net http://i.root-servers.net. .501632INNSl.root-servers.net http://l.root-servers.net. .501632INNSa.root-servers.net http://a.root-servers.net. .501632INNSd.root-servers.net http://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 http://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 'hosthostname', 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 http://example.com If the answer is mail.example.com http://mail.example.com do this: dig mx example.com http://example.com if either fail do this: dig +trace mx example.com http://example.com or dig +trace mail.example.com http://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 mailto: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
In article mailman.655.1335991345.63724.bind-us...@lists.isc.org, Lyle Giese l...@lcrcomputer.net 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 'hosthostname', 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
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 'hosthostname', 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
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
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 http://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 http://gmail.com/ ;; global options: +cmd .501632INNSm.root-servers.net http://m.root-servers.net/. .501632INNSc.root-servers.net http://c.root-servers.net/. .501632INNSh.root-servers.net http://h.root-servers.net/. .501632INNSb.root-servers.net http://b.root-servers.net/. .501632INNSe.root-servers.net http://e.root-servers.net/. .501632INNSj.root-servers.net http://j.root-servers.net/. .501632INNSk.root-servers.net http://k.root-servers.net/. .501632INNSg.root-servers.net http://g.root-servers.net/. .501632INNSf.root-servers.net http://f.root-servers.net/. .501632INNSi.root-servers.net http://i.root-servers.net/. .501632INNSl.root-servers.net http://l.root-servers.net/. .501632INNSa.root-servers.net http://a.root-servers.net/. .501632INNSd.root-servers.net http://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 http://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 'hosthostname', 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 http://example.com/ If the answer is mail.example.com http://mail.example.com/ do this: dig mx example.com http://example.com/ if either fail do this: dig +trace mx example.com http://example.com/ or dig +trace mail.example.com http://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
Re: Host command timing out sporadically
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 'hosthostname', 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.
