you just showed how parent zone (2.0.192.in-addr.arpa) must be
configured for it.
On 18.01.18 12:58, Grant Taylor via bind-users wrote:
No, I did not. The following zone is the authoritative zone, as seen
by the world.
; Mach Global zone file
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA prisoner.iana.org. hostmaster.root-servers.org.
(2002040800 30m 15m 1w 1w)
1 IN PTR host1.example.net.
2 IN PTR host2.example.net.
; …
42 IN PTR host42.example.net.
; …
Note that nothing has been done in the authoritative zone.
The following is the zone that would go on the local server that
would override the globally authoritative zone.
; Mach local zone file
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA myLocalServer.myLocalDomain.myTld.
myEmail.myPublicDomain.myTld. (2002040800 30m 15m 1w 1w)
1 IN PTR client1.myLocalDomain.myTld.
2 IN PTR client2.myLocalDomain.myTld.
; …
42 IN NS blackhole-1.iana.org.
42 IN NS blackhole-2.iana.org.
; …
96 IN PTR server3.myLocalDomain.myTld.
97 IN PTR oldServer3.myLocalDomain.myTld.
; …
This local copy is where the changes are made to override what the
globally authoritative zone serves. (Like I think the OP was
indicating s/he was doing.)
The NS records for 42 in the local zone ""delegate back to the parent
servers.
so, in fact you want the whole zone locally, override anything you like, but
forward some records to other servers?
DNS does not work that way.
in BIND this is not done by configuring zone data, but by configuring named
to forward zones.
zone "42.2.0.192.in-addr.arpa" {
type static-stub;
server-names {
blackhole-1.iana.org;
blackhole-2.iana.org;
};
};
what you describe is how dj bernstein proposed reverse delegation.
I was not aware of that. I'll have to look into his proposed solution.
I'm not sure this will help you. What you want is apparently asking for
troubles.
However it's much better to define subzone and redirect records via
CNAMEs to it. it's easier to define one subzone with a few NS
records pointing to it and replace each PTR with CNAME than replace
each PTR with multiple NSes.
I'm going to have to disagree with you. I have used both RFC 2317
Classless IN-ADDR.ARPA (type) delegation and the delegation that I'm
suggesting multiple times. Every time I've used Classless
IN-ADDR.ARPA (type) delegation has resulted in heartache or worse.
I don't remember having any troubles with classless delegation.
unless someone misconfigured it, of course. but misconfigured DNS is a
problem of different kind.
I've even personally experienced cases where Spam RBLs failed
miserably with RFC 2317 Classless IN-ADDR.ARPA and ended up black
listing things inappropriately. I have had zero problems with the
type of delegation that I'm advocating.
what do dns blacklist have in common with classless delegation?
classless delegation means you are delegating subzone to other server.
Which blacklist ever tried to delegate subzone to other blacklist?
Combining the fact that 2317 Classless IN-ADDR.ARPA (type) delegation
requires support in the authoritative / parent zone with the problems
that I've seen and the fact that I've not seen any problems with my
alternate, I'll continue using my alternate.
As a bonus, it's entirely possible to do cross delegation using my
method without any problems. I can have two clients using /25, each
cross delegating the others part, and things work out quite well.
this may "work" when you have your own reverze zone and agree with other
owners on sharing. But from the internet, and from the DNS point of view,
you are creating problematic mess.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
A day without sunshine is like, night.
_______________________________________________
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
