This looks like someone implemented dns-x20 which was a anti-spoofing proposal which made use of the fact that queries where case insensitive and that most servers preserved the case of the question in the reply. This gives a few extra bits on top of the query id much the same as using random ports gives a few extra bits.
dns-x20 basically says randomise the case of letters in the query and check that the response has the same randomisation. Alternatively this could just be a broken query section checker if they are not trying to implement dns-x20. I would expect anyone implementing dns-x20 to be able to turn it off in the configuration of the device. Now the DNS is supposed to be case preserving (RFC 1034/1035), in case there was ever a need to become case sensitive, which means the case of the question in the query should be preserved in the response and the case of domains in the answers should be preserved when extracting it from the databases. One could argue that the MikroTik server is actually in error here as it does not preserve the case of the query when generating the response. That said no one AFAIK does case preservation on cached data. Named does case preservation on zone transfers and has primatives which would allow it to do case preservation on authoritative answers (just change a flag). Full case preservation would require that we store case information of the ownernames of the records which we currently don't do. Mark In message <1376271809.3118.76.camel@karl>, Karl Auer writes: > Hi all. > > I have an odd issue - a particular device is apparently ignoring > apparently legal DNS responses. The only differences I can see between > the responses that do work and the responses that don't work are that in > the responses that don't work: > > a) the case of the response has been folded to lower case > > b) the response includes an additional servers section > > Here are two samples. The first fails, and was obtained by querying a > MikroTik embedded caching server. The second works, and was obtained by > querying a BIND caching server. If we tell the device to query the > embedded server, it ignores the responses; if we tell the device to > query the BIND server, it works. > > I guess I just want to know if the embedded server is doing anything > wrong in folding the case down, or if the other device is doing > something wrong by not accepting the folded response. > > Regards, K. > > kauer@karl:~/pcaps$ dig @192.168.1.1 pioneer.vTuner.com > > ; <<>> DiG 9.8.1-P1 <<>> @192.168.1.1 pioneer.vTuner.com > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16432 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 7 > > ;; QUESTION SECTION: > ;pioneer.vtuner.com. IN A > > ;; ANSWER SECTION: > pioneer.vtuner.com. 1800 IN CNAME primary8.vtuner.com. > primary8.vtuner.com. 1800 IN A 173.193.193.67 > > ;; AUTHORITY SECTION: > vtuner.com. 8745 IN NS ns1.securityspace.com. > vtuner.com. 8745 IN NS ns1.dnsmadeeasy.com. > vtuner.com. 8745 IN NS ns2.securityspace.com. > vtuner.com. 8745 IN NS ns0.dnsmadeeasy.com. > vtuner.com. 8745 IN NS ns4.dnsmadeeasy.com. > vtuner.com. 8745 IN NS ns2.dnsmadeeasy.com. > vtuner.com. 8745 IN NS ns3.dnsmadeeasy.com. > > ;; ADDITIONAL SECTION: > ns1.securityspace.com. 154 IN A 67.19.79.219 > ns1.dnsmadeeasy.com. 4002 IN A 208.80.124.2 > ns2.securityspace.com. 154 IN A 66.36.230.78 > ns0.dnsmadeeasy.com. 10840 IN A 208.94.148.2 > ns4.dnsmadeeasy.com. 692 IN A 208.80.127.2 > ns2.dnsmadeeasy.com. 10326 IN A 208.80.126.2 > ns3.dnsmadeeasy.com. 692 IN A 208.80.125.2 > > ;; Query time: 445 msec > ;; SERVER: 192.168.1.1#53(192.168.1.1) > ;; WHEN: Mon Aug 12 11:33:20 2013 > ;; MSG SIZE rcvd: 339 > > The second works, and was obtained by querying a BIND caching server: > > kauer@karl:~/pcaps$ dig @192.168.1.35 pioneer.vTuner.com > > ; <<>> DiG 9.8.1-P1 <<>> @192.168.1.35 pioneer.vTuner.com > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12903 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;pioneer.vTuner.com. IN A > > ;; ANSWER SECTION: > pioneer.vTuner.com. 1800 IN CNAME primary8.vTuner.com. > primary8.vTuner.com. 1800 IN A 173.193.193.67 > > ;; AUTHORITY SECTION: > vTuner.com. 83375 IN NS ns0.dnsmadeeasy.com. > vTuner.com. 83375 IN NS ns1.dnsmadeeasy.com. > vTuner.com. 83375 IN NS ns1.securityspace.com. > vTuner.com. 83375 IN NS ns2.dnsmadeeasy.com. > vTuner.com. 83375 IN NS ns2.securityspace.com. > vTuner.com. 83375 IN NS ns3.dnsmadeeasy.com. > vTuner.com. 83375 IN NS ns4.dnsmadeeasy.com. > > ;; Query time: 2477 msec > ;; SERVER: 192.168.1.35#53(192.168.1.35) > ;; WHEN: Mon Aug 12 11:36:02 2013 > ;; MSG SIZE rcvd: 227 > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (ka...@biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 > > GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A > Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 > > _______________________________________________ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ 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