java.net.UnknownHostException occurs after change date to the future

Question

A java.net.UnknownHostException occurs after following the instructions below:

Instructions:

1. Disconnect the computer from the Internet (eg: turning off the modem)
2. Change the OS date to 14 days in the future
3. Run the code below
4. Click the "Perform test" button
5. You will get an exception message, but that's right, because the internet is disconnected
6. Click OK in the message window
7. Reconnect the internet
8. Change the OS date back to today's date
9. Click the "Perform test" button
10. You will get an exception message, but you shouldn't, because the internet is connected
11. You can click the "Perform test" button again and again, getting always the same exception, despite being connected to internet.
12. If you test the the URL (http://test.com) at browser it will work

Why does this happen? I imagine that should not happen.

Simple Code:

public class TestUrlConnection{

public static void main(String[] args) {
    SwingUtilities.invokeLater(new Runnable(){
        @Override
        public void run(){
            createAndShowGui();
        }
    });
}

private static void createAndShowGui(){
    final JFrame frame = new JFrame("Test URL Connection");
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

    JButton btOk = new JButton("Perform Test");     
    btOk.addActionListener(new ActionListener(){
        @Override
        public void actionPerformed(ActionEvent e){
            try{
                String content = readContentFromTestUrl();
                if(content!=null)
                    JOptionPane.showMessageDialog(frame, "OK. URL Connection returned Content.\nContent length = "+content.length());
                else
                    JOptionPane.showMessageDialog(frame, "Content is null, but no exception");
            }
            catch(IOException exc){
                JOptionPane.showMessageDialog(frame, "Exception:\n\n"+stackTraceToString(exc));
            }
        }
    });

    frame.setContentPane(btOk);     
    frame.setMinimumSize(new Dimension(250,100));
    frame.setLocationRelativeTo(null);
    frame.setVisible(true);
}   

private static String readContentFromTestUrl() throws IOException{
    InputStream is = null;
    InputStreamReader isr = null;
    BufferedReader br = null;

    try {
        URL url = new URL("http://test.com");
        URLConnection urlConnection = url.openConnection();
        urlConnection.setUseCaches(false);

        is = urlConnection.getInputStream();
        isr = new InputStreamReader(is);
        br = new BufferedReader(isr);

        String inputLine;
        String content = "";

        while ((inputLine = br.readLine()) != null)
            content += inputLine + "\n";

        return content;
    }
    finally{
        if(is!=null){try{is.close();}catch(IOException e){e.printStackTrace();}}
        if(isr!=null){try{isr.close();}catch(IOException e){e.printStackTrace();}}
        if(br!=null){try{br.close();}catch(IOException e){e.printStackTrace();}}
    }
}

private static String stackTraceToString(IOException exc){
    exc.printStackTrace();
    StringWriter sw = new StringWriter();
    exc.printStackTrace(new PrintWriter(sw));
    String s = sw.toString();
    return s.substring(0, s.length()>600 ? 600 : s.length());
}

}

Answer 1

DNS queries are expensive and their results changes rarely, so almost every network implementations cache the DNS lookup results so that if you open 100 connections in a few seconds it does not have to do 100 DNS queries returning the same IP address.

Java implementation is not different, and it caches both positive and negative (failed) queries.

By default negative results gets cached for 10 seconds, but obviously your test pointed out that :

1. Whether a previously cached result is valid or not is checked when another lookup is perfomed, which is fine from an implementation point of view.
2. The cache was not build thinking of clock changes, so everyone changing live the date of a server running java network stuff should consider this, as well as many other software packages that don't take clock change into consideration.

So, what happens is that Java caches that test.com is unresolvable. It should be there only for 10 seconds, so it's placed there with a timestamp. The you change the clock, and this timestamp instead of invalidating after 10 seconds, probably invalidates after 14 days and 10 seconds.

You can see it is using a cached value because the first click on the button takes a lot of time, while the other clicks are almost istantaneous.

One simple solution, that also proves the problem is in the DNS cache, is to add this line as first line in your main :

java.security.Security.setProperty("networkaddress.cache.negative.ttl" , "0");

This tells java not to cache negative DNS results, and if you try you'll see it will behave as expected. However, disabling such caches can reduce your performances a lot, and cause security problems, so I would rather advice to restart your JVM (and most other long-running processes) if you suddenly change the date of your machines.