case in responses

Mark Andrews marka at isc.org
Mon Aug 12 02:22:36 UTC 2013


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 at 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 at 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 at 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 (kauer at 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 at 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: marka at isc.org


More information about the bind-users mailing list