search

each / draft-aname

work on a draft to standardize ANAME/ALIAS records to allow CNAME-like records at the zone apex
7 stars 4 forks source link

ANAME loop detection #45

Open fcelda opened 5 years ago

fcelda commented 5 years ago

ANAME loops are more difficult to detect in comparison to CNAME loops. If an authoritative server calls out to an external resolver then the authoritative server looses part of the processing context. This may result in DNS message multiplication and bouncing between the authoritative and the recursive.

This problem might be worth pointing out in the Security considerations.

One way to address this is to point all authoritative servers to a single resolver, make sure the resolver is capable of query de-duplication, and let the authoritative act on SERVFAIL (timeout) when resolving the ANAME.

BIND may have an advantage over the authoritative-only servers as it likely doesn't have to call out to other server.

vcunat commented 5 years ago

As suggested by Tony, one way to help would be to require returning the ANAMEs in the SERVFAIL. If you return an empty SERVFAIL to the client (the next link in the cycle chain), it will typically retry and it won't cache the failure for long, because it generally has no way of knowing that the error was some persistent condition. Eventually, it will give up and return SERVFAIL to the next link and it happens again - altogether you might get geometric amplification in each step. ANAME records returned in the SERVFAIL answer could serve as a proof in this case and propagate back to all the links in the chain - and be cached for their whole TTLs.

EDIT: I included considering chains that cross multiple providers, though that might not be a realistic scenario (I don't know).

Extended errors come to mind as well, but they might contain too little information to be as effective.

matje commented 5 years ago

@fcelda I am not sure if I fully understand the issue. Would you be willing to provide text for the Security Considerations section?

I do agree that mitigations are sane also outside the context of loop detection (single resolver, SERVFAIL on timeout).

What exactly do you mean with query de-duplication?

matje commented 5 years ago

Ping @fcelda

If I hear nothing back, I am inclined to close this issue.

fcelda commented 5 years ago

Thanks for the patience. Yes, I can write a few paragraphs on this topic.

matje commented 5 years ago

Jan, I think your mail to dnsop makes the loop detection issue more clear than described in #70. I would like to suggest to use that in the draft (https://github.com/each/draft-aname/pull/71) and push a -04 (before the cut off date). The solution for the loop detection needs to be determined, that will need to go in a -05.

Is that okay with you?

fcelda commented 5 years ago

@matje Sure. :rocket: