[Pdns-users] CNAMEs to non-local names with authoritative server as recursor

[Chris]

On Mon, Feb 01, 2016 at 12:52:49PM +1300, Chris wrote:
> > > I am using pdns-static-3.4.4-1.x86_64, and I have a pipe backend
> > > which modifies local records based on the clients location in the
> > > network.  This means I need the authoritative server in front of the
> > > recursor so I can get their IP address.  The backend only handles
> > > the request if it finds an A records, otherwise it just sends END so
> > > it falls through, and pdns itself looks up the record in the
> > > database.  This works great, but I have a problem when it comes to
> > > serving CNAMEs that aren't local.  If they are local, it works fine.
> > > For non-local records, from what I can see, the answer comes back
> > > from the database like
> > > server-1009579898.us-west-1.elb.amazonaws.com., then the server
> > > loops over the answer to find everything up to .com, finds nothing
> > > in the database, but I don't think it ever reaches out to the
> > > recursor.  It then returns nothing to the client.  I suppose that
> > > makes sense as an authoritative server, but is there any way to get
> > > this situation to work?
> > > 
> > Can you provide examples of output? When asked directly from AUTH
> > server you are supposed to get CNAME back if it's non-local.
> 

This is a fairly old thread now, since I had found a work-around, but I
finally sat down to figure out what was happening.  Just in case someone
is running the same wacky setup that I am, here is what happened.  I was
under the impression that when a authoritative server doing recursion
got a CNAME from the database, and determined that it isn't
authoritative for the CNAME, it would pass the CNAME on to the recursor
behind the scenes.  What it does, however, is pass the original query to
the resolver, which knew nothing about our internal domain.  The tip-off
is when I started getting 127.0.53.53 for a new internal domain which
should never have been going to the internet.

What I had to do was tell the recursor to forward our internal domain to
the authoritative server again.  That way when it gets the internal
domain name from the authoritative server, it sends it right back, gets
the CNAME and *then* it starts the query over with the CNAME.  A bit
loopy, but it works :)