On Thu, 17 Dec 2015 15:30:13 -0500 Thus spake Raul Miller <[email protected]>:
> On Thu, Dec 17, 2015 at 2:33 PM, Kyle Amon <[email protected]> wrote: > > An IP address can't get "resolved" by a nameserver. It is a > > nameserver's resolution terminus. But this is weird, so I'm open to > > suggestions on proper terminology. Converted, perhaps? > > Well... in RFC 1035, domain names could not be numeric. But this > constraint was relaxed for a variety of reasons. PTR records require > numeric subdomains. And RFC 1912 specifically mentions examples like > 3com.com, 411.org, 1776.com. > > So, now, for example, 127.0.0.1.example.com. could be syntactically > valid as a domain name. And, if you leave off the trailing dot on a > domain name, dns resolvers first try appending whatever has been > configured as the default domain and resolving that. > > In other words, one person could interpret something that looks like > an ip address to be part of a domain name even though another person > could reasonably think that this is completely invalid. > > It's easy to be sloppy with the rules when you do not have time to > read and understand them all -- especially when they were never > intended to be misused the way they are being misused. Yes, the domain naming rules have been considerably relaxed, as you point out, although the numeric prohibition obviously never applied to the in-addr.arpa domain in the first place, but an IP address is still never resolved to an IP address, as once it's an IP address, in whatever form, it is already maximally `resolved`, and regardless of whether DNS was ever involved or not. Malformed domain names are, well, malformed domain names, and misinterpretation is, well, misinterpretation. An IP address is an IP address, a domain name is a domain name, and never the twain shall rationally mix. Anything to the contrary is just conflation. No amount of misunderstanding, misinterpretation or dearth of time, will involve DNS in this... amonk@obsd4e ~ $ ping 0150.0xa7.25535 PING 0150.0xa7.25535 (104.167.99.191): 56 data bytes 64 bytes from 104.167.99.191: icmp_seq=0 ttl=255 time=0.117 ms On a hopefully more germane note, however, that is cut from an obsd 5.8 box, so failure is only when getaddrinfo() is involved. Inasmuch, it would seem reasonable to at least violate standard uniformly, or not at all, and particularly if security is to be cited as involved in the reasoning. --Kyle -- CA +1-778-819-UNIX www.backwatcher.com US +1-425-584-UNIX SIP [email protected] INUM +883-5100-0990-1657 ISN UNIX*1917 C*NET 1-731-UNIX GPG F36E1CAB / CF001165F36E1CAB 6050 05B7 9FF1 CC21 3F00 CEBB CF00 1165 F36E 1CAB OTR 1B8CA85B 9696C3E0 CDE79B77 52D5F7E6 5492DBE2 : jabber/backwatcher.org 5CF381C0 5F74307B 082E63E9 9EC509FA 85486180 : jabber/riseup.net 3614B012 C81F85FD 71FC48A4 75D88B91 A0203B51 : jabber/jabber.ru DC446975 0D1CC62D 092E633C 2E3D3D82 B4CE1C47 : freenode B4B825A3 086F0716 2CA55061 A0F521EB 54C0AB2F : oftc 744D942C D581087C ADDB11D2 E8E9FF59 B46481F3 : efnet 4443188D 5CA26B63 6327F9CD 3349C795 7743110D : facebook 4FB85A74 B2E1BBE3 20CD282E 8E8DD9B3 30EDAAC3 : google B0C46C9E DD3685C8 81182D51 B2D14BE9 A43CFE09 : icq 41D60F67 7441ACFF 32CC2BF7 4EE70B17 08DA044F : aim 30CD13B4 A25DAC7A 863F638A 9EE95FBB 15D320A9 : yahoo 9FE919C7 7FD23FCB 5FF12636 A1F571B9 104AE5C1 : skype
pgpkzbKyeM8QD.pgp
Description: OpenPGP digital signature
