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.mcma...@oracle.com> wrote: -----
To: Jayashree Sk1 <jayashre...@in.ibm.com>, net-dev@openjdk.java.net
From: Michael McMahon <michael.x.mcma...@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
>   
>


Reply via email to