Question about expected recursive resolver behavior

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about expected recursive resolver behavior

Sarah Newman
What should happen when for a given domain:

- The domain resolves via TCP but not UDP - UDP for this domain had no response at all.
- That authoritative nameserver hosts other domains, and those domains resolve via UDP.

I found https://www.isc.org/blogs/refinements-to-edns-fallback-behavior-can-cause-different-outcomes-in-recursive-servers/
but I'm not sure if this case is covered or not.

--Sarah
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Question about expected recursive resolver behavior

Chuck Aurora
On 2020-04-23 14:16, Sarah Newman wrote:
> What should happen when for a given domain:
>
> - The domain resolves via TCP but not UDP - UDP for this domain had no
> response at all.
> - That authoritative nameserver hosts other domains, and those domains
> resolve via UDP.

Do you have an example for this?  I don't get the "no response on UDP"
part.  If the same nameserver is answering other queries on UDP, why
wouldn't at least send a REFUSED reply?

Perhaps REFUSED has been disabled somehow; that could be tested by
querying it for other non-hosted zones,

dig @<that-NS> ns isc.org.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Question about expected recursive resolver behavior

Sarah Newman
On 4/23/20 12:41 PM, Chuck Aurora wrote:

> On 2020-04-23 14:16, Sarah Newman wrote:
>> What should happen when for a given domain:
>>
>> - The domain resolves via TCP but not UDP - UDP for this domain had no
>> response at all.
>> - That authoritative nameserver hosts other domains, and those domains
>> resolve via UDP.
>
> Do you have an example for this?  I don't get the "no response on UDP"
> part.  If the same nameserver is answering other queries on UDP, why
> wouldn't at least send a REFUSED reply?
>
> Perhaps REFUSED has been disabled somehow; that could be tested by
> querying it for other non-hosted zones,
>
> dig @<that-NS> ns isc.org.

Here is my example, but it's been fixed now:

https://prgmr.com/blog/2020/04/23/debugging-freebsd-resolution-failure.html

REFUSED hasn't been disabled.

I bring this up because we had customers complaining about our resolvers not working and I don't know if we could/should have done better.

--Sarah
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Question about expected recursive resolver behavior

Tony Finch
In reply to this post by Sarah Newman
Sarah Newman <[hidden email]> wrote:

> What should happen when for a given domain:
>
> - The domain resolves via TCP but not UDP - UDP for this domain had no
> response at all.

I would expect the domain to be completely unresolvable: the resolver will
only try TCP if it gets a truncated reaponse over UDP.

> - That authoritative nameserver hosts other domains, and those domains
> resolve via UDP.

The lack of response for some domains might cause problems for the other
domains if the resolver decides that the authoritative server is too
broken to bother asking.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Bailey: Variable 3 or less, increasing 4 at times. Moderate. Fair. Good,
occasionally poor.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users