[Dnsmasq-discuss] strict-order still considered broken?

Discussion:

Thomas Eliasson

2015-09-22 12:55:56 UTC

Hi!

Just want to verify that there is no change regarding the 'strict-order'
option.

It's still considered broken, and not recommended for use?

Last note on this I found on the list was in 2009.

BR
/Thomas

Simon Kelley

2015-09-22 14:24:59 UTC

Permalink

The strict-order option does what it's documented to do, as far as I know.

If what you're actually asking is "does the strict-order option still
not allow me to give priority to a nameserver which has a different idea
of the DNS to the secondary nameserver(s)" then the answer to that is
that it still doesn't, and really can't.

The reason for this is that the transport for DNS is unreliable UDP, so
if queries for your "special" names go to the first nameserver and get a
special answer then sometimes, either the query or the reply will be
lost, and time-out, and then get sent to the secondary nameserver, which
will reply with a different answer to the one you wanted.

Cheers,

Simon.

Post by Thomas Eliasson
Hi!
Just want to verify that there is no change regarding the 'strict-order'
option.
It's still considered broken, and not recommended for use?
Last note on this I found on the list was in 2009.
BR
/Thomas
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Thomas Eliasson

2015-09-23 07:08:30 UTC

Permalink

In the posts from 2009 I got the impression the strict-order
functionality was generally broken.

What I did:
I tried querying the dnsmasq configured with two name-servers and
strict-order using python-dns's resolver.
When pulling the cable to the first name-server in the list, the query
times out.

After some investigation I found that dnsmasq identifies a query by
using the triple (source address, source port, CRC of the query-section).

The Python implementation resends the query with different source ports.
If I force the same source port, it works fine.

I'm worrying about how many clients will retry queries using different
source ports and thus not get serviced by my dnsmasq.

Is the identification of a retry standardized?
I could not find any information on this.
Otherwise I should probably not use strict-order if I'm not in control
of the clients.

/Thomas

Post by Simon Kelley
The strict-order option does what it's documented to do, as far as I know.
If what you're actually asking is "does the strict-order option still
not allow me to give priority to a nameserver which has a different idea
of the DNS to the secondary nameserver(s)" then the answer to that is
that it still doesn't, and really can't.
The reason for this is that the transport for DNS is unreliable UDP, so
if queries for your "special" names go to the first nameserver and get a
special answer then sometimes, either the query or the reply will be
lost, and time-out, and then get sent to the secondary nameserver, which
will reply with a different answer to the one you wanted.
Cheers,
Simon.

_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Simon Kelley

2015-09-26 20:46:33 UTC

Permalink

To be honest, I don't know. I've never tested. the Python behavour seems
to me to be strange: the original socket must still be open at timeout,
to receive the reply which never comes, so why not re-use it?

Of course, unless using strict-order, there's no practical difference
between sending two queries for the same name, and retrying a query, so
that's another good reason not to use strict-order.

Simon.

Post by Thomas Eliasson
In the posts from 2009 I got the impression the strict-order
functionality was generally broken.
I tried querying the dnsmasq configured with two name-servers and
strict-order using python-dns's resolver.
When pulling the cable to the first name-server in the list, the query
times out.
After some investigation I found that dnsmasq identifies a query by
using the triple (source address, source port, CRC of the query-section).
The Python implementation resends the query with different source ports.
If I force the same source port, it works fine.
I'm worrying about how many clients will retry queries using different
source ports and thus not get serviced by my dnsmasq.
Is the identification of a retry standardized?
I could not find any information on this.
Otherwise I should probably not use strict-order if I'm not in control
of the clients.
/Thomas