And here is the patch of course.
On Thu, Feb 17, 2011 at 3:13 AM, Mike Wilson <[email protected]> wrote:
> Hey noticed this while testing PowerDNS Authoritative Nameserver
> 2.9.22. Here's my config file:
>
> logging-facility=0
> skip-cname=no
> launch=gmysql
> gmysql-user=pdns
> gmysql-password=*secret*
> gmysql-dbname=pdns
> loglevel=9
> wildcards=yes
> daemon=yes
> soa-expire-default=300
> soa-minimum-ttl=60
> distributor-threads=1
> out-of-zone-additional-processing=yes
> recursor=8.8.8.8
>
>
> Lets say I have have a wildcard record pointing to 1.1.1.1 for zone. I
> also have example.zone in my database. When I query the nameserver for
> nonexistentsubdomain.example.zone I would always get 1.1.1.1 as my
> answer. I was expecting to get no answer at all rather than the
> wildcard for zone. I'm not an expert at DNS, but looking at RFC 1034
> it seems like my expectations match with the required behavior and I
> cannot find anything in RFC 4592 that would seem to change that.
> Specifically, this is the part it seems to violate from section 4.3.3
> of RFC 1034:
>
> Wildcard RRs do not apply:
>
> - When the query is in another zone. That is, delegation cancels
> the wildcard defaults.
>
> - When the query name or a name between the wildcard domain and
> the query name is know to exist. For example, if a wildcard
> RR has an owner name of "*.X", and the zone also contains RRs
> attached to B.X, the wildcards would apply to queries for name
> Z.X (presuming there is no explicit information for Z.X), but
> not to B.X, A.B.X, or X.
>
> I wrote a patch to correct the behavior if it is indeed a bug. The
> patch is included. What do you guys think? I realize that it doesn't
> cover the whole case of "the zone also contains RRs attached to B.X",
> but checking to see if we are authoritative for that domain would seem
> like a good place to stop the wildcard search.
>
> -Mike Wilson
>
--- pdns/packethandler.cc.orig 2011-02-16 08:35:53.000000000 -0700
+++ pdns/packethandler.cc 2011-02-17 01:38:05.000000000 -0700
@@ -234,7 +234,7 @@
}
/** returns 1 in case of a straight match, 2 in case of a wildcard CNAME (groan), 0 in case of no hit */
-int PacketHandler::doWildcardRecords(DNSPacket *p, DNSPacket *r, string &target)
+int PacketHandler::doWildcardRecords(DNSPacket *p, DNSPacket *r, string &target, SOAData *s)
{
DNSResourceRecord rr;
bool found=false, retargeted=false;
@@ -291,6 +291,16 @@
DLOG(L<<"Wildcard match on '"<<string("*.")+subdomain<<"'"<<", retargeted="<<retargeted<<endl);
return retargeted ? 2 : 1;
}
+ else {
+ int zoneId;
+ bool weAuth = true;
+ if (s->qname.empty())
+ weAuth = getAuth(p,s,subdomain,&zoneId);
+
+ if (weAuth && Utility::strcasecmp(s->qname.c_str(),subdomain.c_str()) == 0)
+ return 0;
+ }
+
}
DLOG(L<<"Returning no hit for '"<<string("*.")+subdomain<<"'"<<endl);
return 0;
@@ -748,7 +758,7 @@
// not found yet, try wildcards (we only try here in case of recursion - we should check before we hand off)
if(mret != 2 && p->d.rd && d_doRecursion && d_doWildcards) {
- int res=doWildcardRecords(p,r,target);
+ int res=doWildcardRecords(p,r,target,&sd);
if(res) { // had a result
// FIXME: wildCard may retarget us in the future
if(res==1) // had a straight result
@@ -858,7 +868,7 @@
if(!found) {
// try wildcards then
if(d_doWildcards) {
- int res=doWildcardRecords(p,r,target);
+ int res=doWildcardRecords(p,r,target,&sd);
if(res==1) // had a straight result
goto sendit;
--- pdns/packethandler.hh.orig 2011-02-16 08:36:01.000000000 -0700
+++ pdns/packethandler.hh 2011-02-16 08:36:09.000000000 -0700
@@ -84,7 +84,7 @@
void addRootReferral(DNSPacket *r);
int trySuperMaster(DNSPacket *p);
int makeCanonic(DNSPacket *p, DNSPacket *r, string &target);
- int doWildcardRecords(DNSPacket *p, DNSPacket *r, string &target);
+ int doWildcardRecords(DNSPacket *p, DNSPacket *r, string &target, SOAData *s);
int findMboxFW(DNSPacket *p, DNSPacket *r, string &target);
int findUrl(DNSPacket *p, DNSPacket *r, string &target);
int doFancyRecords(DNSPacket *p, DNSPacket *r, string &target);
_______________________________________________
Pdns-dev mailing list
[email protected]
http://mailman.powerdns.com/mailman/listinfo/pdns-dev
