Subject: [dnssd] Hybrid Proxy SOA records

From: Tom Pusateri <[email-masked]>
Date: Wed, 3 Sep 2014 08:48:59 -0400

For each delegated subdomain, the hybrid proxy should provide an SOA record when queried. In the case of LLQ, a client can query a service with an SOA record type and either get back an SOA response in the answer section or is supposed to put the SOA for the subdomain in the authority section if LLQ isn't supported.

There are many recommendations out there for SOA response values but I was wondering if the Hybrid Proxy is in a unique enough position that the draft should provide guidance on the SOA response values.

Ripe has some recommendations here:

http://www.ripe.net/ripe/docs/ripe-203

But when does the serial number change in a dynamic proxy? The recommendations from Ripe seem too long for the hybrid proxy case.

Any clue would be helpful.

Thanks,
Tom

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 3 Sep 2014 16:08:19 +0300

For the record, I’m not that convinced SOA is that useful - I don’t implement LLQ and also no SOA for zones currently.

That said..

> http://www.ripe.net/ripe/docs/ripe-203

These figures are way off the mark for what hybrid proxy provides - for example, mdns maximum TTL is hour or two, and the recommendation has minimum TTL of 2 days.. :-p

> But when does the serial number change in a dynamic proxy? The recommendations from Ripe seem too long for the hybrid proxy case.

Constantly? Just calculate it as function of time? 

If you want to be fancy, it could be incremented every time you see mdns probe+announce steps occur, but someone may silently join or leave anyway so it wouldn’t be correct always at any rate. 

Cheers,

-Markus

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 4 Sep 2014 22:31:07 -0400

> On Sep 3, 2014, at 9:08 AM, Markus Stenberg <[email-masked]> wrote:
> 

I'm in the process of implementing LLQ so I want to make sure clients don't give up.

> If you want to be fancy, it could be incremented every time you see mdns probe+announce steps occur, but someone may silently join or leave anyway so it wouldn’t be correct always at any rate. 

Thanks for the suggestion.

It would not be hard to update a timestamp each time the cache changes on the interface. But the standard ascii format of YYYYMMDDNN where NN is a sequence number does not leave enough flexibility for lots of changes to the cache throughout the day. In this case, and since we are limited to 32 bits, it would be better to use the number of seconds since the epoch. The only restriction this provides is that you can't identify changes more than once per second and still be within 32 bits. But this isn't a realistic problem since you shouldn't have sub-second tracking.

Here's the default values I'm going to use. I'll make sure they can be overridden through configuration:

Serial: number of seconds since the epoch
Expire: 24 hours
Refresh: this is probably meaningless in the context of the proxy but I'll use 2 hours
Retry: this is also probably meaningless but I'll use 30 minutes
Min TTL: the default negative TTL [RFC 2308] could be used in the context of the proxy but this isn't clear because the NSEC records are impossible to proxy for since we don't know all of the records. I'll use 30 minutes.

Thanks,
Tom