Home / server / Questions / 1053445
In Process
filimonic
Asked: 2021-02-13 08:57:18 +0800 CST

Are there any instruments for DNS rewrite?

  • 772

I have internal zone old-internal-domain.local. And we have records like server1.old-internal-domain.local and www.server1.old-internal-domain.local.

I want to make all records in old-internal-domain.local became accessible also in zone new-internal-domain.company.tld like server1.new-internal-domain.company.tld without copying records from old zone to new one.

I want something like dns rewrite rules, so when client queries server about server1.new-internal-domain.company.tld, server internally rewrites it into server1.old-internal-domain.local and resolves this. In response, it responds as server1.new-internal-domain.company.tld A 10.20.30.40

The key moment is to make it without creating copies of records.

It's better if I can use Windows DNS, but other software is OK too. Please advise.

  • This is not ActiveDirectory domain, just an ordinary DNS domain.
windows domain-name-system rewrite

1 Answers

  1. I solved a similar use case using BIND. In my scenario, an internal department name changed (and still does change frequently). But I didn't want to maintain old-dept-name and new-dept-name zone files.

    So, on my master DNS server, my zone files are defined as:

            zone "old-dept.companyname.net" {
            type master;
            file "GEN/companyname.net";
            allow-query { GEN-CLIENTS; };
            allow-transfer { 
                    key "GEN-KEY";
            };
            // also-notify avoids problems about NS complaints
            also-notify {
                    10.x.x.x key GEN-KEY;
                    10.x.x.x key GEN-KEY;
            };
    };

    zone "new-dept.companyname.net" {
            type master;
            file "GEN/companyname.net";
            allow-query { GEN-CLIENTS; };
            allow-transfer { 
                    key "GEN-KEY";
            };
            also-notify {
                    10.x.x.x key GEN-KEY;
                    10.x.x.x key GEN-KEY;
            };
    };

    Notice the same filename is used for both zones. NB: views are heavily used, which is what the GEN* stuff is about.

    The key then is on the slave servers to not use the 'file' directive more than once - otherwise you'll run into locking problems during replication. For such zones, the data only resides in RAM. It may not even be necessary to use it at all - it's been a while and I don't recall:

        zone "old-dept.companyname.net" {
            type slave;
            masters port 53 { 10.x.x.x key GEN-KEY; };
            file "GEN/companyname.net";
            allow-query { any; };
            notify no; 
    };

    zone "new-dept.companyname.net" {
            type slave;
            masters port 53 { 10.x.x.x key GEN-KEY; };
            // Notice there's no 'file' listed here - this prevents locking problems during replication
            allow-query { any; };
            notify no; 
    };

    It's not a perfect solution, but I can have nearly unlimited "mirrors" of the same zone. The RAM-based zones are not a concern since they reload from the master at a slave server restart/reload or when a zone is updated.

    Some drawbacks:

    • You may (depending on how it's configured) get some sketchy warnings about NS records being out of zone.
    • I'm using only static records - I have not tested using dynamic updates.
    • You have to make a decision about reverse lookups. Do you want PTR records to point to old-dept? new-dept? the short name? all? Any option is easily possible, but it IS a consideration.

    Good luck!

    • 1