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

Augie Schwer augie.schwer at gmail.com
Thu Aug 2 00:25:50 UTC 2007


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


More information about the Pdns-users mailing list