Subject: [dnssd] Questions about draft-cheshire-mdnsext-hybrid-02

From: Tom Pusateri <[email-masked]>
Date: Thu, 20 Feb 2014 06:53:15 -0500

While this draft hasn't been accepted by the WG, Kerry thought that it would be ok to send questions about draft-cheshire-mdnsext-hybrid-02 since the expertise is here.

My testing shows that all unicast DNS queries for services come from the main DNS server that holds the NS record for the subdomain used by the hybrid proxy. This makes it impossible to determine the source of the request because the DNS packet itself doesn't contain the unicast client address.

1. This could be due to a misconfiguration on my main DNS server so I was wondering if this expected or do I have something setup wrong. In other words, should remote unicast clients be talking directly to the hybrid proxy or should their requests go through the main DNS server which they discover typically through DHCP?
This could be cleared up in section 3.

2. If client requests are always relayed through the main DNS server, then on the bottom of page 3 in section 3, it would be difficult to determine if "private addresses from one private address realm should not be communicated to clients in a different private address realm. It would also be more difficult to do filtering at the hybrid proxy.

3. The top of section 3 says that each link should be assigned a DNS subdomain. But then section 6 alludes to problems with IPv4 and IPv6 sharing the same subdomain name. After reading it many times and implementing it with a single subdomain name for both IPv4 and IPv6 on the same link, I haven't come across any problems. I think section 6 undoes a bit of the clarity in section 3 on this topic could be reworded so that sharing a DNS name for IPv4 and IPv6 is expected.

Thanks,
Tom

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 20 Feb 2014 19:54:48 +0200

> 2. If client requests are always relayed through the main DNS server, then on the bottom of page 3 in section 3, it would be difficult to determine if "private addresses from one private address re…

Very few clients themselves are recursive resolvers. And I don’t expect them to be.

But I suppose it depends on topology you’re discussing, but e.g. in our homenet-related effort, all DNS traffic goes as follows:

1. [client]
 |
2. [dns forwarder (dnsmasq)]
 |
3. [dns forwarder (dnsmasq)]
|
4. [link-specific subdomain hybrid proxy (ohybridproxy[1]) listening at e.g. 127.0.0.2]

3/4 are in our case always colocated; 2 and 3 may be same thing, if local lookup, or on different routers in the home.

(Similarly, 3 could be in someone else’s home ;->)

I would say that only sensible place to do filtering is in dns forwarding/server components, and keep hybrid proxy as simple as possible.

> 3. The top of section 3 says that each link should be assigned a DNS subdomain. But then section 6 alludes to problems with IPv4 and IPv6 sharing the same subdomain name. After reading it many time…

The problem lies mostly in how mDNS is specified (ships passing each other in the night and so on), but as both v4 and v6 mdns can contain either information (and typically implementations answer to both address families requests as well), I don’t think there is a big _real_ problem there. I would assume that v4-only and v6-only clients might result in naming issues, though. 

e.g. ‘device.example.com’ has A record of 1.2.3.4 owned by device A in IPv4 mDNS, and AAAA record of dead:beef::1 owned by device B in IPv6 mDNS; given this, some user unhappiness may ensue (assuming both implementations support only one AF and therefore don’t defend their names against each other.)

Cheers,

-Markus

[1] https://github.com/sbyx/ohybridproxy

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 24 Feb 2014 18:11:46 -0500

> Very few clients themselves are recursive resolvers. And I don’t expect them to be.

If this were true, what would be the point of implementing LLQ in the proxy? Will a typical client (workstation looking for a printer, etc.) running today's code resolve the name server of the subdomain and then try to setup an LLQ with the hybrid proxy according to the procedure described in the LLQ draft Section 4.1?

When I sent this note originally, I hadn't read that section but now that I'm implementing LLQ, it seems like the client will talk directly to the hybrid proxy if LLQ is supported.

Then filtering becomes possible (and even necessary) in the hybrid proxy.

Tom

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 25 Feb 2014 10:41:56 +0200

On 25.2.2014, at 1.11, Tom Pusateri <[email-masked]> wrote:
> If this were true, what would be the point of implementing LLQ in the proxy? Will a typical client (workstation looking for a printer, etc.) running today’s code resolve the name server of the subdomain and then try to setup an LLQ with the hybrid proxy according to the procedure described in the LLQ draft Section 4.1?

In my experience, most common clients don’t try to set up LLQ at all. Your mileage may vary though.

> Then filtering becomes possible (and even necessary) in the hybrid proxy.

You can also do ‘LLQ relay/proxy’ by providing LLQ at DNS server on your policy domain boundary, and then LLQ at hybrid proxy which is translation/filtering ignorant. (Obviously, hybrid proxy has to do _some_ filtering regardless due to e.g. linklocals and so on, but pushing and maintaining policy to large number of hybrid proxy nodes may be nontrivial exercise in a large network.)

Cheers,

-Markus