Re: reverse zone of type forward when /28 subnet
Well, it's Ok with that. I indeed am the owner of small reverse
zone 255-241.z.y.x.in-addr.arpa IN { type master;
named with accordance with rfc2317 CNAME trick and can edit it.
The changes are transferred one way to the ISP side and make part of
their zone z.y.x.in-addr.arpa. So my changes are seen by the world.
But this small subzone cannot be used for direct reverse resolving right
at my dns. It can only be done at class C (or B, or A) granularity.
So to achieve exactly what I want I need to pull somehow this class C
zone z.y.x.in-addr.arpa to my dns. Either as slave zone (which is
denied by ISP) or as forward zone which I cannot tune to work.
May be some other unknown by me approach exists.
Again, there is no problem with reverse resolving in general but
I cannot achieve this directly at my dns, that is to receive a response
from it no matter wherever it forwards the request or from where it
gets the PTR records.
Peter Andreev wrote:
Please correct me if I'm wrong: you'd like to edit PTR records for
your part of the /24 zone?
If so, what you ISP says about rfc2317?
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Hi,
I've searched the list archives and Google and don't see anything
to answer my question subj.
we have let's say x.y.z.240/28 subnet and BIND 9.9.2-P1.
We want to have a master DNS without unnecessary extra functionality.
(Including no caching)
This is the named.conf with obscured addresses:
# cat /dns992/etc/named.conf
key rndc-key { ... };
controls { ... };
acl nameservers { A; B; };
options { directory /var/named;
allow-query { any; };
recursion no;
version Some Server;
listen-on { x.y.z.w; };
pid-file /var/run/named.pid;
};
zone company IN { type master;
file company.dat;
allow-transfer { nameservers; };
};
zone 255-241.z.y.x.in-addr.arpa IN { type master;
file company.rev;
allow-transfer { nameservers; };
};
zone z.y.x.in-addr.arpa IN { type forward; forward only;
forwarders { intranet.1; }; };
//zone z.y.x.in-addr.arpa IN { type slave;
//file z_y_x_in-addr.arpa;
//masters { A; B; };
//};
zone localhost IN { type master;
file master.localhost;
allow-update { none; };
};
zone 0.0.127.in-addr.arpa IN { type master;
file localhst.rev;
notify no;
};
Direct resolving works fine. Our subzone is delegated from ISP properly.
dig +trace shows due CNAMEs and in general reverse resolving works as well.
But I want to achieve reverse resolving on our DNS itself.
It is a quite natural desire, to be self sufficient or at least pretend to
be,
isn't it ...
The simplest way to achieve that would be to have a slave zone for the whole
class C network x.y.z.0/24 but the ISP don't allow zone transfer.
A can understand why transfers of direct zones are limited by security
reasons. But reverse zones do not contain any private subdomains or
whatever.
There is nothing in the reverse zone that cannot be collected by simple
queries. And, BTW nothing to hide.
Well, another way would be to have a reverse zone for z.y.x.in-addr.arpa
of type forward with forward only clause and due forwarders.
But it doesn't seem to work. I've tried external forwarders including
8.8.8.8 + 8.8.8.4 without success and now stick with our internal dns
at intranet/24.1
This internal dns produces perfect reverse resolving but only for internal
users, of course the internals acl includes the address of external dns.
It has this set of options:
options {
directory /var/named;
forward first;
version not available;
forwarders { A; B; };
allow-query { internals; };
allow-transfer { none; };
allow-recursion { internals; };
listen-on { intranet.1; };
};
What I have when performing reverse resolving at external dns is:
x.y.z.k
Server: x.y.z.w
Address:x.y.z.w#53
** server can't find k.z.y.x.in-addr.arpa: REFUSED
and setting set d2 in nslookup v9.9.2 doesn't reveal anything
catching attention although I see that there is an attempt to
contact the forwarder.
trying origin company.internal (obscured as well)
recursive query
add_question()
starting to render the message
done rendering
create query 0x402a4010 linked to lookup 0x82168c0
do_lookup()
send_udp(0x402a4010)
bringup_timer()
have local timeout of 5
working on lookup 0x82168c0, query 0x402a4010
sockcount=1
recving with lookup=0x82168c0, query=0x402a4010, sock=0x402a5008
recvcount=1
sending a request
unlock_lookup dighost.c:3530
lock_lookup dighost.c:2328
success
send_done()
sendcount=0
check_if_done()
list empty
unlock_lookup dighost.c:2357
recv_done()
lock_lookup dighost.c:3053
success
recvcount=0
lookup=0x82168c0, query=0x402a4010
before parse starts
after parse
next_origin()
So for some reason the list is empty and recvcount=0 in the second
occasion.
From the same shell, from the very same nslookup instance with
server local dns
the reverse lookup is OK.
And of course I am
Re: Signed zone does not get updated 'receive_secure_serial: not exact'
Am 26.12.2012 um 23:31 schrieb Mark Andrews ma...@isc.org: * the record to be removed was not there * the record to be aded was already there This means that the two versions of the zone have become unsyncronized. I did some more tests with another zone. Not sure BIND works as intended there: - zone 'trashheap' gets signed (has serial 7 unsigned and receives serial 8|10 signed subsequently) Dec 27 11:34:12 spectre named[27411]: zone trashheap.net/IN (unsigned): loaded serial 7 Dec 27 11:34:12 spectre named[27411]: any newly configured zones are now loaded Dec 27 11:34:12 spectre named[27411]: zone trashheap.net/IN (signed): loaded serial 7 Dec 27 11:34:12 spectre named[27411]: trashheap.net/IN: dns_diff_apply: update with no effect Dec 27 11:34:12 spectre named[27411]: zone trashheap.net/IN (signed): receive_secure_serial: not exact Dec 27 11:34:12 spectre named[27411]: zone trashheap.net/IN (signed): reconfiguring zone keys Dec 27 11:34:12 spectre named[27411]: zone trashheap.net/IN (signed): next key event: 27-Dec-2012 11:34:12.333 Dec 27 11:34:12 spectre named[27411]: zone trashheap.net/IN (signed): sending notifies (serial 8) Dec 27 11:34:12 spectre named[27411]: client 88.198.49.12#26609/key ns1-acme.spoerlein.net (trashheap.net): transfer of 'trashheap.net/IN': IXFR started: TSIG ns1-acme.spoerlein.net Dec 27 11:34:12 spectre named[27411]: client 88.198.49.12#26609/key ns1-acme.spoerlein.net (trashheap.net): transfer of 'trashheap.net/IN': IXFR ended Dec 27 11:34:17 spectre named[27411]: zone trashheap.net/IN (signed): sending notifies (serial 10) Dec 27 11:34:17 spectre named[27411]: client 88.198.49.12#17597/key ns1-acme.spoerlein.net (trashheap.net): transfer of 'trashheap.net/IN': IXFR started: TSIG ns1-acme.spoerlein.net Dec 27 11:34:17 spectre named[27411]: client 88.198.49.12#17597/key ns1-acme.spoerlein.net (trashheap.net): transfer of 'trashheap.net/IN': IXFR ended - a TXT record is added to zone 'trashheap' via nsupdate - same problem as before: 'receive_secure_serial: not exact' Dec 27 11:37:33 spectre named[27411]: client 188.138.3.243#59506/key tlx.leuxner.net: signer tlx.leuxner.net approved Dec 27 11:37:33 spectre named[27411]: client 188.138.3.243#59506/key tlx.leuxner.net: updating zone 'trashheap.net/IN': adding an RR at '2013._domainkey.trashheap.net' TXT Dec 27 11:37:33 spectre named[27411]: trashheap.net/IN: dns_diff_apply: update with no effect Dec 27 11:37:33 spectre named[27411]: zone trashheap.net/IN (signed): receive_secure_serial: not exact - to mitigate the problem, zone journal is dropped again 'rndc sync -clean trashheap.net' - zone is frozen - unsigned serial is increased (to 9) - zone is unfrozen - zone receives new signed serial (11) Dec 27 11:44:10 spectre named[27411]: received control channel command 'sync -clean trashheap.net' Dec 27 11:44:10 spectre named[27411]: sync: dumping zone 'trashheap.net/IN', removing journal file: success Dec 27 11:45:40 spectre named[27411]: received control channel command 'loadkeys trashheap.net' Dec 27 11:45:40 spectre named[27411]: zone trashheap.net/IN (signed): reconfiguring zone keys Dec 27 11:45:40 spectre named[27411]: zone trashheap.net/IN (signed): next key event: 27-Dec-2012 11:45:40.045 Dec 27 11:46:38 spectre named[27411]: received control channel command 'freeze trashheap.net' Dec 27 11:46:38 spectre named[27411]: freezing zone 'trashheap.net/IN': success Dec 27 11:47:02 spectre named[27411]: received control channel command 'thaw trashheap.net' Dec 27 11:47:02 spectre named[27411]: thawing zone 'trashheap.net/IN': success Dec 27 11:47:02 spectre named[27411]: zone trashheap.net/IN (unsigned): loaded serial 9 Dec 27 11:47:02 spectre named[27411]: zone trashheap.net/IN (signed): serial 11 (unsigned 9) Dec 27 11:47:02 spectre named[27411]: zone trashheap.net/IN (signed): sending notifies (serial 11) Dec 27 11:47:02 spectre named[27411]: client 88.198.49.12#54606/key ns1-acme.spoerlein.net (trashheap.net): transfer of 'trashheap.net/IN': IXFR started: TSIG ns1-acme.spoerlein.net Dec 27 11:47:02 spectre named[27411]: client 88.198.49.12#54606/key ns1-acme.spoerlein.net (trashheap.net): transfer of 'trashheap.net/IN': IXFR ended - another TXT record is added and propagation works going forward Dec 27 12:03:21 spectre named[27411]: client 188.138.3.243#13188/key tlx.leuxner.net: updating zone 'trashheap.net/IN': adding an RR at '2014._domainkey.trashheap.net' TXT Dec 27 12:03:21 spectre named[27411]: zone trashheap.net/IN (signed): serial 12 (unsigned 10) Dec 27 12:03:21 spectre named[27411]: zone trashheap.net/IN (signed): sending notifies (serial 12) Regards Thomas smime.p7s Description: S/MIME cryptographic signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: reverse zone of type forward when /28 subnet
Forwarding does not work without recursion enabled.
There is a few ways to solve the problem:
1. Using views;
2. Using another dns resolver (for example Unbound);
3. Downloading the zone via script (bad idea from any point);
4. Do not bother where your resolver get authoritative data (I'd
recommend this one).
Actually, I'm afraid you won't be able to achieve your goal without
needless overcomplication.
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Well, it's Ok with that. I indeed am the owner of small reverse
zone 255-241.z.y.x.in-addr.arpa IN { type master;
named with accordance with rfc2317 CNAME trick and can edit it.
The changes are transferred one way to the ISP side and make part of
their zone z.y.x.in-addr.arpa. So my changes are seen by the world.
But this small subzone cannot be used for direct reverse resolving right
at my dns. It can only be done at class C (or B, or A) granularity.
So to achieve exactly what I want I need to pull somehow this class C
zone z.y.x.in-addr.arpa to my dns. Either as slave zone (which is
denied by ISP) or as forward zone which I cannot tune to work.
May be some other unknown by me approach exists.
Again, there is no problem with reverse resolving in general but
I cannot achieve this directly at my dns, that is to receive a response
from it no matter wherever it forwards the request or from where it
gets the PTR records.
Peter Andreev wrote:
Please correct me if I'm wrong: you'd like to edit PTR records for
your part of the /24 zone?
If so, what you ISP says about rfc2317?
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Hi,
I've searched the list archives and Google and don't see anything
to answer my question subj.
we have let's say x.y.z.240/28 subnet and BIND 9.9.2-P1.
We want to have a master DNS without unnecessary extra functionality.
(Including no caching)
This is the named.conf with obscured addresses:
# cat /dns992/etc/named.conf
key rndc-key { ... };
controls { ... };
acl nameservers { A; B; };
options { directory /var/named;
allow-query { any; };
recursion no;
version Some Server;
listen-on { x.y.z.w; };
pid-file /var/run/named.pid;
};
zone company IN { type master;
file company.dat;
allow-transfer { nameservers; };
};
zone 255-241.z.y.x.in-addr.arpa IN { type master;
file company.rev;
allow-transfer { nameservers; };
};
zone z.y.x.in-addr.arpa IN { type forward; forward only;
forwarders { intranet.1; }; };
//zone z.y.x.in-addr.arpa IN { type slave;
//file z_y_x_in-addr.arpa;
//masters { A; B; };
//};
zone localhost IN { type master;
file master.localhost;
allow-update { none; };
};
zone 0.0.127.in-addr.arpa IN { type master;
file localhst.rev;
notify no;
};
Direct resolving works fine. Our subzone is delegated from ISP properly.
dig +trace shows due CNAMEs and in general reverse resolving works as
well.
But I want to achieve reverse resolving on our DNS itself.
It is a quite natural desire, to be self sufficient or at least pretend
to
be,
isn't it ...
The simplest way to achieve that would be to have a slave zone for the
whole
class C network x.y.z.0/24 but the ISP don't allow zone transfer.
A can understand why transfers of direct zones are limited by security
reasons. But reverse zones do not contain any private subdomains or
whatever.
There is nothing in the reverse zone that cannot be collected by simple
queries. And, BTW nothing to hide.
Well, another way would be to have a reverse zone for z.y.x.in-addr.arpa
of type forward with forward only clause and due forwarders.
But it doesn't seem to work. I've tried external forwarders including
8.8.8.8 + 8.8.8.4 without success and now stick with our internal dns
at intranet/24.1
This internal dns produces perfect reverse resolving but only for
internal
users, of course the internals acl includes the address of external
dns.
It has this set of options:
options {
directory /var/named;
forward first;
version not available;
forwarders { A; B; };
allow-query { internals; };
allow-transfer { none; };
allow-recursion { internals; };
listen-on { intranet.1; };
};
What I have when performing reverse resolving at external dns is:
x.y.z.k
Server: x.y.z.w
Address:x.y.z.w#53
** server can't find k.z.y.x.in-addr.arpa: REFUSED
and setting set d2 in nslookup v9.9.2 doesn't reveal anything
catching attention although I see that there is an attempt to
contact the forwarder.
trying origin company.internal (obscured as well)
recursive query
add_question()
starting to render the message
done rendering
create query 0x402a4010 linked to lookup 0x82168c0
do_lookup()
send_udp(0x402a4010)
bringup_timer()
have local timeout of 5
working on lookup 0x82168c0, query 0x402a4010
sockcount=1
recving
Re: reverse zone of type forward when /28 subnet
Hi,
thanks a lot for the information.
Contains key reason and sounds interesting.
1. Do you mean I can isolate zone z.y.x.in-addr.arpa
into a separate view where recursion is enabled but all
other zones are excluded? If so, it's very promising.
2. Sorry, Unbound - is it just another dns server?
3. Thought about a script. Know Korn shell at middle level.
Nobody prohibits to maintain yet another copy of master zone.
But I don't want to indulge into such remote circumventions.
4. That's possible to not bother about the issue but for now
I am not ready to fold hands.
Peter Andreev wrote:
Forwarding does not work without recursion enabled.
There is a few ways to solve the problem:
1. Using views;
2. Using another dns resolver (for example Unbound);
3. Downloading the zone via script (bad idea from any point);
4. Do not bother where your resolver get authoritative data (I'd
recommend this one).
Actually, I'm afraid you won't be able to achieve your goal without
needless overcomplication.
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Well, it's Ok with that. I indeed am the owner of small reverse
zone 255-241.z.y.x.in-addr.arpa IN { type master;
named with accordance with rfc2317 CNAME trick and can edit it.
The changes are transferred one way to the ISP side and make part of
their zone z.y.x.in-addr.arpa. So my changes are seen by the world.
But this small subzone cannot be used for direct reverse resolving right
at my dns. It can only be done at class C (or B, or A) granularity.
So to achieve exactly what I want I need to pull somehow this class C
zone z.y.x.in-addr.arpa to my dns. Either as slave zone (which is
denied by ISP) or as forward zone which I cannot tune to work.
May be some other unknown by me approach exists.
Again, there is no problem with reverse resolving in general but
I cannot achieve this directly at my dns, that is to receive a response
from it no matter wherever it forwards the request or from where it
gets the PTR records.
Peter Andreev wrote:
Please correct me if I'm wrong: you'd like to edit PTR records for
your part of the /24 zone?
If so, what you ISP says about rfc2317?
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Hi,
I've searched the list archives and Google and don't see anything
to answer my question subj.
we have let's say x.y.z.240/28 subnet and BIND 9.9.2-P1.
We want to have a master DNS without unnecessary extra functionality.
(Including no caching)
This is the named.conf with obscured addresses:
# cat /dns992/etc/named.conf
key rndc-key { ... };
controls { ... };
acl nameservers { A; B; };
options { directory /var/named;
allow-query { any; };
recursion no;
version Some Server;
listen-on { x.y.z.w; };
pid-file /var/run/named.pid;
};
zone company IN { type master;
file company.dat;
allow-transfer { nameservers; };
};
zone 255-241.z.y.x.in-addr.arpa IN { type master;
file company.rev;
allow-transfer { nameservers; };
};
zone z.y.x.in-addr.arpa IN { type forward; forward only;
forwarders { intranet.1; }; };
//zone z.y.x.in-addr.arpa IN { type slave;
//file z_y_x_in-addr.arpa;
//masters { A; B; };
//};
zone localhost IN { type master;
file master.localhost;
allow-update { none; };
};
zone 0.0.127.in-addr.arpa IN { type master;
file localhst.rev;
notify no;
};
Direct resolving works fine. Our subzone is delegated from ISP properly.
dig +trace shows due CNAMEs and in general reverse resolving works as
well.
But I want to achieve reverse resolving on our DNS itself.
It is a quite natural desire, to be self sufficient or at least pretend
to
be,
isn't it ...
The simplest way to achieve that would be to have a slave zone for the
whole
class C network x.y.z.0/24 but the ISP don't allow zone transfer.
A can understand why transfers of direct zones are limited by security
reasons. But reverse zones do not contain any private subdomains or
whatever.
There is nothing in the reverse zone that cannot be collected by simple
queries. And, BTW nothing to hide.
Well, another way would be to have a reverse zone for z.y.x.in-addr.arpa
of type forward with forward only clause and due forwarders.
But it doesn't seem to work. I've tried external forwarders including
8.8.8.8 + 8.8.8.4 without success and now stick with our internal dns
at intranet/24.1
This internal dns produces perfect reverse resolving but only for
internal
users, of course the internals acl includes the address of external
dns.
It has this set of options:
options {
directory /var/named;
forward first;
version not available;
forwarders { A; B; };
allow-query { internals; };
allow-transfer { none; };
allow-recursion { internals; };
listen-on { intranet.1; };
};
What I have when performing reverse resolving at external dns is:
x.y.z.k
Server: x.y.z.w
Address:x.y.z.w#53
** server can't find
Re: reverse zone of type forward when /28 subnet
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Hi,
thanks a lot for the information.
Contains key reason and sounds interesting.
1. Do you mean I can isolate zone z.y.x.in-addr.arpa
into a separate view where recursion is enabled but all
other zones are excluded? If so, it's very promising.
Actually, forwarding also doesn't work for queries without RD bit.
Such queries are being sent by resolver in normal circumstances.
2. Sorry, Unbound - is it just another dns server?
Yep, it is recursive-only dns server. It has an option called
local-zone, which is absolutelly what you are looking for. Note that
Unbound has very limited capabilities to support authoritative data.
3. Thought about a script. Know Korn shell at middle level.
Nobody prohibits to maintain yet another copy of master zone.
Nobody but zone owner.
But I don't want to indulge into such remote circumventions.
4. That's possible to not bother about the issue but for now
I am not ready to fold hands.
I just meant that fencing your resolver without really good reasons is
a bad idea. If you do it just for fun in production environment, you
should think twice.
Peter Andreev wrote:
Forwarding does not work without recursion enabled.
There is a few ways to solve the problem:
1. Using views;
2. Using another dns resolver (for example Unbound);
3. Downloading the zone via script (bad idea from any point);
4. Do not bother where your resolver get authoritative data (I'd
recommend this one).
Actually, I'm afraid you won't be able to achieve your goal without
needless overcomplication.
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Well, it's Ok with that. I indeed am the owner of small reverse
zone 255-241.z.y.x.in-addr.arpa IN { type master;
named with accordance with rfc2317 CNAME trick and can edit it.
The changes are transferred one way to the ISP side and make part of
their zone z.y.x.in-addr.arpa. So my changes are seen by the world.
But this small subzone cannot be used for direct reverse resolving right
at my dns. It can only be done at class C (or B, or A) granularity.
So to achieve exactly what I want I need to pull somehow this class C
zone z.y.x.in-addr.arpa to my dns. Either as slave zone (which is
denied by ISP) or as forward zone which I cannot tune to work.
May be some other unknown by me approach exists.
Again, there is no problem with reverse resolving in general but
I cannot achieve this directly at my dns, that is to receive a response
from it no matter wherever it forwards the request or from where it
gets the PTR records.
Peter Andreev wrote:
Please correct me if I'm wrong: you'd like to edit PTR records for
your part of the /24 zone?
If so, what you ISP says about rfc2317?
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Hi,
I've searched the list archives and Google and don't see anything
to answer my question subj.
we have let's say x.y.z.240/28 subnet and BIND 9.9.2-P1.
We want to have a master DNS without unnecessary extra functionality.
(Including no caching)
This is the named.conf with obscured addresses:
# cat /dns992/etc/named.conf
key rndc-key { ... };
controls { ... };
acl nameservers { A; B; };
options { directory /var/named;
allow-query { any; };
recursion no;
version Some Server;
listen-on { x.y.z.w; };
pid-file /var/run/named.pid;
};
zone company IN { type master;
file company.dat;
allow-transfer { nameservers; };
};
zone 255-241.z.y.x.in-addr.arpa IN { type master;
file company.rev;
allow-transfer { nameservers; };
};
zone z.y.x.in-addr.arpa IN { type forward; forward only;
forwarders { intranet.1; }; };
//zone z.y.x.in-addr.arpa IN { type slave;
//file z_y_x_in-addr.arpa;
//masters { A; B; };
//};
zone localhost IN { type master;
file master.localhost;
allow-update { none; };
};
zone 0.0.127.in-addr.arpa IN { type master;
file localhst.rev;
notify no;
};
Direct resolving works fine. Our subzone is delegated from ISP
properly.
dig +trace shows due CNAMEs and in general reverse resolving works as
well.
But I want to achieve reverse resolving on our DNS itself.
It is a quite natural desire, to be self sufficient or at least pretend
to
be,
isn't it ...
The simplest way to achieve that would be to have a slave zone for the
whole
class C network x.y.z.0/24 but the ISP don't allow zone transfer.
A can understand why transfers of direct zones are limited by security
reasons. But reverse zones do not contain any private subdomains or
whatever.
There is nothing in the reverse zone that cannot be collected by simple
queries. And, BTW nothing to hide.
Well, another way would be to have a reverse zone for
z.y.x.in-addr.arpa
of type forward with forward only clause and due forwarders.
But it doesn't seem to work. I've tried external forwarders including
8.8.8.8 +
Re: reverse zone of type forward when /28 subnet
Ok, thank you,
I'll try views first of all.
And I need some further clarification about this:
I just meant that fencing your resolver without really good reasons is
a bad idea.
By fencing your resolver do you mean converting a dns
server into only a source of information from its master zones
cutting severely any unnecessary functionality or anything else?
What is a bad idea and why?
In fact I want to do so because I want to protect it from
cache poisoning and any other attack of forge nature.
Peter Andreev wrote:
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Hi,
thanks a lot for the information.
Contains key reason and sounds interesting.
1. Do you mean I can isolate zone z.y.x.in-addr.arpa
into a separate view where recursion is enabled but all
other zones are excluded? If so, it's very promising.
Actually, forwarding also doesn't work for queries without RD bit.
Such queries are being sent by resolver in normal circumstances.
2. Sorry, Unbound - is it just another dns server?
Yep, it is recursive-only dns server. It has an option called
local-zone, which is absolutelly what you are looking for. Note that
Unbound has very limited capabilities to support authoritative data.
3. Thought about a script. Know Korn shell at middle level.
Nobody prohibits to maintain yet another copy of master zone.
Nobody but zone owner.
But I don't want to indulge into such remote circumventions.
4. That's possible to not bother about the issue but for now
I am not ready to fold hands.
I just meant that fencing your resolver without really good reasons is
a bad idea. If you do it just for fun in production environment, you
should think twice.
Peter Andreev wrote:
Forwarding does not work without recursion enabled.
There is a few ways to solve the problem:
1. Using views;
2. Using another dns resolver (for example Unbound);
3. Downloading the zone via script (bad idea from any point);
4. Do not bother where your resolver get authoritative data (I'd
recommend this one).
Actually, I'm afraid you won't be able to achieve your goal without
needless overcomplication.
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Well, it's Ok with that. I indeed am the owner of small reverse
zone 255-241.z.y.x.in-addr.arpa IN { type master;
named with accordance with rfc2317 CNAME trick and can edit it.
The changes are transferred one way to the ISP side and make part of
their zone z.y.x.in-addr.arpa. So my changes are seen by the world.
But this small subzone cannot be used for direct reverse resolving right
at my dns. It can only be done at class C (or B, or A) granularity.
So to achieve exactly what I want I need to pull somehow this class C
zone z.y.x.in-addr.arpa to my dns. Either as slave zone (which is
denied by ISP) or as forward zone which I cannot tune to work.
May be some other unknown by me approach exists.
Again, there is no problem with reverse resolving in general but
I cannot achieve this directly at my dns, that is to receive a response
from it no matter wherever it forwards the request or from where it
gets the PTR records.
Peter Andreev wrote:
Please correct me if I'm wrong: you'd like to edit PTR records for
your part of the /24 zone?
If so, what you ISP says about rfc2317?
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Hi,
I've searched the list archives and Google and don't see anything
to answer my question subj.
we have let's say x.y.z.240/28 subnet and BIND 9.9.2-P1.
We want to have a master DNS without unnecessary extra functionality.
(Including no caching)
This is the named.conf with obscured addresses:
# cat /dns992/etc/named.conf
key rndc-key { ... };
controls { ... };
acl nameservers { A; B; };
options { directory /var/named;
allow-query { any; };
recursion no;
version Some Server;
listen-on { x.y.z.w; };
pid-file /var/run/named.pid;
};
zone company IN { type master;
file company.dat;
allow-transfer { nameservers; };
};
zone 255-241.z.y.x.in-addr.arpa IN { type master;
file company.rev;
allow-transfer { nameservers; };
};
zone z.y.x.in-addr.arpa IN { type forward; forward only;
forwarders { intranet.1; }; };
//zone z.y.x.in-addr.arpa IN { type slave;
//file z_y_x_in-addr.arpa;
//masters { A; B; };
//};
zone localhost IN { type master;
file master.localhost;
allow-update { none; };
};
zone 0.0.127.in-addr.arpa IN { type master;
file localhst.rev;
notify no;
};
Direct resolving works fine. Our subzone is delegated from ISP
properly.
dig +trace shows due CNAMEs and in general reverse resolving works as
well.
But I want to achieve reverse resolving on our DNS itself.
It is a quite natural desire, to be self sufficient or at least pretend
to
be,
isn't it ...
The simplest way to achieve that would be to have a slave zone for the
whole
class C network x.y.z.0/24 but the ISP don't allow zone transfer.
A can understand why transfers of direct
Re: reverse zone of type forward when /28 subnet
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Ok, thank you,
I'll try views first of all.
And I need some further clarification about this:
I just meant that fencing your resolver without really good reasons is
a bad idea.
By fencing your resolver do you mean converting a dns
server into only a source of information from its master zones
cutting severely any unnecessary functionality or anything else?
What is a bad idea and why?
You are trying to cut some ways of information obtaining for resolver.
That is what I mean.
In fact I want to do so because I want to protect it from
cache poisoning and any other attack of forge nature.
I can't say these attacks are very common. Actually I can't recall any
cases of such attacks in a wild nature. Also, in-addr.arpa isn't a
good target.
As for now the best defence against cache poisoning is DNSSec and
since we have signed all russian TLDs you could implement it.
Peter Andreev wrote:
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Hi,
thanks a lot for the information.
Contains key reason and sounds interesting.
1. Do you mean I can isolate zone z.y.x.in-addr.arpa
into a separate view where recursion is enabled but all
other zones are excluded? If so, it's very promising.
Actually, forwarding also doesn't work for queries without RD bit.
Such queries are being sent by resolver in normal circumstances.
2. Sorry, Unbound - is it just another dns server?
Yep, it is recursive-only dns server. It has an option called
local-zone, which is absolutelly what you are looking for. Note that
Unbound has very limited capabilities to support authoritative data.
3. Thought about a script. Know Korn shell at middle level.
Nobody prohibits to maintain yet another copy of master zone.
Nobody but zone owner.
But I don't want to indulge into such remote circumventions.
4. That's possible to not bother about the issue but for now
I am not ready to fold hands.
I just meant that fencing your resolver without really good reasons is
a bad idea. If you do it just for fun in production environment, you
should think twice.
Peter Andreev wrote:
Forwarding does not work without recursion enabled.
There is a few ways to solve the problem:
1. Using views;
2. Using another dns resolver (for example Unbound);
3. Downloading the zone via script (bad idea from any point);
4. Do not bother where your resolver get authoritative data (I'd
recommend this one).
Actually, I'm afraid you won't be able to achieve your goal without
needless overcomplication.
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Well, it's Ok with that. I indeed am the owner of small reverse
zone 255-241.z.y.x.in-addr.arpa IN { type master;
named with accordance with rfc2317 CNAME trick and can edit it.
The changes are transferred one way to the ISP side and make part of
their zone z.y.x.in-addr.arpa. So my changes are seen by the world.
But this small subzone cannot be used for direct reverse resolving
right
at my dns. It can only be done at class C (or B, or A) granularity.
So to achieve exactly what I want I need to pull somehow this class C
zone z.y.x.in-addr.arpa to my dns. Either as slave zone (which is
denied by ISP) or as forward zone which I cannot tune to work.
May be some other unknown by me approach exists.
Again, there is no problem with reverse resolving in general but
I cannot achieve this directly at my dns, that is to receive a response
from it no matter wherever it forwards the request or from where it
gets the PTR records.
Peter Andreev wrote:
Please correct me if I'm wrong: you'd like to edit PTR records for
your part of the /24 zone?
If so, what you ISP says about rfc2317?
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Hi,
I've searched the list archives and Google and don't see anything
to answer my question subj.
we have let's say x.y.z.240/28 subnet and BIND 9.9.2-P1.
We want to have a master DNS without unnecessary extra functionality.
(Including no caching)
This is the named.conf with obscured addresses:
# cat /dns992/etc/named.conf
key rndc-key { ... };
controls { ... };
acl nameservers { A; B; };
options { directory /var/named;
allow-query { any; };
recursion no;
version Some Server;
listen-on { x.y.z.w; };
pid-file /var/run/named.pid;
};
zone company IN { type master;
file company.dat;
allow-transfer { nameservers; };
};
zone 255-241.z.y.x.in-addr.arpa IN { type master;
file company.rev;
allow-transfer { nameservers; };
};
zone z.y.x.in-addr.arpa IN { type forward; forward only;
forwarders { intranet.1; }; };
//zone z.y.x.in-addr.arpa IN { type slave;
//file z_y_x_in-addr.arpa;
//masters { A; B; };
//};
zone localhost IN { type master;
file master.localhost;
allow-update { none; };
};
zone 0.0.127.in-addr.arpa IN { type master;
file
difference between default views in named_statistics.txt
Hi, We are using bind as a recursive dns server in our college. It is working fine. Now we need to make a report regarding QPS, NXDOMAIN, FORMAT ERROR, Server Failure, Name Error, Not Implemented, Refused queries comes to our recursive DNS SERVER. For this we use named_statistics file which gives all information regarding our requirement. But when look in to named_statistics file, It shows below output, cat /var/named/chroot/var/named/data/named_stats.txt +++ Statistics Dump +++ (1356630443) ... ... ... [View: _bind] ++ Name Server Statistics ++ 4 IPv4 requests received 2 requests with EDNS(0) received 4 responses sent 2 responses with EDNS(0) sent 3 queries resulted in successful answer 4 queries resulted in non authoritative answer 1 queries resulted in NXDOMAIN 4 queries caused recursion ++ Zone Maintenance Statistics ++ ++ Resolver Statistics ++ [Common] [View: default] 67 IPv4 queries sent 66 IPv4 responses received 3 NXDOMAIN received 8 FORMERR received 8 EDNS(0) query failures 10 query retries 2 query timeouts 12 IPv4 NS address fetches 21 DNSSEC validation attempted 16 DNSSEC validation succeeded 5 DNSSEC NX validation succeeded 6 queries with RTT 10-100ms 60 queries with RTT 100-500ms While making report regarding our requirement, do we need to consider Resolver Statistics or Name Server Statistics values ? What will be difference between view : default and view _bind ? Because when we look on NXDOMAIN values view: default shows 3 and view: _bind shows 1, so as we are playing recursive dns server role in network, from which we consider correct value for our requirement ? if is there any nice document to understand this statistics, please share it. Best Regards, 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: reverse zone of type forward when /28 subnet
In message 50dc2b79.1040...@dionaholding.ru, Dmitri Tarkhov writes:
Well, it's Ok with that. I indeed am the owner of small reverse
zone 255-241.z.y.x.in-addr.arpa IN { type master;
named with accordance with rfc2317 CNAME trick and can edit it.
The changes are transferred one way to the ISP side and make part of
their zone z.y.x.in-addr.arpa. So my changes are seen by the world.
But this small subzone cannot be used for direct reverse resolving right
at my dns. It can only be done at class C (or B, or A) granularity.
So to achieve exactly what I want I need to pull somehow this class C
zone z.y.x.in-addr.arpa to my dns. Either as slave zone (which is
denied by ISP) or as forward zone which I cannot tune to work.
May be some other unknown by me approach exists.
Again, there is no problem with reverse resolving in general but
I cannot achieve this directly at my dns, that is to receive a response
from it no matter wherever it forwards the request or from where it
gets the PTR records.
RFC 2317 style delegations are for convience as they reduce the
number of zones that need to be configured. If your ISP won't
permit the transfer of the parent zone, which prevents local reverse
lookups working when the upstream link is broken, you should revert
to traditional delegations. That is 1 zone per IP address.
Note any ISP that prevents the parent zone being transfered to the
customer, when doing RFC 2317 style delegations, doesn't know what
they are doing as they are forcing you to run a configuration that
depends upon the link working 100% of the time.
Mark
zone 241.Z.X.Y.IN-ADDR.ARPA {
type master;
file 241.Z.X.Y.IN-ADDR.ARPA;
};
...
zone 255.z.x.y.IN-ADDR.ARPA {
type master;
file 255.Z.X.Y.IN-ADDR.ARPA;
};
241.z.x.y.IN-ADDR.ARPA:
@ 3600SOA .
@ 3600NS
@ 3600NS
242.z.x.y.IN-ADDR.ARPA:
@ 3600SOA .
@ 3600NS
@ 3600NS
@ 3600PTR
...
255.z.x.y.IN-ADDR.ARPA:
@ 3600SOA .
@ 3600NS
@ 3600NS
Peter Andreev wrote:
Please correct me if I'm wrong: you'd like to edit PTR records for
your part of the /24 zone?
If so, what you ISP says about rfc2317?
2012/12/27 Dmitri Tarkhov tark...@dionaholding.ru:
Hi,
I've searched the list archives and Google and don't see anything
to answer my question subj.
we have let's say x.y.z.240/28 subnet and BIND 9.9.2-P1.
We want to have a master DNS without unnecessary extra functionality.
(Including no caching)
This is the named.conf with obscured addresses:
# cat /dns992/etc/named.conf
key rndc-key { ... };
controls { ... };
acl nameservers { A; B; };
options { directory /var/named;
allow-query { any; };
recursion no;
version Some Server;
listen-on { x.y.z.w; };
pid-file /var/run/named.pid;
};
zone company IN { type master;
file company.dat;
allow-transfer { nameservers; };
};
zone 255-241.z.y.x.in-addr.arpa IN { type master;
file company.rev;
allow-transfer { nameservers; };
};
zone z.y.x.in-addr.arpa IN { type forward; forward only;
forwarders { intranet.1; }; };
//zone z.y.x.in-addr.arpa IN { type slave;
//file z_y_x_in-addr.arpa;
//masters { A; B; };
//};
zone localhost IN { type master;
file master.localhost;
allow-update { none; };
};
zone 0.0.127.in-addr.arpa IN { type master;
file localhst.rev;
notify no;
};
Direct resolving works fine. Our subzone is delegated from ISP properly.
dig +trace shows due CNAMEs and in general reverse resolving works as well.
But I want to achieve reverse resolving on our DNS itself.
It is a quite natural desire, to be self sufficient or at least pretend to
be,
isn't it ...
The simplest way to achieve that would be to have a slave zone for the whol
e
class C network x.y.z.0/24 but the ISP don't allow zone transfer.
A can understand why transfers of direct zones are limited by security
reasons. But reverse zones do not contain any private subdomains or
whatever.
There is nothing in the reverse zone that cannot be collected by simple
queries. And, BTW nothing to hide.
Well, another way would be to have a reverse zone for z.y.x.in-addr.arpa
of type forward with forward only clause and due forwarders.
But it doesn't seem to work. I've tried external forwarders including
8.8.8.8 + 8.8.8.4 without success and now stick with our internal dns
at intranet/24.1
This internal dns produces perfect reverse resolving but only for internal
users, of course the internals acl includes the address of external dns.
It has this set of options:
options {
directory /var/named;
forward first;
version not available;
forwarders { A; B; };
allow-query { internals; };
allow-transfer { none; };
Re: reverse zone of type forward when /28 subnet
On 12/27/2012 11:18 AM, Mark Andrews wrote:
zone 241.Z.X.Y.IN-ADDR.ARPA {
type master;
file 241.Z.X.Y.IN-ADDR.ARPA;
};
That's great locally, but it doesn't match the 2317 delegation from the
upstream, and usually it's not possible to change what they send you.
Or are you suggesting maintaining both the individual versions of the
zones, and the 2317 zone?
Doug
___
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: reverse zone of type forward when /28 subnet
In message 50dcd454.2070...@dougbarton.us, Doug Barton writes:
On 12/27/2012 11:18 AM, Mark Andrews wrote:
zone 241.Z.X.Y.IN-ADDR.ARPA {
type master;
file 241.Z.X.Y.IN-ADDR.ARPA;
};
That's great locally, but it doesn't match the 2317 delegation from the
upstream, and usually it's not possible to change what they send you.
Or are you suggesting maintaining both the individual versions of the
zones, and the 2317 zone?
No. I'm suggesting that they tell their ISP to do RFC 2317 right
or do RFC 1035 delegations. If their ISP won't do either change
ISP.
Doug
___
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
--
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
Re: difference between default views in named_statistics.txt
On Dec 27, 2012, at 1:05 PM, benjamin fernandis benjo11...@gmail.com wrote: cat /var/named/chroot/var/named/data/named_stats.txt While this may present what you want, I think you may be happier parsing the Statistics Channel... http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html#statschannels While this points to the 9.9 ARM, but the statistics channel has existed since 9.5. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com ___ 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: difference between default views in named_statistics.txt
Hi Alan, Thanks for your kind response. I enabled statistics channel and in that i can see Resolver Statistics for View _default and Resolver Statistics for View _bind what is the difference between these two views which also same in named_Statistics file. BR Ben On Fri, Dec 28, 2012 at 5:56 AM, Alan Clegg a...@clegg.com wrote: On Dec 27, 2012, at 1:05 PM, benjamin fernandis benjo11...@gmail.com wrote: cat /var/named/chroot/var/named/data/named_stats.txt While this may present what you want, I think you may be happier parsing the Statistics Channel... http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html#statschannels While this points to the 9.9 ARM, but the statistics channel has existed since 9.5. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com ___ 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: reverse zone of type forward when /28 subnet
Hi, all,
thank you very much for discussion. It was interesting and very useful.
You can pretty well imagine that I am not much dns involved,
I am rather unix and unix HW guy.
Unfortunately I saw dns cache poisoning attack and although it could be
provoked by side effects it's better to get rid of it altogether.
For just 14 (241-254) addresses it is not difficult to maintain 2 types
of master zones in sync (RFC 2317 and RFC 1035) and it's enough to put a
couple of comment lines to not forget it later.
Yes, life is short but this is not the reason to not train the brain,
can help to hook a life a bit longer ...
Bring stir to the chicken coop and request compliance is generally
good idea and fingers itch but I don't expect much from our ISPs ...
So first I'll try type forward within a view,
then I'm sure, one address zones can serve me right.
I will also contact the ISP but without great expectations.
Why I do all this is:
- enforce security
- assure stable mail exchange (which depends on reverse resolving)
Mark Andrews wrote:
In message 50dcd454.2070...@dougbarton.us, Doug Barton writes:
On 12/27/2012 11:18 AM, Mark Andrews wrote:
zone 241.Z.X.Y.IN-ADDR.ARPA {
type master;
file 241.Z.X.Y.IN-ADDR.ARPA;
};
That's great locally, but it doesn't match the 2317 delegation from the
upstream, and usually it's not possible to change what they send you.
Or are you suggesting maintaining both the individual versions of the
zones, and the 2317 zone?
No. I'm suggesting that they tell their ISP to do RFC 2317 right
or do RFC 1035 delegations. If their ISP won't do either change
ISP.
Doug
___
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
--
Best regards,
Dmitri Tarkhov
___
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
