Discussion:
[Dnsmasq-discuss] Rewrite TTL on MX RR
Anthony Brodard
2016-01-05 11:06:49 UTC
Permalink
Hi list !

I don't know if it's expected or if it's a bug, but I have a strange
behavior when I rewrite TTL values : some RR type keep upstream SSL (at
least mx, txt and soa).

For example :

$ dig mx gmail.com

;; ANSWER SECTION:
gmail.com. 1689 IN MX 10 alt1.gmail-smtp-in.l.google.com.
gmail.com. 1689 IN MX 30 alt3.gmail-smtp-in.l.google.com.
gmail.com. 1689 IN MX 20 alt2.gmail-smtp-in.l.google.com.
gmail.com. 1689 IN MX 40 alt4.gmail-smtp-in.l.google.com.
gmail.com. 1689 IN MX 5 gmail-smtp-in.l.google.com.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 05 10:51:29 CET 2016
;; MSG SIZE rcvd: 716


$ dig gmail-smtp-in.l.google.com.

;; ANSWER SECTION:
gmail-smtp-in.L.GOOGLE.com. 60 IN A 74.125.195.27

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 05 10:52:23 CET 2016
;; MSG SIZE rcvd: 246

I'm running on an old version provided on ubuntu LTS : 2.68-1ubuntu0.1, but
I don't notice anything in the changelog.

My conf :

$ cat /etc/dnsmasq.conf

resolv-file=/etc/resolv.dnsmasq.conf
listen-address=127.0.0.1
bind-interfaces
cache-size=1024
neg-ttl=20
max-ttl=60
max-cache-ttl=60
strict-order

Do you already see this behavior ? Is it normal/expected ?

Thank you !
Anthony Brodard
Simon Kelley
2016-01-06 18:30:29 UTC
Permalink
It's expected, in the sense that it's coded that way: dnsmasq doesn't
do anything with with replies to queries for anything other then A
(IPv4 address) and AAAA (ipv6 address) queries.

Now I think about it, I rather class this as a bug, and would like to
change the behaviour.

Thoughts, list?


Cheers,

Simon.
Post by Anthony Brodard
Hi list !
I don't know if it's expected or if it's a bug, but I have a
strange behavior when I rewrite TTL values : some RR type keep
upstream SSL (at least mx, txt and soa).
$ dig mx gmail.com
;; ANSWER SECTION: gmail.com. 1689 IN MX 10
alt1.gmail-smtp-in.l.google.com. gmail.com. 1689 IN MX 30
alt3.gmail-smtp-in.l.google.com. gmail.com. 1689 IN MX 20
alt2.gmail-smtp-in.l.google.com. gmail.com. 1689 IN MX 40
alt4.gmail-smtp-in.l.google.com. gmail.com. 1689 IN MX 5
gmail-smtp-in.l.google.com.
Tue Jan 05 10:51:29 CET 2016 ;; MSG SIZE rcvd: 716
$ dig gmail-smtp-in.l.google.com.
;; ANSWER SECTION: gmail-smtp-in.L.GOOGLE.com. 60 IN A
74.125.195.27
Tue Jan 05 10:52:23 CET 2016 ;; MSG SIZE rcvd: 246
2.68-1ubuntu0.1, but I don't notice anything in the changelog.
$ cat /etc/dnsmasq.conf
resolv-file=/etc/resolv.dnsmasq.conf listen-address=127.0.0.1
bind-interfaces cache-size=1024 neg-ttl=20 max-ttl=60
max-cache-ttl=60 strict-order
Do you already see this behavior ? Is it normal/expected ?
Thank you ! Anthony Brodard
_______________________________________________ Dnsmasq-discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Anthony Brodard
2016-01-08 09:16:48 UTC
Permalink
Hi Simon,

Thank you for your quick reply and explanation :-)
FYI, I've found one of your answer about this topic, 5 years ago :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579536#10

About changing the behavior, I think adding an option allowing to choose
which kind of queries must be cached can be a good improvement. Let's see
with the list.

