Re: [dns-privacy] Alternative signalling propsals

On Fri, Dec 14, 2018 at 12:43 PM Reed, Jon <jreed@akamai.com> wrote:

> I'd like to start a thread about alternatives to encoding fingerprints in
> NS names.  As I noted in the  meeting (unless I'm significantly
> misunderstanding the proposal), this is a non-starter for large operators
> like us.  It's not feasible to get our customers to change every NS record
> in their thousands of domains, and there's no way to do any sort of
> incremental rollout.  Customers are reluctant to even finish KSK rotations
> (by updating the DS in the parent), I can't imagine trying to get them to
> update NS records to enable this feature, let alone update them for an
> emergency keypair rotation.
>
> We use the encoding in our infrastructure zone that hosts customer
> authoritative NS names (in this case, akam.net), but that creates a gap
> in the chain.
>
> On the call, someone (Wes?) proposed an alternative such as records in the
> reverse zones.   That would be a huge win for us, since we have a small
> finite set of nameserver IPs, and easily control our reverse zones (as, I
> would imagine, do other large providers).  I wasn't in Bangkok, so I'm not
> sure if there were any specific implementation proposals kicked around, but
> I'd like to start talking about what that would look like.  Something
> TLSA-ish at the reverse name for the nameserver IP?   There's obviously
> some overhead with the recursive having to look up reverse names for NS
> IPs, but large TTL values could help with that.
>

One of the stated reasons for browsers not doing DANE / TLSA was having to
wait for the TLSA record to come back before you can connect.
"Ah! Fine..", says I, "Just do these in parallel -- you will get back the
TLSA record at about the same time as the A or AAAA. You could even be
smart and start making the TCP connection if you happen to get back the A
first. There, I fixed it for you...[0]".

Turns out this doesn't (or, at least, didn't) work -- yes, ~1/2 the time
the TLSA record will come in first, and ~1/2 the time it will be second --
but, when it is second:
A: you often don't know if it will ever show up
and
B: sometimes is it really really second / your query got lost and you need
to ask again, after a suitable backoff.

In a well functioning Internet you could do something clever like wait for
"a little bit more" than the time it took to get the A (1.5 times?) and, if
you haven't gotten an NXDOMAIN assume your query got lost -- unfortunately
the DNS is messy - a notable number of servers seem to not bother sending
NXDOMAIN, some middleboxes (or stupid implementations) drop Q types they
don't understand, etc.
Hopefully the world has gotten better since this research[1], and hopefully
the Recursive to Auth path is better then the Stub to Recursive path, but
it is definitely worth confirming / checking...

This sort of problem was one of the motivations for Wes and my Multiple
Responses (
https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/ ,
https://datatracker.ietf.org/meeting/96/materials/slides-96-dnsop-6 )
and various other solutions, including multiple Q types, etc
(https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/,
https://datatracker.ietf.org/meeting/99/materials/slides-99-dnsop-sessb-multiple-responses-multi-qtypes-00

W
[0]: "Oh, that was easy," says I, and for an encore went on to prove that
black is white and got myself killed on the next pedestrian crossing.”
(with apologies to Douglas Adams)
[1]: Citation needed :-). I've seen a number of papers showing the DNS long
tail - I think Giovane was the author of at least one...

>
> -Jon
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf