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
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
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
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
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
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
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
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
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
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
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
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.
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,
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;
14 matches
Mail list logo
