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
new here
I am a Wisp admin and I have just configured a couple of new Bind9 servers.
They will resolve using dig google.com @9x.1xx.104.14
I am having some trouble getting them to answer themselves on 127.0.0.1
for example:
[root@ns4 named]# dig google.com @127.0.0.1 +trace
; DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5 google.com @127.0.0.1 +trace
;; global options: printcmd
;; connection timed out; no servers could be reached
[root@ns4 named]#
Here is an my config:
//
// named.conf for Red Hat caching-nameserver
//
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; rndc-key; };
};
options {
directory /var/named;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
version Surely you must be joking;
notify yes;
allow-recursion {
127.0.0.1;
9x.1xx.104.0/22;
9x.1xx.108.0/23;
};
allow-transfer { 9x.1xx.104.22;
};
listen-on {
9x.1xx.104.14;
};
};
//
logging {
channel my_syslog {
syslog kern;
severity debug;
};
channel my_file {
file /var/named/chroot/var/named/log.msgs;
severity dynamic;
print-category yes;
};
category unmatched {
null;
};
category queries {
my_file;
};
category lame-servers {
null;
};
category general {
default_syslog;
};
};
// a caching only nameserver config
//
zone . IN {
type hint;
file root.servers;
};
zone 104.1xx.9x.in-addr.arpa {
type master;
file /var/named/9x.1xx.104.rev;
allow-transfer {
9x.1xx.104.22;
};
};
zone 0.0.127.in-addr.arpa {
type master;
file /var/named/127.0.0.rev;
};
zone localdomain {
type master;
file /var/named/localdomain.hosts;
};
zone localhost {
type master;
file /var/named/localhost.hosts;
};
key rndc-key {
algorithm hmac-md5;
secret wh6DFiuNGJHzHwvNTy8JEA==;
};
Here is my resolv.conf :
nameserver 127.0.0.1
nameserver 9x.1xx.104.14
Not sure what I broke but it seems to work on some of my older servers.
Thanks for any help.
--
David Milholen
Project Engineer
P:501-318-1300
___
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 04/22/2012 10:05 PM, David Milholen wrote:
listen-on {
9x.1xx.104.14;
};
Perhaps add 127.0.0.1; into the listen on clause.
- --
Larry Brower, CCENT
Fedora Ambassador - North America
Fedora Quality Assurance
lbro...@fedoraproject.org
http://www.fedoraproject.org/
-BEGIN PGP SIGNATURE-
iQIcBAEBCgAGBQJPlMp9AAoJEF1Xw4ZWTEoJMLgP/1yJ09F4QdPQqlq8yXl9MPDs
u8f7pwzgZxipsVGD3fiuV6FAhGh/D3AXMMkZIGqiXXBTb9WNBOnVi4pji+5pee2T
7bgEWBdBtS18jmvJTGi5Uu55BjhX8eSgLNKIRhUuWtJENL6cFl8QM14Qpzzu8eDz
oCAZmRgZ89qxqjQbwleB2ihiHvkdFbeC1AsKQg0IGxgVtrUofsBSVnRP1yVSx+de
dM92Jrhc+yY/A7TpiQsUmfOIljd3JNipfSmhFe/d+pe9a1umO1WQ7I4Fufg3AdIJ
jdlV3dvk0JuZegg4OM2jBmAMVtcJxXiLB4+QW3WGk/3prVYX1z3OawFIknszAnCD
xEB6AZA0dp0nMC3HBh+1RGpFkhc5oZdo6nhvu/BDuV5yI9lKJSAV4AzRd7MPFgEL
RTAeF5FIVPPJuvhgAeOHAsOxip2d5PLF18HvTIPaExx/EuRRGsXic36LJRyYkhUt
roatThoRBHsE6XgDc+CQJyC+Ac32pHBiJ6Y4lOIFYEbWTDjxbcD3Jszj3SaQbUCZ
jc+mzA8E9dLEv4kTtdbXPgnrWLBjeh24P/ZZBm26nvY2S5fZcrmnXsJBVuGB2FqL
di1wyz0xmqvilg3FwNNke9wt6lCRKvpycwUos3RiqadDGYCClMm3VySE4tdSWq/F
NgECeg/P6VrazDxYkHno
=zXKb
-END PGP SIGNATURE-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: new here
You set a listen-on that does not include 127.0.0.1.
On Apr 22, 2012 11:08 PM, David Milholen dmilho...@wletc.com wrote:
I am a Wisp admin and I have just configured a couple of new Bind9
servers.
They will resolve using dig google.com @9x.1xx.104.14
I am having some trouble getting them to answer themselves on 127.0.0.1
for example:
[root@ns4 named]# dig google.com @127.0.0.1 +trace
; DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5 google.com @127.0.0.1+trace
;; global options: printcmd
;; connection timed out; no servers could be reached
[root@ns4 named]#
Here is an my config:
//
// named.conf for Red Hat caching-nameserver
//
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; rndc-key; };
};
options {
directory /var/named;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
version Surely you must be joking;
notify yes;
allow-recursion {
127.0.0.1;
9x.1xx.104.0/22;
9x.1xx.108.0/23;
};
allow-transfer { 9x.1xx.104.22;
};
listen-on {
9x.1xx.104.14;
};
};
//
logging {
channel my_syslog {
syslog kern;
severity debug;
};
channel my_file {
file /var/named/chroot/var/named/log.msgs;
severity dynamic;
print-category yes;
};
category unmatched {
null;
};
category queries {
my_file;
};
category lame-servers {
null;
};
category general {
default_syslog;
};
};
// a caching only nameserver config
//
zone . IN {
type hint;
file root.servers;
};
zone 104.1xx.9x.in-addr.arpa {
type master;
file /var/named/9x.1xx.104.rev;
allow-transfer {
9x.1xx.104.22;
};
};
zone 0.0.127.in-addr.arpa {
type master;
file /var/named/127.0.0.rev;
};
zone localdomain {
type master;
file /var/named/localdomain.hosts;
};
zone localhost {
type master;
file /var/named/localhost.hosts;
};
key rndc-key {
algorithm hmac-md5;
secret wh6DFiuNGJHzHwvNTy8JEA==;
};
Here is my resolv.conf :
nameserver 127.0.0.1
nameserver 9x.1xx.104.14
Not sure what I broke but it seems to work on some of my older servers.
Thanks for any help.
--
David Milholen
Project Engineer
P:501-318-1300
___
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
