[Pdns-users] CNAME/Wildcard problem - why you should care.

[Augie Schwer]

This one came to me personally, but I think it should have gone to the list.

---------- Forwarded message ----------
From: Chris Seufert <chris at shopa.com.au>
Date: Aug 1, 2007 7:12 PM
Subject: Re: [Pdns-users] CNAME/Wildcard problem - why you should care.
To: Augie Schwer <augie.schwer at gmail.com>


Does this problem come into play when the client who is trying to
resolve the domain name is sitting on a IPv6 network, or does it have
the potential to happen with any IPv6 aware resolver. (ie has IPv4
address, but is IPv6 capable).

For pure IPv4 client <-> host, will anyone actually see this problem?
the reason i ask is, i have had no complaints from any of our cusomters.

Just a thought, but instead of using a wildcard CNAME, perhaps you could
use a wildcard A record, this does seem to alleviate the problem, but
its not fixing the problem thou. I see a bigger problem with a lookup
AAAA records our installation.

# host -t AAAA www.thewebdesigner.com.au fred.shopa.com.au
www.thewebdesigner.com.au       CNAME   dsl.thewebdesigner.com.au
dsl.thewebdesigner.com.au       CNAME   dsl.thewebdesigner.com.au
...
dsl.thewebdesigner.com.au       CNAME   dsl.thewebdesigner.com.au
dsl.thewebdesigner.com.au       CNAME   dsl.thewebdesigner.com.au
Possible CNAME loop

That seems to be as bad, if not worse, as the problem your describing.

-Chris

Augie Schwer wrote:
> In an effort to drum up more support for this problem I will explain
> why everyone should care about this problem getting fixed.
> (http://wiki.powerdns.com/cgi-bin/trac.fcgi/ticket/125)
>
> Modern resolving libraries make both AAAA and A requests when doing
> name lookups; Firefox for example makes a AAAA and then an A request.
>
> PowerDNS authoritative servers return incorrect data when they
> encounter a zone with a wild card (*) pointed at a CNAME. For example
> the partial zone below would cause problems:
>
> www.example.com        IN    A                192.168.0.5
> secure.example.com     IN    A                10.0.0.5
> *.example.com               IN    CNAME    www.example.com
>
> Your customers will try and surf to secure.example.com using Firefox
> and be dumbfounded when they end up at www.example.com .
>
> This happens because Firefox requests a AAAA first, your customers'
> recursor (BIND, PowerDNS, etc.) passes the query on to the
> authoritative server for example.com (PowerDNS), the authoritative
> server replies incorrectly that secure.example.com is a CNAME for
> www.example.com , the recursor caches this information, Firefox then
> makes a request for the A record, the recursor answers out of its
> cache that secure.example.com is a CNAME for www.example.com, and
> proceeds to make requests along these lines until the customer is
> eventually given the IP address of www.example.com.
>
> You should care about this problem because the zones and name servers
> involved may not be under your control, but you will still get an
> earful from your customers. You should care because even if all the
> zones and name servers are under your control, the service you provide
> will be perceived as broken. You should care because you will end up
> spending time trouble shooting why some people can resolve domain
> names just fine while others see this broken behavior (internal
> caching servers with authoritative data vs. local/external caching
> servers without authoritative data).
>
> If you are concerned about this behavior then please make yourself
> known; because if I am the only one that thinks this is a problem then
> I certainly don't expect it to get fixed any time soon.
>
>
>



-- 
Augie Schwer    -    Augie at Schwer.us    -    http://schwer.us
Key fingerprint = 9815 AE19 AFD1 1FE7 5DEE 2AC3 CB99 2784 27B0 C072