service-routing mDNS-SD bug that prevents Apple devices from performing A/AAAA lookups

bcoverstone · ‎09-21-2018

I have just recently learned and enabled mDNS-SD on a Cisco 3560 switch version 15.2(4)E5.

I am trying to share a device (Chromecast in this case) across subnets and found it works with everything except Apple products because their mDNS query is slightly different than other vendors.

I used Wireshark and the Cisco debug mdns commands to troubleshoot this. I'll summarize the issue, then show the supporting debug output. Hopefully someone knows a workaround, or perhaps Cisco will fix this at some point.

The issue is this: When a an mDNS query for an A/AAAA record occurs, if that query contains both a QUESTION and an ANSWER, Cisco mDNS will not be able to locate the record in it's cache.

Here are two debug outputs of a non-working and working mDNS query for the same A record. The only difference is the first debug has a query where questions=1 and answers=1, and the second debug has the answers counter changed to 0 (the answer payload is still in the packet, but it is ignored if answers=0, which made this test easier to perform).

I turned portions of the debug output RED that pertain to the issue.

Debug from failed query:

Sep 21 15:32:36.221: mDNS packet dump
11 11 1 20 0 1 0 1 0 0 0 1 24 35 64 62 31 63 34 66 37 2D 39 38 39 62 2D 38 63 36 64 2D 38 62 39 35 2D 34 32 36 65 34 34
36 37 34 38 63 35 5 6C 6F 63 61 6C 0 0 1 0 1 C0 C 0 1 0 1 0 0 0 72 0 4 C0 A8 B 62 0 0 29 5 A0 0 0 11 94 0 12 0 4 0 E 0 A
E 26 A0 74 31 47 4E 24 A0 74 31 47 4E
Sep 21 15:32:36.230:
Sep 21 15:32:36.230: DOM: id=4369, query, opcode=0, aa=0, tc=0, rd=1, ra=0
Sep 21 15:32:36.230:      rcode=0, qdcount=1, ancount=1, nscount=0, arcount=1
Sep 21 15:32:36.230:      query name is 5db1c4f7-989b-8c6d-8b95-426e446748c5.local, qtype=1, class=1
Sep 21 15:32:36.230: Answer section:
Sep 21 15:32:36.230:    Name='5db1c4f7-989b-8c6d-8b95-426e446748c5.local'
Sep 21 15:32:36.230:    RR type=1, class=1, ttl=114, data length=4
Sep 21 15:32:36.230:      IP=192.168.11.98
Sep 21 15:32:36.230: Authority section:
Sep 21 15:32:36.230: Additional record section:
Sep 21 15:32:36.230:    Name=''
Sep 21 15:32:36.230:    RR type=41, class=1440, ttl=4500, data length=18
Sep 21 15:32:36.230:      (Skipping unknown RR type)
Sep 21 15:32:36.230: mDNS: There are questions.
Sep 21 15:32:36.230: mDNS: Received A RR
Sep 21 15:32:36.238: mDNS: 5db1c4f7-989b-8c6d-8b95-426e446748c5.local A record already present
Sep 21 15:32:36.238: mDNS: No Entries found in the mDNS cache

Debug from successful query:

