Maintained by: NLnet Labs

query ip address

Tom Samplonius
Wed Sep 13 23:27:52 CEST 2017


  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


> On Sep 13, 2017, at 2:03 PM, Joe Williams <williams.joe at gmail.com> wrote:
> 
> Thanks to asking around on twitter I think we have the why, https://cr.yp.to/djbdns/namedroppers/20000220195445-21265-qmail@cr-yp-to <https://cr.yp.to/djbdns/namedroppers/20000220195445-21265-qmail@cr-yp-to>
> 
> https://twitter.com/jedisct1/status/908072827890405376 <https://twitter.com/jedisct1/status/908072827890405376>
> 
> On Wed, Sep 13, 2017 at 1:52 PM, Joe Williams <williams.joe at gmail.com <mailto:williams.joe at gmail.com>> wrote:
> Thanks for finding that Tom! 
> 
> On Wed, Sep 13, 2017 at 1:49 PM, Tom Samplonius <tom at samplonius.org <mailto:tom at samplonius.org>> wrote:
> dnscache is a pretty weird.  From the webpage at http://cr.yp.to/djbdns/dnscache.html <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.
> 
> 
> 
> 
>> On Sep 13, 2017, at 1:17 PM, Joe Williams <williams.joe at gmail.com <mailto:williams.joe at gmail.com>> wrote:
>> 
>> 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.
>> 
>> On Wed, Sep 13, 2017 at 1:05 PM, Tom Samplonius <tom at samplonius.org <mailto:tom at samplonius.org>> wrote:
>> 
>> > ;; 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
>> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20170913/9ce33566/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3862 bytes
Desc: not available
URL: <https://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20170913/9ce33566/attachment-0001.bin>