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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