Regards,
Anthony
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
It's expected, in the sense that it's coded that way: dnsmasq doesn't
do anything with with replies to queries for anything other then A
(IPv4 address) and AAAA (ipv6 address) queries.
Now I think about it, I rather class this as a bug, and would like to
change the behaviour.
Thoughts, list?
Cheers,
Simon.
Post by Anthony Brodard
Hi list !
I don't know if it's expected or if it's a bug, but I have a
strange behavior when I rewrite TTL values : some RR type keep
upstream SSL (at least mx, txt and soa).
$ dig mx gmail.com
;; ANSWER SECTION: gmail.com. 1689 IN MX 10
alt1.gmail-smtp-in.l.google.com. gmail.com. 1689 IN MX 30
alt3.gmail-smtp-in.l.google.com. gmail.com. 1689 IN MX 20
alt2.gmail-smtp-in.l.google.com. gmail.com. 1689 IN MX 40
alt4.gmail-smtp-in.l.google.com. gmail.com. 1689 IN MX 5
gmail-smtp-in.l.google.com.
Tue Jan 05 10:51:29 CET 2016 ;; MSG SIZE rcvd: 716
$ dig gmail-smtp-in.l.google.com.
;; ANSWER SECTION: gmail-smtp-in.L.GOOGLE.com. 60 IN A
74.125.195.27
Tue Jan 05 10:52:23 CET 2016 ;; MSG SIZE rcvd: 246
2.68-1ubuntu0.1, but I don't notice anything in the changelog.
$ cat /etc/dnsmasq.conf
resolv-file=/etc/resolv.dnsmasq.conf listen-address=127.0.0.1
bind-interfaces cache-size=1024 neg-ttl=20 max-ttl=60
max-cache-ttl=60 strict-order
Do you already see this behavior ? Is it normal/expected ?
Thank you ! Anthony Brodard
_______________________________________________ Dnsmasq-discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCAAGBQJWjV1FAAoJEBXN2mrhkTWiwhIP/j8ahr4kXvkpApoMzHt+psAS
V1GgvlHs4O5Tq/vGA0nNzxCADZS/fNpDzw+smkohAOrgRyCpUvl1g0hQxodIAlLG
V01oAxWvi97d+wV7S04KrZs5B6+R8D3IPZQ/yDLKSVKRvnIWQ8ddYs77nOto5JKN
r1f6B69RV8ypUN+cYQE3IF00tNeuDZYPpzi3Kk2IOi9a6USw91hD9ZIkrkrCMP3K
fm6uuoTCYBnrDQF+RviWg3Px54g1ln2lsjL/USObWp3LAXRJKKfRU+ST9aHdSGSp
/51m+0YbKnjpmVe0loZ7ynnkD3VpvgXOkWStTKrVefrxhU9RT2tAEiCP8hGaMIHu
7irzT4K5NFsAOfuHeotsfvrWdPgRFG/14oNzz/mElmAmz8TQnhqUApnx506m6QlS
2dFxtXMa/Ig/xSjL7WR6WrKfexkIM8ZhhobfCjeONe/yZtxIh9i+cg5dNYMgVRlR
ipMw1rGsugH2GkTKmJa2IW4rwxBa3QZCUptk7dXR5u7GOKeDqXFttuTKkJisTIwk
BhNTgux8g6fzVVn38td2Q2tIR4JE/S76MfoMVnUWRE4GCW4tqkFnNipb/mz3kSEs
Bn0ZYgLDn4wxInASBmQ+7GR3Gwb6bA3+Fk6EiCCDN8XiN8O4DvAkTcTTeUIwA+8w
V1SDSt4m2KvqYe+F+Tc/
=KQB2
-----END PGP SIGNATURE-----
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Simon Kelley
2016-01-09 18:29:31 UTC
Permalink
Post by Anthony Brodard
Hi Simon,
Thank you for your quick reply and explanation :-) FYI, I've found
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579536#10
I stand by that: I don't want to extend the cache to arbitrary RR
types. Note that dnsmasq _forwards_ any type of query and returns the
result. Only caching is limited to certain types.

TTL rewriting doesn't depend on caching, dnsmasq could easily rewrite
the TTL for RR types it doesn't know how to cache.
Post by Anthony Brodard
About changing the behavior, I think adding an option allowing to
choose which kind of queries must be cached can be a good
improvement. Let's see with the list.
Have you seen how many options dnsmasq has already? If there's one
sane way to do it, that should be how it's done.



Cheers,

Simon.
Post by Anthony Brodard
Regards, Anthony
It's expected, in the sense that it's coded that way: dnsmasq
doesn't do anything with with replies to queries for anything other
then A (IPv4 address) and AAAA (ipv6 address) queries.
Now I think about it, I rather class this as a bug, and would like
to change the behaviour.
Thoughts, list?
Cheers,
Simon.
Post by Anthony Brodard
Hi list !
I don't know if it's expected or if it's a bug, but I have a
strange behavior when I rewrite TTL values : some RR type
keep upstream SSL (at least mx, txt and soa).
$ dig mx gmail.com
;; ANSWER SECTION: gmail.com. 1689 IN MX 10
alt1.gmail-smtp-in.l.google.com. gmail.com. 1689 IN MX 30
alt3.gmail-smtp-in.l.google.com. gmail.com. 1689 IN MX 20
alt2.gmail-smtp-in.l.google.com. gmail.com. 1689 IN MX 40
alt4.gmail-smtp-in.l.google.com. gmail.com. 1689 IN MX 5
gmail-smtp-in.l.google.com.
;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;;
WHEN: Tue Jan 05 10:51:29 CET 2016 ;; MSG SIZE rcvd: 716
$ dig gmail-smtp-in.l.google.com.
;; ANSWER SECTION: gmail-smtp-in.L.GOOGLE.com. 60 IN A
74.125.195.27
;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;;
WHEN: Tue Jan 05 10:52:23 CET 2016 ;; MSG SIZE rcvd: 246
2.68-1ubuntu0.1, but I don't notice anything in the
changelog.
$ cat /etc/dnsmasq.conf
resolv-file=/etc/resolv.dnsmasq.conf
listen-address=127.0.0.1 bind-interfaces cache-size=1024
neg-ttl=20 max-ttl=60 max-cache-ttl=60 strict-order
Do you already see this behavior ? Is it normal/expected ?
Thank you ! Anthony Brodard
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Post by Anthony Brodard
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________ Dnsmasq-discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Loading...