[Pdns-users] NXDOMAIN on CNAME and UPC

[Peter van Dijk]

Hello Pawel,

On May 24, 2013, at 23:16 , Pawel Panek wrote:

> My concern is NXDOMAIN status. As per discussions and RFC's the answer is correct. I understand that but the problem is there are some dns resolver which just don't get it ;).
> Clients of mine started report they can't get cdn network to work with their sites. After investigation everything comes to common point - the ISP. All of them are using UPC broadband in Europe. When they query default UPC's name servers they are getting 'couldn't find host' errors. It looks like this:
> 
> nslookup cdn.mydomain.net
> Server: ns01.upclive.nl
> Address: 62.179.104.196
> *** ns01.upclive.nl could not find cdn.mydomain.net: Non-existent domain
> 
> tracert cdn.mydomain.net
> Could not convert the target name of cdn.mydomain.net.
> 
> Seems UPC's dns resolvers rely on dns response status and discard CNAME answer. Now the question comes in: who is wrong?
> There is hundreds of thousands clients in Europe using UPC services. I have the same reports from people living in Netherlands, Czech Rep.  and Poland. it's impossible for me to tell all of them to change dns resolvers to other servers. I would rather bend the rules and adjust PowerDNS status to return NOERROR for answers like this and have all these people off my back.
> Maybe someone from UPC is looking on this list and can share thoughts. Anyway, any advice on how to deal with this situation would be much appreciated.

First and foremost: if this happens for a domain, the authoritative servers ARE misconfigured. However, Recursor (3.3) is also wrong in accepting the bogus data. Recursor 3.5 and 3.5.1 operate correctly and will give useful answers in these situations.

We have reached out to UPC about this, and they have responded that they are aware of the issue, and are working to update their servers, which has already happened partially. Until this is done everywhere which will still take a while and in order to avoid running into the same issue at other providers they (and us!) recommend to avoid this issue by fixing the underlying configuration issue on the authoritative servers.

Kind regards,
-- 
Peter van Dijk
Netherlabs Computer Consulting BV - http://www.netherlabs.nl/