DNS and private rfc1918 addresses

Discussion in 'Broadband' started by Chris Davies, Jan 12, 2015.

  1. Chris Davies

    Chris Davies Guest

    Can anyone cite me a reference that states definitively whether a DNS
    proxy, such as one run by an ISP, is permitted to ignore valid lookups
    that result in an address within RFC1918 space. Please?

    For reasons related to Windows, VPN, and non-technical users, we provide
    internally-valid 10.x.x.x addresses in response to lookups in the public
    DNS for certain hosts in our domain. At least one UK ISP refuses to return
    these A records, claiming that they are private address space (which they
    are) and so can't be routed over the Internet. This is causing frustration
    for our users who have this ISP at home and want to VPN to our office.

    (I can give more details, but I'm concerned this post is already too
    long.)

    Much appreciated,
    Chris
     
    Chris Davies, Jan 12, 2015
    #1
    1. Advertisements

  2. Chris Davies

    Chris Davies Guest

    Yep. We do have VPN to a central point. The problem is that on Windows
    (at least), web browsers cache name/address lookups rather than deferring
    all name/address lookups to the PC's DNS subsystem. The scenario that
    gets our users upset is this fairly typical one:

    - User opens web browser and loads Intranet page
    - Web browser uses DNS to look up name and gets "no such name",
    because it's not in our external DNS
    - User remembers to start VPN client and tries web browser again
    - Web browser knows there's no such host name, so refuses to try again
    - User gets frustrated

    With the scenario that we can deliver the RFC1918 address for our Intranet
    over the public DNS we get this instead:

    - User opens web browser and loads Intranet page
    - Web browser uses DNS to look up name and gets RFC1918 address. Web
    browser attempts to load page but fails because there's
    (correctly) no route to an RFC1918 address over the Internet
    - User remembers to start VPN client and tries web browser again
    - Web browser has a valid name/address lookup and so tries again. With
    success this time
    - User is happy

    The killer is that web browsers do not honour DNS negative-cache TTL, so
    we can't even drop that down to a low value such as 60 seconds. I can't
    control the users' home PCs (and don't want to, even if I could), so any
    per-user solution has to be something I can suggest rather than mandate.

    It gets worse for corporate laptops, etc., where it's quite likely that
    the browser's home page will be our Intranet.

    Not an option for home users, thanks.

    We don't want to expose the Intranet to the world at large, and given that
    as part of our "business" we allow people to sponsor children in certain
    poorer countries the implications of the Intranet content leaking are
    pretty painful. The majority of our home users are on DHCP so it's not
    possible to identify them by address. We could demand username/password
    lookups to access the Intranet (and associated resources) but that feels
    to me like we're broadening the potential attack surface area.

    Chris
     
    Chris Davies, Jan 12, 2015
    #2
    1. Advertisements

  3. Chris Davies

    Chris Davies Guest

    Sounds like Plusnet then.

    Yep. It is PlusNet. I've had a ticket open on this but I'm not
    convinced that anyone in infrastructure read what I was trying to
    do, before returning it to 1st Line with a "we won't route private
    addresses". However, I was originally trying to keep PlusNet's name out
    of the discussion, since I don't see the value in whinging publicly when
    I've already had the conversation as a customer.

    On the other hand, asking people for solutions seemed to me to be
    fair game...

    Windows based VPNs are generally happy to route queries to different
    resolvers depending on the domain. Linux-based ones have to be kicked
    to do this (usually by using something like dnsmasq on the client and
    pointing resolv.conf to 127.0.0.1).

    It doesn't help my problem as described in my (other) follow-up post,
    though :-(

    Chris
     
    Chris Davies, Jan 12, 2015
    #3
  4. Chris Davies

    Davern Guest

    The last 2 paragraphs of Section 3, RFC1918, appear to answer your
    question directly:-

    "Because private addresses have no global meaning, routing information
    about private networks shall not be propagated on inter-enterprise
    links, and packets with private source or destination addresses
    should not be forwarded across such links. Routers in networks not
    using private address space, especially those of Internet service
    providers, are expected to be configured to reject (filter out)
    routing information about private networks. If such a router receives
    such information the rejection shall not be treated as a routing
    protocol error.

    Indirect references to such addresses should be contained within the
    enterprise. Prominent examples of such references are DNS Resource
    Records and other information referring to internal private
    addresses. In particular, Internet service providers should take
    measures to prevent such leakage."

    Whilst the precise meaning of the words 'routing information' might be
    open to some interpretation, the following paragraph seems to be
    unambiguous notwithstanding the use of the word 'should'.
     
    Davern, Jan 13, 2015
    #4
  5. Chris Davies

    Chris Davies Guest

    Users can remember something like intranet.example.org. They're less
    likely to remember something like 10.11.12.13. But it's an interesting
    option to consider.

    It's not the DNS cache that's the problem; it's the browser's
    reimplementation of the DNS cache that is that problem. This isn't
    accessible with ipconfig /flushdns.

    Don't know. Should know. I'll go find out.

    At the user's home it's not my PC. I really don't want to have to support
    other people's systems more than I have to.

    Thanks for the thoughts.
    Chris
     
    Chris Davies, Jan 13, 2015
    #5
  6. Chris Davies

    Graham J Guest

    I think this is a perfectly reasonable limitation by those ISPs.

    I can think of three ways to work around it - but without understanding
    your detailed requirements I'm not sure whether any would work.

    1) Use a dial-in VPN facility, into something like a Vigor V2830 router.
    The remote user has a dial-in VPN set up on his computer (you may need
    to do this for him) and once he connects he has an IP address on your
    office LAN, and his DNS server is your office DNS server (as specified
    by the setings in your router), so all the lookups for internal
    resources will work. Note that all his internet traffice will go
    through your office LAN and WAN for the duration of the connection.

    2) Use a LAN-to-LAN VPN, nailed up. This (almost certainly) means your
    remote user must have a static public IP address - with consequent
    benefits for your ability to help hom remotely. Also probably means he
    has to use a better class of ISP so will get improved reliability.
    Configure his router to point to your office DNS server. You provide
    hime with a router, pre-configured. The disadvantage of this is that
    ALL his internet traffic will go through your office LAN and WAN, so it
    will be measureably slower (limited by the UPload speed of your office WAN.

    I do this for a business with a remote office. It works adequately.

    3) Get several public IP addresses for those hosts you want to make
    available to your remote users. Configure a suitable router/firewall to
    allow traffic into those hosts from your remote clients (think Cisco).
    Then these hosts can have legitimate DNS lookups from anywhere.

    Does any of this help?
     
    Graham J, Jan 13, 2015
    #6
  7. Sounds like Plusnet then.

    I've a client setup like this because it saves having the remote users
    change their DNS to use the internal DNS servers when they connect up
    the VPN, so the few hosts they need access to are simply placed on the
    public DNS for the company.

    Works well - apart from one poor sod who uses Plusnet. I got him
    to change his DNS servers to googles and it now works fine for him.

    (We're using OpenVpn and Linux to Linux FWIW)

    Gordon
     
    Gordon Henderson, Jan 13, 2015
    #7
  8. I suspect it is. It's probably a nuance of the software we're using
    (PowerDNS I think).
    This seems a really shoddy way to do things IMO. I'm no expert on VPN
    configs, but I'm fairly certain there's a more graceful way to do this
    that doesn't involve using public DNS resolvers to return addresses for
    private/local host names.
    Can't the VPN be configured to assign different DNS addresses on connection?
     
    Plusnet Support Team, Jan 13, 2015
    #8
  9. Chris Davies

    Davern Guest

    On 13/01/2015 11:29, Plusnet Support Team wrote:
    [...]
    An OpenVPN server can, e.g.

    ....
    push "dhcp-option DNS 8.8.8.8"
    push "dhcp-option DNS 8.8.4.4"
    ....

    I can't confirm that it still works using a private IP address range but
    I can't see any reason that it wouldn't.
     
    Davern, Jan 13, 2015
    #9
  10. Chris Davies

    Graham J Guest

    Do you mean - tries to load Intranet page?
    because it's not in our external DNS


    [snip everything else]

    I think the key point here is that your intranet refers to itself by
    name, thereby forcing a name lookup. If it specified itself by IP
    address then the browser would attempt a direct connection - and of
    course fail until the user brought up the VPN (or bring up the VPN
    automatically in the case of a LAN-to-LAN arrangement).

    After that whatever it cached would work once the VPN was brought up.

    Is it possible to rewrite your intranet pages with hard-coded addresses?

    Other ideas:

    Have a script to bring up the VPN - in this have a line to flush the DNS
    cache once the VPN is up.

    Does restarting the browser flush its own cache (I think it does). So
    train the users to close and reopen the browser ...

    The LAN-to-LAN VPN is a really useful feature. You could suggest that
    if users cannot remember to bring up the VPN first (or at least not
    complain if they forget) then they are not competent to use the service
    you provide, so you insist that you put in place a management mechanism
    with which to support them.

    All sorts of things about Windows are beyond the average user, so remote
    management via VPN and VNC is very useful. I find it so much easier
    than trying to explain things by phone - you simply say "let go of your
    mouse and allow me to show you" With proper preparation, you can bring
    up the VPN and invoke VNC all within about ten seconds.
     
    Graham J, Jan 13, 2015
    #10
  11. Can't the VPN be configured to assign different DNS addresses on connection?[/QUOTE]

    Yes, but as far as I know only for all users, not some, and some users
    for various reasons don't want their dns servers changing. This is for
    a company who makes networking gear too..

    I understand not routing traffic to these IPs, but I can't see why
    a DNS lookup ought to be deliberately thwarted.

    Gordon
     
    Gordon Henderson, Jan 13, 2015
    #11
  12. Chris Davies

    Andy Burns Guest

    I may be at a customer site, using that customer's internal DNS to refer
    to their servers, with a VPN session established to our own servers, and
    wanting to access mail.internal.ourdomain.co.uk, which would be an
    RFC1918 address accessible over the VPN, but if the customer uses
    Plusnet and has forwarders to Plusnet's DNS, then it doesn't resolve
    anything from our .internal zone.
     
    Andy Burns, Jan 13, 2015
    #12
  13. Chris Davies

    Bob Eager Guest

    Would it be because, if more than one customer wanted this, it would be
    impossible to provide reverse DNS?
     
    Bob Eager, Jan 14, 2015
    #13
  14. Chris Davies

    Phil W Lee Guest

    Give them each a hosts file with your intranet servers in.
    Hosts comes before dns in windows lookup, so if the user hasn't
    brought up the vpn yet they should just get a timeout.
    Then when they bring up the vpn, a browser refresh should load the
    intranet homepage.
     
    Phil W Lee, Jan 14, 2015
    #14
  15. Use the hosts file?

    127.0.0.1 localhost.localdomain
    10.11.12.13 intranet.example.org

    You could supply users with a batch file or installer to make the
    necessary addition to the hosts file, then it's point'n'drool for them.
     
    Mike Tomlinson, Jan 14, 2015
    #15
  16. Chris Davies

    Graham J Guest

    Phil W Lee wrote:

    [snip
    [snip]

    This will of course work, but editing or replacing the "hosts" file is
    way beyond the average Windows user, so brings us back to the issue of
    properly supporting such users.

    It also is impossible where the user does not have administrative access
    to his machine - as would happen where the machine is controlled by the
    IT department of the user's employer. But then, this might also prevent
    the user from creating the necessary VPN.

    I think you have to make your intranet site available via your public
    website, using a suitable password mechanism - possibly a dongle of smme
    sort - so as to overcome the privacy issues you raised.
     
    Graham J, Jan 14, 2015
    #16
  17. Chris Davies

    Graham J Guest

    Chris Davies wrote:

    [snip]
    At present you are getting the blame for the user's incompetence.

    What is the relationship between you and the user? Is the user a
    colleague within the same business? Or a customer of your business?
     
    Graham J, Jan 14, 2015
    #17
  18. Chris Davies

    Davern Guest

    Yes, but as far as I know only for all users, not some, and some users
    for various reasons don't want their dns servers changing. This is for
    a company who makes networking gear too..

    I understand not routing traffic to these IPs, but I can't see why
    a DNS lookup ought to be deliberately thwarted.[/QUOTE]

    Because the private IPs are not globally unique. To quote RFC1918,
    Section 5 final 2 paragraphs:-

    "If two (or more) organizations follow the address allocation
    specified in this document and then later wish to establish IP
    connectivity with each other, then there is a risk that address
    uniqueness would be violated. To minimize the risk it is strongly
    recommended that an organization using private IP addresses choose
    randomly from the reserved pool of private addresses, when allocating
    sub-blocks for its internal allocation.

    If an enterprise uses the private address space, or a mix of private
    and public address spaces, then DNS clients outside of the enterprise
    should not see addresses in the private address space used by the
    enterprise, since these addresses would be ambiguous. One way to
    ensure this is to run two authority servers for each DNS zone
    containing both publically and privately addressed hosts. One server
    would be visible from the public address space and would contain only
    the subset of the enterprise's addresses which were reachable using
    public addresses. The other server would be reachable only from the
    private network and would contain the full set of data, including the
    private addresses and whatever public addresses are reachable the
    private network. In order to ensure consistency, both servers should
    be configured from the same data of which the publically visible zone
    only contains a filtered version. There is certain degree of
    additional complexity associated with providing these capabilities."

    Consider a simple example whereby you are sitting behind a NAT router
    which has the LAN address of 192.168.0.1, and you attempt a connection
    to xyz ltd. Upon your carrying out a DNS lookup, you are given the IP
    address for its intranet web server as 192.168.0.1. It would be a
    recipe for ever increasing confusion, hence the need to avoid ambiguity
    and for not propagating private IPs via public DNS servers.
     
    Davern, Jan 14, 2015
    #18
  19. Chris Davies

    Davern Guest

    On 14/01/2015 08:36, Andy Burns wrote:
    [...]
    Your own words underline the issue - "tend to avoid" and "judicious
    use". Welcome to the world of CGNAT and multinationals with very large
    private networks.
     
    Davern, Jan 14, 2015
    #19
  20. Chris Davies

    Andy Burns Guest

    Oh I realise the possible pitfalls, but in practice they /are/ generally
    avoidable, which makes it annoying when someone goes out of their way to
    make it impossible.
     
    Andy Burns, Jan 14, 2015
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.