Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ANAME loop detection #45

Open
fcelda opened this issue Apr 2, 2019 · 6 comments
Open

ANAME loop detection #45

fcelda opened this issue Apr 2, 2019 · 6 comments

Comments

@fcelda
Copy link
Contributor

fcelda commented Apr 2, 2019

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
Copy link

vcunat commented Apr 2, 2019

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
Copy link
Collaborator

matje commented Jun 11, 2019

@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
Copy link
Collaborator

matje commented Jun 21, 2019

Ping @fcelda

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

@fcelda
Copy link
Contributor Author

fcelda commented Jun 21, 2019

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

@fcelda fcelda mentioned this issue Jul 1, 2019
@matje
Copy link
Collaborator

matje commented Jul 8, 2019

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 (#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
Copy link
Contributor Author

fcelda commented Jul 8, 2019

@matje Sure. 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants