Let's be transparent here: reverse lookups are not a formal requirement, and,
if I'm not mistaken, not even officially published as a Best Practice. Many
folks don't bother with them.
Having said that, they are *very* useful, and I insist on them wherever
possible.
If an organization decides to go with reverse mappings, one thing they should
decide is how to handle reverse-lookup "ambiguities". By that, I mean, if you
have NameA.example.com resolving to an address and NameB.example.com resolving
to the same address, then where should the reverse mapping point?
NameA.example.com or NameB.example.com? You can't really have *both*, since
that's not the way reverse-resolution works (you can define both RRs in the
RRset, but clients only see one of them, so what's the point?). It's tempting
to say that NameA.example.com must be an alias for NameB.example.com or
_vice_versa_, but aliases aren't always possible -- consider if both
NameA.example.com and NameB.example.com are delegated subzones. The apex of a
zone can't be an alias. So, this is a business decision that needs to be made.
One possible rule is that ambiguities are simply *forbidden*, i.e. we disallow
pointing a name directly at an IP address which is already mapped to a
different n
ame -- it has to be an alias, or it can't be created at all. But then you have
to sell that to your customers, end-users, partners, etc. and that might not be
an easy pill to swallow. This "ambiguity" decision is not a showstopper, just a
stop along the journey. Lastly, I'll point out that if you (as we do) have a
DNS maintenance system which automatically keeps the forward and reverse
records in sync, then it needs to be aware of, and handle, whatever decision
has been made in terms of reverse-record ambiguity. Our homegrown system
handles this in a very inflexible, embedded way, as per decisions we made years
ago. But a commercial product should be flexible enough to handle a wide
variety of choices.
- Kevin
-----Original Message-----
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark Andrews
Sent: Monday, February 22, 2016 9:32 PM
To: David Li
Cc: BIND Users
Subject: Re: A Zone Transfer Question
I've yet to see a system that doesn't do reverse lookups automatically.
Lots of tools do it so, yes, you should be configuring the nameserver to return
PTR records.
Mark
In message <caeutsay4u42eotuk2+z16e5mwouq6n5dcuztgtddue67h19...@mail.gmail.com>
, David Li writes:
> Hi Mark,
>
> Thanks for the explanation!
>
> At this time all my stuff are internal to the data center so I just
> added an option to listen to the IPv4 only. This seems to have made
> these error messages gone away.
>
> I do have another question: If I don't need to do reverse lookup, do
> I still need PTR records? In other words, is there any downside if I
> don't have PTR records in my zone files?
>
> David
>
>
>
>
>
> On Mon, Feb 22, 2016 at 4:04 PM, Mark Andrews <ma...@isc.org> wrote:
> >
> > This is named trying to talk to nameservers over IPv6 and being told
> > by the OS that they are unreachable.
> >
> > At this point in time you should be yelling at your ISP to supply
> > you with IPv6 connectivity if they aren't already as the world ran
> > out of IPv4 addresses years ago and the network is only running
> > because ISP's that don't have enough addresses are sharing them
> > between multiple customers which is costing everyone in one way or
> > another.
> >
> > If your ISP is offering you IPv6 you may need to update your CPE
> > router to one which supports IPv6.
> >
> > There is no valid excuse for a ISP not supplying IPv6 in 2016. They
> > have had over a decade to plan for how to deliver IPv6 to you.
> >
> > Mark
> >
> >
> > In message <CAEuTsAyDpMHZiKENFyZEpPxgAfQAzfDecSBtzjX+h7F4YGpKGg@mail.gmail.
> com>
> > , David Li writes:
> >> Barry and others:
> >>
> >> Thanks for the help!
> >> It's my bad that the slave zone's subnet range was missing from
> >> allow-query. I also added the slave IP explicitly to the
> >> allow-transfer option. Now it's seems to be working.
> >>
> >>
> >> Another issue that I haven't quite figured out is the errors in the
> >> syslog. I have no idea where these are coming from:
> >>
> >>
> >>
> >> Feb 22 15:27:33 dli-centos7 named[2170]: error (network
> >> unreachable) resolving 'node2/A/IN': 2001:503:c27::2:30#53 Feb 22
> >> 15:27:33 dli-centos7 named[2170]: error (network unreachable)
> >> resolving 'node2/A/IN': 2001:7fd::1#53 Feb 22 15:27:33 dli-centos7
> >> named[2170]: error (network unreachable) resolving './NS/IN':
> >> 2001:500:1::803f:235#53 Feb 22 15:27:33 dli-centos7 named[2170]:
> >> error (network unreachable) resolving './NS/IN':
> >> 2001:503:c27::2:30#53 Feb 22 15:27:33 dli-centos7 named[2170]:
> >> error (network unreachable) resolving './NS/IN': 2001:7fd::1#53 Feb
> >> 22 15:27:38 dli-centos7 named[2170]: error (network unreachable)
> >> resolving 'node2/A/IN': 2001:dc3::35#53 Feb 22 15:27:38 dli-centos7
> >> named[2170]: error (network unreachable) resolving 'node2/A/IN':
> >> 2001:7fe::53#53 Feb 22 15:27:38 dli-centos7 named[2170]: error
> >> (network unreachable) resolving './NS/IN': 2001:dc3::35#53 Feb 22
> >> 15:27:38 dli-centos7 named[2170]: error (network unreachable)
> >> resolving './NS/
> >>
> >>
> >> I don't have a zone file that have these records defined. Any idea?
> >>
> >> David
> >>
> >>
> >>
> >>
> >> > ------------------------------
> >> >
> >> > Message: 3
> >> > Date: Fri, 19 Feb 2016 21:25:43 -0500
> >> > From: Barry Margolin <bar...@alum.mit.edu>
> >> > To: comp-protocols-dns-b...@isc.org
> >> > Subject: Re: A Zone Transfer Question
> >> > Message-ID:
> >> > <barmar-b6877f.21254319022...@88-209-239-213.giganet.hu>
> >> >
> >> > In article
> >> > <mailman.269.1455926963.73610.bind-us...@lists.isc.org>,
> >> > David Li <dlipub...@gmail.com> wrote:
> >> >
> >> >> Hi John,
> >> >>
> >> >> Well, I was wrong about the log. I did find some info about why
> >> >> zone transfer failed. On one server running zone rack1.com, I see:
> >> >>
> >> >> Feb 19 16:04:27 dli-centos7 named[13882]: client
> >> >> 10.4.3.101#20745
> >> >> (rack1.com): query 'rack1.com/SOA/IN' denied Feb 19 16:04:27
> >> >> dli-centos7 named[13882]: client 10.4.3.101#52612
> >> >> (rack1.com): transfer of 'rack1.com/IN': IXFR ended
> >> >>
> >> >> Any idea why it's denied?
> >> >
> >> > VM1 has the option:
> >> >
> >> > allow-query {
> >> > 10.4.1/24;
> >> > 127.0.0.1;
> >> > };
> >> >
> >> > 10.4.3.101 isn't in 10.4.1/24. The slave has to be allowed to
> >> > query the master.
> >> >
> >> > --
> >> > Barry Margolin
> >> > Arlington, MA
> >> >
> >> >
> >> > ------------------------------
> >> >
> >> _______________________________________________
> >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> >> unsubscr
> ibe
> >> 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
--
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
_______________________________________________
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
