List,
I am transitioning from dnscache to unbound and have noticed a difference in behavior that I need to address since I have a few systems using it. Querying dnscache using an IP as the question I get an answer back using unbound I do not. For instance:
$ dig @localhost 10.36.129.10
; <<>> DiG 9.8.1-P1 <<>> @localhost 10.36.129.10
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54502
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;10.36.129.10. IN A
;; ANSWER SECTION:
10.36.129.10. 655360 IN A 10.36.129.10
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Sep 13 12:42:03 2017
;; MSG SIZE rcvd: 46
Unbound responds with what I would have expected dnscache to respond with NXDOMAIN. I haven’t been able to track down where exactly this sort of behavior is defined in an RFC or etc. So far digging through the dnscache source hasn’t been fruitful either.
Anyone know if unbound can be configured to behave this way or know what dnscache might be doing here?
Thanks!
-Joe
;; ANSWER SECTION:
10.36.129.10. 655360 IN A 10.36.129.10
Looking at this answer, I’m not sure why anyone would want this behaviour?
Is dnscache trying to dampen RFC1918 A queries by doing this?
Tom
Thanks for the reply Tom, I wish I knew why as well. Right now I am just trying to make my unbound config backwards compatible to not break code that expects an answer for an IP address.
dnscache is a pretty weird. From the webpage at http://cr.yp.to/djbdns/dnscache.html …
“dnscache handles dotted-decimal domain names internally, giving (e.g.) the domain name 192.48.96.2 an A record of 192.48.96.2."
So it looks like dnscache will return a the IP address back for any A queries for a IP address. And it looks like it returns a basically infinite ttl.
Why do you need this behaviour? I used to use dnscache many years ago, but dropped it when powerdns-recursor became available. I never noticed this “feature”, and never had anything break when it went away.
Thanks for finding that Tom!
I haven’t seen a IP address in a MX record in the last 5 years. In the 16 years since that was written, the email world has changed a lot. Email systems are larger, and tend to run by email professionals who know the standards. This did not happen:
It's reasonably clear what will happen to this protocol in the future.
System administrators will continue to use dotted-decimal domain names.
There will be occasional failures from other MTAs running under other
DNS caches; the MTA implementors and the DNS implementors will react by
adding support. Eventually, no matter what DNSEXT does, dotted-decimal
domain names will be a de facto standard.
And the DNSEXT working group never changed the MX standard.
Sometimes it might better to go with the Standard way of doing things. You can’t keep adding non-standard cruft to your services, and expect a smooth lifecycle.
Tom
I haven’t seen a IP address in a MX record in the last 5 years. In
the 16 years since that was written, the email world has changed a lot.
Email systems are larger, and tend to run by email professionals who
know the standards. This did not happen:
It's reasonably clear what will happen to this protocol in the future.
System administrators will continue to use dotted-decimal domain names.
There will be occasional failures from other MTAs running under other
DNS caches; the MTA implementors and the DNS implementors will react by
adding support. Eventually, no matter what DNSEXT does, dotted-decimal
domain names will be a de facto standard.
And the DNSEXT working group never changed the MX standard.
Sometimes it might better to go with the Standard way of doing things.
You can’t keep adding non-standard cruft to your services, and expect a
smooth lifecycle.
Oh yes, I very much agree.
Speaking with Knot Resolver leader hat on, this is not going to be
supported by Knot Resolver (unless there is a published standards-track
RFC, of course :-)).
Petr Špaček @ CZ.NIC