RFR: 8243376 java.net.SocketPermission.implies(Permission p) spec is mismatching with implementation
Michael McMahon
michael.x.mcmahon at oracle.com
Fri May 22 12:34:18 UTC 2020
Hi Jay,
What I was referring to is something different. DNS reverse lookups
don't use CNAME records. They use PTR records constructed from the IP
address
written in reverse and suffixed with .in-addr.arpa. So, to do a reverse
lookup
of 183.79.131.212, you must look for a PTR record at
212.131.79.183.in-addr.arpa
and this actually returns "f14.top.vip.kks.yahoo.co.jp" in your example
which is what Java considers to be the canonical name.
DNS reverse lookup is not always configured right, and it isn't for the
domain
you mentioned above. You can't do a forward lookup on the f14.top... name,
so Java does not return that name because it doesn't trust it and you only
get the IP address in the returned InetAddress object.
Here's a code snippet that illustrates this:
import java.net.*;
public class DNS {
public static void main(String[] args) throws Exception {
InetAddress[] addrs = InetAddress.getAllByName(args[0]);
for (InetAddress addr : addrs) {
System.out.println("addr = " + addr);
InetAddress a1 = InetAddress.getByAddress(addr.getAddress());
System.out.println("reverse = " + a1.getCanonicalHostName());
System.out.println("------------------------");
}
}
}
If you run the program above with a domain like "www.oracle.com"
you'll see the actual names where the site is hosted on akamai
and each IP address has a different canonical name.
I realise the mechanism is convoluted and possibly needs to be updated,
also the use of the "cname" variable in SocketPermission creates confusion
with CNAME records in DNS but for a specific point fix like this, we should
stick with how it works currently and I think we would now have the
possibility for multiple
cname objects in some cases so would have to allow for that wherever 'cname'
is used in SocketPermission.
- Michael.
On 22/05/2020 10:51, Jayashree Sk1 wrote:
> Hi Michael
>
> Below are my findings:
>
> 1. The fix would have to account for the possibility of multiple canonical names (obtained from DNS reverse lookup).
>
> Ans:
> There is no need for us consider the multiple addresses in getCanonName because, each of the multiple ip’s DNS reverse lookup with always give the same HostName using which we are obtaining our cname.
>
> if (init_with_ip) {
> cname = addresses[0].getHostName(false).toLowerCase();
> } else {
> cname = InetAddress.getByName(addresses[0].getHostAddress()).
> getHostName(false).toLowerCase();
> }
>
>
> Why?
> In the DNS server, the DNS services which keeps different Record files..
> - An A record for example.com pointing to the server IP address
> - A CNAME record for www.example.com pointing to example.com
>
> A CNAME record must always point to another domain name, never directly to an IP address.
>
> And from the RFC https://tools.ietf.org/html/rfc1034
>
> Multiple CNAME records for the same fully-qualified domain name is a violation of the specs for DNS. (Implying One HostName can have only one CNAME record)
>
> Quoth RFC 1034, Section 3.6.2:
> If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.
>
>
> Eg: (in my mac when i ran) dig www.yahoo.jp
> ...
> ;; ANSWER SECTION:
> www.yahoo.jp. 893 IN CNAME www.g.yahoo.co.jp.
> www.g.yahoo.co.jp. 53 IN A 118.151.231.231
> www.g.yahoo.co.jp. 53 IN A 182.22.40.240
> www.g.yahoo.co.jp. 53 IN A 182.22.39.242
> www.g.yahoo.co.jp. 53 IN A 182.22.59.229
> ...
>
> There can be only one www.g.yahoo.co.jp cname for www.yahoo.jp in the CNAME record.
> However in the A records the multiple IPs of www.yahoo.jp can be assigned to the CNAME
>
> I hope, i understood your point and have answered it right.
>
>
> 2. It might be better to build a test using the internal files based name service
>
> Sure Michael, I have started working on writing a testcase with internal files based name service.
>
>
> Thanks
> Jay
>
>
> -----Michael McMahon <michael.x.mcmahon at oracle.com> wrote: -----
> To: Jayashree Sk1 <jayashreesk at in.ibm.com>, net-dev at openjdk.java.net
> From: Michael McMahon <michael.x.mcmahon at oracle.com>
> Date: 05/21/2020 02:51PM
> Subject: [EXTERNAL] Re: RFR: 8243376 java.net.SocketPermission.implies(Permission p) spec is mismatching with implementation
>
> Hi Jay,
>
> A couple of comments. There are other places in SocketPermission which
> assume that the addresses array only contains one element, eg getCanonName()
> assumes there is only one such name. The fix would have to account for
> the possibility
> of multiple canonical names (obtained from DNS reverse lookup).
>
> Also, I think the test shouldn't have a dependency on a particular
> global domain
> name. It might be better to build a test using the internal files based
> name service
> which would be guaranteed to always work, and then we could use it to
> test some
> of these additional things that the fix needs, as I mentioned above.
>
> Regards,
>
> Michael
>
> On 21/05/2020 09:35, Jayashree Sk1 wrote:
>> Hello,
>>
>> Please review the fix and Jtreg testcase to the following issue:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8243376&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=rA_13vli8clPM_toR46hq8FVwH3XGr8z7cUfcQoqL-k&m=aWH8PKz-0I8zphO56V3Dq2BRiCQQkbLQjIp04REJjVk&s=zWis2zVPVOwXwEOufBgh11VAFvOaBXBD9bILVUy-Ns0&e=
>>
>> The proposed changeset is hosted at:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Evtewari_8243376_webrev_index.html&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=rA_13vli8clPM_toR46hq8FVwH3XGr8z7cUfcQoqL-k&m=aWH8PKz-0I8zphO56V3Dq2BRiCQQkbLQjIp04REJjVk&s=bsGw7kkG2YYxOKuVOHH_w2BBVeUyfIhdlNt8o8Y0cXY&e=
>>
>> The scenario is:
>> - Some specified target hostname resolves to two IP addresses (always the same address pair).
>> - The DNS resolved order of the two ip addresses changes (a usual LoadBalancer type behavior).
>> - The CNAME of the two ip addresses differ.
>>
>> In SocketPermission class(void getIP() method), it internally resolves and saves only the first IP address resolved, not all the IP addresses resolved.
>> - Depending on when the implier/implied SocketPermission hostname is resolved, the resolved addresses order differs, and the internally saved IP address mismatches, resulting on SocketPermission#implies() false.
>>
>> So the fix is to:
>> Pass all the IP addresses of the specified target instead of just saving the first IP.
>>
>> Thanks
>> Jay
>>
>>
>
More information about the net-dev
mailing list