A Zone Transfer Question

Darcy Kevin (FCA) kevin.darcy at fcagroup.com
Tue Feb 23 17:48:54 UTC 2016 

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 name -- 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-bounces at lists.isc.org [mailto:bind-users-bounces at 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+Z16E5mwoUq6n5DcuztGTddue67h19Pmg at 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 <marka at 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 at 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 <barmar at alum.mit.edu>
> >> > To: comp-protocols-dns-bind at isc.org
> >> > Subject: Re: A Zone Transfer Question
> >> > Message-ID: 
> >> > <barmar-B6877F.21254319022016 at 88-209-239-213.giganet.hu>
> >> >
> >> > In article 
> >> > <mailman.269.1455926963.73610.bind-users at lists.isc.org>,
> >> >  David Li <dlipubkey at 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 at 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: marka at isc.org
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

More information about the bind-users mailing list