Sep 21 15:36:38.272: mDNS packet dump
11 11 1 20 0 1 0 0 0 0 0 1 24 35 64 62 31 63 34 66 37 2D 39 38 39 62 2D 38 63 36 64 2D 38 62 39 35 2D 34 32 36 65 34 34
36 37 34 38 63 35 5 6C 6F 63 61 6C 0 0 1 0 1 C0 C 0 1 0 1 0 0 0 72 0 4 C0 A8 B 62 0 0 29 5 A0 0 0 11 94 0 12 0 4 0 E 0 A
E 26 A0 74 31 47 4E 24 A0 74 31 47 4E
Sep 21 15:36:38.281:
Sep 21 15:36:38.281: DOM: id=4369, query, opcode=0, aa=0, tc=0, rd=1, ra=0
Sep 21 15:36:38.289:      rcode=0, qdcount=1, ancount=0, nscount=0, arcount=1
Sep 21 15:36:38.289:      query name is 5db1c4f7-989b-8c6d-8b95-426e446748c5.local, qtype=1, class=1
Sep 21 15:36:38.289: Answer section:
Sep 21 15:36:38.289: Authority section:
Sep 21 15:36:38.289: Additional record section:
Sep 21 15:36:38.289:    Name='5db1c4f7-989b-8c6d-8b95-426e446748c5.local'
Sep 21 15:36:38.289:    RR type=1, class=1, ttl=114, data length=4
Sep 21 15:36:38.289:      IP=192.168.11.98
Sep 21 15:36:38.289: mDNS: There are questions.
Sep 21 15:36:38.289: DOM: id=0, response, opcode=0, aa=0, tc=0, rd=0, ra=0
Sep 21 15:36:38.289:      rcode=0, qdcount=0, ancount=1, nscount=0, arcount=0
Sep 21 15:36:38.297: Answer section:
Sep 21 15:36:38.297:    Name='5db1c4f7-989b-8c6d-8b95-426e446748c5.local'
Sep 21 15:36:38.297:    RR type=1, class=1, ttl=116, data length=4
Sep 21 15:36:38.297:      IP=192.168.11.98
Sep 21 15:36:38.297: Authority section:
Sep 21 15:36:38.297: Additional record section:
Sep 21 15:36:38.297: mDNS: Interface index in mdns_send_packet is 978
Sep 21 15:36:38.297: mDNS: idb in mdns_send_packet is Vlan10
Sep 21 15:36:38.297: mDNS packet dump
0 0 80 0 0 0 0 1 0 0 0 0 24 35 64 62 31 63 34 66 37 2D 39 38 39 62 2D 38 63 36 64 2D 38 62 39 35 2D 34 32 36 65 34 34 36
 37 34 38 63 35 5 6C 6F 63 61 6C 0 0 1 0 1 0 0 0 74 0 4 C0 A8 B 62
Sep 21 15:36:38.297:
Sep 21 15:36:38.297: mDNS: ip addr on idb Vlan10 192.168.10.1 1
Sep 21 15:36:38.297: mDNS: Setting up the mDNS socket buffer of size 70
Sep 21 15:36:38.306: mDNS: Sending Multicast IPV4 Packet on interface Vlan10

As you can see above, the only byte changed from the query in the first debug to the query in the second debug is the number "00 01" to "00 00" in the first few bytes of the query packet, which changes the answers to 0. The first debug shows that the mDNS-SD process erroneously was not able to find the record. The second debug shows that the mDNS-SD process successfully returned the response.

Since every Apple product seems to query services in this fashion, is there a workaround for this?

Georg Pauwen · ‎09-22-2018

Hello,

tough one. I couldn't find any bugs related to to this.

Does this also happen with static mDNS (as in the example below) ?

Cisco(config)# service-instance mdns-sd service Apple regtype _ipp._tcp.local. domain local
Cisco(config-mdns-sd-si)# target-hostname Apple.local

Also, does it not work for devices in the same VLAN and/or across VLANs ?

bcoverstone · ‎09-24-2018

Hi Georg,

This only happens when routing between vlans, as the client/server talk directly when in the same vlan.

I tested a service-instance using the following commands:

service-instance mdns-sd service "abcd" regtype _googlecast._tcp domain local
 target-hostname abcd.local
 ipv4addr 192.168.11.64

[I also re-configured filters so there would only be one _googlecast._tcp.local, so there wouldn't be two responses]

The same thing happened, this time with my service-instance name: question abcd.local and answer 192.168.11.64.

Below is a snapshot from Wireshark, showing the request packet from the Apple device querying the A record immediately after receiving the manual service-instance that we created. It's as if it needs to validate that the A record matches the IP address that it just received.