CNAMEs to non-local names with authoritative server as recursor

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

CNAMEs to non-local names with authoritative server as recursor

lists-2
Hi,

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?  

Cheers
_______________________________________________
Pdns-users mailing list
[hidden email]
https://mailman.powerdns.com/listinfo/pdns-users@...
Reply | Threaded
Open this post in threaded view
|

Re: CNAMEs to non-local names with authoritative server as recursor

lists-2
>> 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.


Here are some logs from an instance of PDNS running to test this issue.  
Some background on the output, our environment is fairly complicated
with many networks, which for historical reasons have a notion of
belonging to "sides".  There are many duplicate host names on each side,
so the DNS database has all of them in the database under the same name
as if they were round-robin, but DNS will return the right one depending
on which network the client is in, and whether they are looking for
something on their side or not based on a variety of historical prefixes
(local, remote, side1, side2 etc.).
That isn't relevant to my problem here, but may help explain what you
are seeing.  The backend also only answers for A records it can handle,
everything else falls through to a regular database lookup.

The problem comes below where the backend lets the query fall through to
the database to find the CNAME.  CNAMEs which point to records in our
domain work fine, but records outside our domain fail.  Below is the dig
command I ran, and the output from PDNS:



dns1.la pdns $ dig -t ANY @localhost -p 63 status-aws.domain.local

; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.5 <<>> -t ANY @localhost -p 63
status-aws.domain.local
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61123
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;status-aws.domain.local.   IN  ANY

;; AUTHORITY SECTION:
.           2707    IN  SOA a.root-servers.net. nstld.verisign-grs.com.
2016013101 1800 900 604800 86400

;; Query time: 25 msec
;; SERVER: 127.0.0.1#63(127.0.0.1)
;; WHEN: Sun Jan 31 22:46:52 UTC 2016
;; MSG SIZE  rcvd: 117




Jan 31 22:46:52 dns1 pdns-dev[21381]: Remote 127.0.0.1 wants
'status-aws.domain.local|ANY', do = 0, bufsize = 1680: packetcache MISS
Jan 31 22:46:52 dns1 pdns-dev[21381]: Distributor misses a thread (4<5),
spawning new one
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query: 'Q        
status-aws.domain.local        IN        SOA        -1        127.0.0.1'
Jan 31 22:46:52 dns1 auto-view-backend[21392]: Asked for
status-aws.domain.local SOA by 127.0.0.1
Jan 31 22:46:52 dns1 auto-view-backend[21392]: 127.0.0.1
                                                 isn't in our networks,
pretending it is on my side.
Jan 31 22:46:52 dns1 auto-view-backend[21392]: Client is in la
Jan 31 22:46:52 dns1 auto-view-backend[21392]: Client in la asked for
local.
Jan 31 22:46:52 dns1 auto-view-backend[21392]: Request is for a type SOA
record.  Letting this fall through to the next backend.
Jan 31 22:46:52 dns1 auto-view-backend[21392]: No working A records
given, falling through
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query: 'Q        domain.local      
   IN        SOA        -1        127.0.0.1'
Jan 31 22:46:52 dns1 auto-view-backend[21392]: Asked for domain.local
SOA by 127.0.0.1
Jan 31 22:46:52 dns1 auto-view-backend[21392]: 127.0.0.1
                                                 isn't in our networks,
pretending it is on my side.
Jan 31 22:46:52 dns1 auto-view-backend[21392]: Client is in la
Jan 31 22:46:52 dns1 auto-view-backend[21392]: Client in la asked for
local.
Jan 31 22:46:52 dns1 auto-view-backend[21392]: Request is for a type SOA
record.  Letting this fall through to the next backend.
Jan 31 22:46:52 dns1 auto-view-backend[21392]: No working A records
given, falling through
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query for 'local' type 'SOA'
failed regex 'domain.local'
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query for '' type 'SOA' failed
regex 'domain.local'
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query: SELECT
content,ttl,prio,type,domain_id,disabled::int,name,auth::int FROM
records WHERE disabled=false and type='SOA' and
name=E'status-aws.domain.local'
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query: SELECT
content,ttl,prio,type,domain_id,disabled::int,name,auth::int FROM
records WHERE disabled=false and type='SOA' and name=E'domain.local'
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query: select max(change_date)
from records where domain_id=1
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query: 'Q        
status-aws.domain.local        IN        NS        1        127.0.0.1'
Jan 31 22:46:52 dns1 auto-view-backend[21392]: Asked for
status-aws.domain.local NS by 127.0.0.1
Jan 31 22:46:52 dns1 auto-view-backend[21392]: 127.0.0.1
                                                 isn't in our networks,
