Discussion:
[Dnsmasq-discuss] Returning SOA for local domains?
Maxim Khitrov
2016-02-04 15:48:56 UTC
Permalink
When you configure a domain as local, meaning that dnsmasq will never
forward queries within that domain, there is no way to configure a
negative cache TTL value since there is no SOA record. As a result, I
frequently run into a problem where I try to ping/access a
non-existent DHCP lease (not acquired yet, forgot to reload dnsmasq,
whatever the reason) and the negative response gets cached locally
using some default TTL, which is much longer than I'd like it to be.
So even after the lease is acquired, I have to either wait several
minutes for the TTL to expire or manually flush the local cache.

Would it make sense to allow domains that are configured as local to
have a SOA record, with the negative cache TTL defaulting to the value
of --local-ttl? A --local-soa option could be added to enable and
control this explicitly.

I've thought about using the built-in authoritative server for this,
but the --auth-server option does not allow me to specify a
non-standard port, so I can't have it listen on 127.0.0.1:54, for
example. I could add another loopback IP, but this is now getting far
too complicated just to get a SOA record returned.

Thoughts?

-Max
Simon Kelley
2016-02-05 21:45:17 UTC
Permalink
Post by Maxim Khitrov
When you configure a domain as local, meaning that dnsmasq will never
forward queries within that domain, there is no way to configure a
negative cache TTL value since there is no SOA record. As a result, I
frequently run into a problem where I try to ping/access a
non-existent DHCP lease (not acquired yet, forgot to reload dnsmasq,
whatever the reason) and the negative response gets cached locally
using some default TTL, which is much longer than I'd like it to be.
So even after the lease is acquired, I have to either wait several
minutes for the TTL to expire or manually flush the local cache.
Would it make sense to allow domains that are configured as local to
have a SOA record, with the negative cache TTL defaulting to the value
of --local-ttl? A --local-soa option could be added to enable and
control this explicitly.
I've thought about using the built-in authoritative server for this,
but the --auth-server option does not allow me to specify a
non-standard port, so I can't have it listen on 127.0.0.1:54, for
example. I could add another loopback IP, but this is now getting far
too complicated just to get a SOA record returned.
Thoughts?
Worth some consideration. I worry that there are a lotr of fields in an
SOA record, and most of them would have to take synthetic values that
might come back and bite us later. It's all very well trying to pass a
negative-TTL to a stub resolver, which ignored most if the fields, but
what do we put in the nameserver field, for instance, and what could go
wrong if a recursive server, rather than a stub resolver is on the other
end?

Cheers,

Simon.

Continue reading on narkive:
Loading...