Bind9 - multiple identical CNAME records in single resultset (cid-*.calendar.live.com)

Hostmaster LUH hostmaster at rrzn.uni-hannover.de
Thu Sep 12 08:06:22 UTC 2013


Hello,


we are facing issues using bind9 as resolving nameservers for our users.
The problem is in resolving domains such as cid-*.calendar.live.com, e.g.
cid-20e76408fdfb6414.calendar.live.com

Bind discards the result with the following message in syslog:
named[1403]: error (FORMERR) resolving
'cid-20e76408fdfb6414.calendar.live.com/A/IN': 213.199.180.53#53

resolving the domain via dig +trace works:
dig +trace cid-20e76408fdfb6414.calendar.live.com

; <<>> DiG 9.8.1-P1 <<>> +trace cid-20e76408fdfb6414.calendar.live.com
....

cid-20e76408fdfb6414.calendar.live.com.	3600 IN	CNAME na.calendar.live.com.
na.calendar.live.com.	3600	IN	CNAME	calendar.live.com.
na.calendar.live.com.	3600	IN	CNAME	calendar.live.com.
calendar.live.com.	3600	IN	A	65.54.251.146
;; Received 151 bytes from 65.55.226.140#53(65.55.226.140) in 119 ms

We guess the problem is in the 2 (identical) CNAME records for the same
domain received in a single result set from ns*.msft.net, bind9 discards
these packets as invalid/FORMERR.
Resolving the CNAME will create a valid cache entry, resolving the A
record afterwards will work.
Using unbound, we are able to resolve domains properly directly.


We are looking for assistance with this, something as easy as a
configuration option to allow the (invalid?) packet to be processed
properly as unbound does would be great.
Of course adjusting the Microsoft nameservers to comply with the RFC
would be better, but we already tried to contact Microsoft (domains@,
msnhst@, opsimt@) about the issue, but so far there was no response.


The cid-*.calendar.live.com domains are used to identify the calendars
of users, the all point to the same records.
Using bind9, this does not work, so live.com calendar is broken (for all
of our users).



Sincerly,
Torsten Glaeser


More information about the bind-users mailing list