pretending it is on my side.
Jan 31 22:46:52 dns1 auto-view-backend[21392]: Client is in la
Jan 31 22:46:52 dns1 auto-view-backend[21392]: Client in la asked for
local.
Jan 31 22:46:52 dns1 auto-view-backend[21392]: Request is for a type NS
record.  Letting this fall through to the next backend.
Jan 31 22:46:52 dns1 auto-view-backend[21392]: No working A records
given, falling through
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query: SELECT
content,ttl,prio,type,domain_id,disabled::int,name,auth::int FROM
records WHERE disabled=false and type='NS' and
name=E'status-aws.domain.local' and domain_id=1
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query: 'Q        
status-aws.domain.local        IN        ANY        1        127.0.0.1'
Jan 31 22:46:52 dns1 auto-view-backend[21392]: Asked for
status-aws.domain.local ANY by 127.0.0.1
Jan 31 22:46:52 dns1 auto-view-backend[21392]: 127.0.0.1
                                                 isn't in our networks,
pretending it is on my side.
Jan 31 22:46:52 dns1 auto-view-backend[21392]: Client is in la
Jan 31 22:46:52 dns1 auto-view-backend[21392]: Client in la asked for
local.
Jan 31 22:46:52 dns1 auto-view-backend[21392]: No working A records
given, falling through
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query: SELECT
content,ttl,prio,type,domain_id,disabled::int,name,auth::int FROM
records WHERE disabled=false and name=E'status-aws.domain.local' and
domain_id=1
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query for
'internal-domain-status-1009579898.us-west-1.elb.amazonaws.com' type
'SOA' failed regex 'domain.local'
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query for
'us-west-1.elb.amazonaws.com' type 'SOA' failed regex 'domain.local'
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query for 'elb.amazonaws.com' type
'SOA' failed regex 'domain.local'
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query for 'amazonaws.com' type
'SOA' failed regex 'domain.local'
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query for 'com' type 'SOA' failed
regex 'domain.local'
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query for '' type 'SOA' failed
regex 'domain.local'
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query: SELECT
content,ttl,prio,type,domain_id,disabled::int,name,auth::int FROM
records WHERE disabled=false and type='SOA' and
name=E'internal-domain-status-1009579898.us-west-1.elb.amazonaws.com'
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query: SELECT
content,ttl,prio,type,domain_id,disabled::int,name,auth::int FROM
records WHERE disabled=false and type='SOA' and
name=E'us-west-1.elb.amazonaws.com'
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query: SELECT
content,ttl,prio,type,domain_id,disabled::int,name,auth::int FROM
records WHERE disabled=false and type='SOA' and
name=E'elb.amazonaws.com'
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query: SELECT
content,ttl,prio,type,domain_id,disabled::int,name,auth::int FROM
records WHERE disabled=false and type='SOA' and name=E'amazonaws.com'
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query: SELECT
content,ttl,prio,type,domain_id,disabled::int,name,auth::int FROM
records WHERE disabled=false and type='SOA' and name=E'com'
Jan 31 22:46:52 dns1 pdns-dev[21381]: Query: SELECT
content,ttl,prio,type,domain_id,disabled::int,name,auth::int FROM
records WHERE disabled=false and type='SOA' and name=E''
Jan 31 22:46:52 dns1 pdns-dev[21381]: Backend launched with banner: OK  
      auto-view backend starting
Jan 31 22:46:52 dns1 pdns-dev[21381]: gpgsql Connection successful.
Connected to database 'powerdns' on ''.

~
_______________________________________________
Pdns-users mailing list
[hidden email]
https://mailman.powerdns.com/listinfo/pdns-users@...
Reply | Threaded
Open this post in threaded view
|

Re: CNAMEs to non-local names with authoritative server as recursor

lists-2
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 :)
_______________________________________________
Pdns-users mailing list
[hidden email]
https://mailman.powerdns.com/mailman/listinfo/pdns-users