DNS servers without proper DNS entries

RESOLVED FIXED

Status

RESOLVED FIXED
2 years ago
2 months ago

People

(Reporter: claudijd, Unassigned)

Tracking

Details

As part of an internal assessment, I was looking at our DNS services.  Some of which I was able to resolve DNS PTR records for but there is a large number of entries I was not able to lookup.

digi helped me out and pointed me to sysadmins/dnsconfig where I was able to find about 50% of them.

This is a two part request....

1.) The following DNS servers do not have reverse look ups, but I was able to find their forward lookups and provide them here. I'd like to request that for this list we simply register a PTR record for each of the IP => Name mappings in DNS...

10.240.0.1(No PTR Record) fw1.ops.pek2.mozilla.net
10.240.0.2(No PTR Record) fw1-0.ops.pek2.mozilla.net
10.240.24.1(No PTR Record) fw1.corp.pek2.mozilla.ne
10.240.24.118(No PTR Record) testing1.corp.pek2.mozilla.com
10.240.24.40(No PTR Record) ns1.corp.pek2.mozilla.com
10.240.24.41(No PTR Record) ns2.corp.pek2.mozilla.com
10.242.75.120(No PTR Record) infoblox1.private.tor1.mozilla.com
10.243.75.120(No PTR Record) infoblox1.private.par1.mozilla.com
10.244.24.6(No PTR Record) admin1a.corp.yvr1.mozilla.com
10.244.24.7(No PTR Record) admin1b.corp.yvr1.mozilla.com
10.245.24.6(No PTR Record) admin1a.corp.akl1.mozilla.com
10.245.24.7(No PTR Record) admin1b.corp.akl1.mozilla.com
10.245.75.120(No PTR Record) infoblox1.private.akl1.mozilla.com
10.247.75.120(No PTR Record) infoblox1.private.tpe1.mozilla.com
10.248.24.7(No PTR Record) admin1b.corp.pdx1.mozilla.com
10.249.75.120(No PTR Record) infoblox1.private.ber1.mozilla.com
10.249.75.5(No PTR Record) admin1.private.ber1.mozilla.com
10.249.75.6(No PTR Record) admin1a.private.ber1.mozilla.com
10.249.75.7(No PTR Record) admin1b.private.ber1.mozilla.com
10.253.75.120(No PTR Record) infoblox1.private.ber2.mozilla.com

2.) This set of DNS servers I was unable to find reverse or forward lookups on .40 and would like some help figuring out what they are so we can determine if they are valid DNS servers or whether they are just systems unnecessarily hosting DNS services.

10.239.75.120(No PTR Record) no forward
10.240.24.2(No PTR Record) no forward
10.242.32.6(No PTR Record) no forward
10.242.32.7(No PTR Record) no forward
10.244.32.6(No PTR Record) no forward
10.244.32.7(No PTR Record) no forward
10.244.40.6(No PTR Record) no forward
10.244.40.7(No PTR Record) no forward
10.245.32.6(No PTR Record) no forward
10.245.32.7(No PTR Record) no forward
10.245.40.6(No PTR Record) no forward
10.245.40.7(No PTR Record) no forward
10.247.24.6(No PTR Record) no forward
10.247.24.7(No PTR Record) no forward
10.247.32.6(No PTR Record) no forward
10.247.32.7(No PTR Record) no forward
10.247.38.227(No PTR Record) no forward
10.247.38.228(No PTR Record) no forward
10.247.40.6(No PTR Record) no forward
10.247.40.7(No PTR Record) no forward
10.249.30.235(No PTR Record) no forward
10.251.24.6(No PTR Record) no forward
10.251.24.7(No PTR Record) no forward
10.252.35.131(No PTR Record) no forward
Please run a MIG scan for all IT hosts containing the line "dns::secure" in the file "/var/lib/puppet/classes.txt", as that will help narrow this down to indicate which hosts have non-puppetized name servers.
:atoll - here are the result of that query...

$ ./mig file -path /var/lib/puppet -name '^classes\.txt$' -content 'dns::secure'
961 agents will be targeted. ctrl+c to cancel. launching in 5 4 3 2 1 GO
Following action ID 6637007032362.
961 / 961 [=================================================] 100.00 % 3/s 4m55s
100.0% done in 4m55.096761096s
961 sent, 961 done, 902 succeeded, 4 failed, 55 timed out
admin1b.private.tor1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:15:31.513014885 +0000 UTC, mode:-rw-r-----, size:2036] in search 's1'
ns1-rsync.private.scl3.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:29:10.143895315 +0000 UTC, mode:-rw-r-----, size:1564] in search 's1'
admin1a.private.ber1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:16:28.422954503 +0000 UTC, mode:-rw-r-----, size:2061] in search 's1'
admin1b.private.par1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:26:14.199466196 +0000 UTC, mode:-rw-r-----, size:2072] in search 's1'
akamai-ns1.dmz.scl3.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:12:09.99665036 +0000 UTC, mode:-rw-r-----, size:1500] in search 's1'
admin1b.private.ber1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:02:41.889766027 +0000 UTC, mode:-rw-r-----, size:2075] in search 's1'
ns1.dev.private.scl3.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:27:27.296459615 +0000 UTC, mode:-rw-r-----, size:1586] in search 's1'
ns1.private.scl3.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:24:12.253381677 +0000 UTC, mode:-rw-r-----, size:1512] in search 's1'
admin1b.private.tpe1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:09:10.468617207 +0000 UTC, mode:-rw-r-----, size:2036] in search 's1'
ns1.bughunter.ateam.phx1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:10:01.599873818 +0000 UTC, mode:-rw-r-----, size:1510] in search 's1'
admin1a.private.lon2.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:29:34.686392966 +0000 UTC, mode:-rw-r-----, size:1946] in search 's1'
admin1a.private.tor1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:34:52.827254685 +0000 UTC, mode:-rw-r-----, size:2050] in search 's1'
admin1a.private.sfo1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:09:31.61281643 +0000 UTC, mode:-rw-r-----, size:2194] in search 's1'
ns2.corp.pek2.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:26:27.01252626 +0000 UTC, mode:-rw-r-----, size:1328] in search 's1'
admin1a.private.pdx1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:36:36.419806578 +0000 UTC, mode:-rw-r-----, size:2184] in search 's1'
admin1b.private.akl1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:15:13.854128418 +0000 UTC, mode:-rw-r-----, size:2036] in search 's1'
ns2.private.scl3.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:21:45.278409703 +0000 UTC, mode:-rw-r-----, size:1498] in search 's1'
ns2.private.releng.scl3.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:32:38 +0000 UTC, mode:-rw-r-----, size:1516] in search 's1'
admin1a.private.par1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:22:21.236021977 +0000 UTC, mode:-rw-r-----, size:2072] in search 's1'
ns1.private.phx1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:26:45.927368319 +0000 UTC, mode:-rw-r-----, size:1520] in search 's1'
admin1a.private.yvr1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:24:14.079681647 +0000 UTC, mode:-rw-r-----, size:2036] in search 's1'
admin1a.private.mtv2.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:19:06.506723162 +0000 UTC, mode:-rw-r-----, size:2201] in search 's1'
admin1a.private.pek1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:03:55.391629821 +0000 UTC, mode:-rw-r-----, size:2089] in search 's1'
admin1b.private.sfo1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:27:01 +0000 UTC, mode:-rw-r-----, size:2180] in search 's1'
admin1b.private.ber2.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:21:16.859600849 +0000 UTC, mode:-rw-r-----, size:2063] in search 's1'
admin1a.stage.private.scl3.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:05:32.026360482 +0000 UTC, mode:-rw-r-----, size:1884] in search 's1'
ns2.private.phx1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:01:14.074371791 +0000 UTC, mode:-rw-r-----, size:1520] in search 's1'
ns2.bughunter.ateam.phx1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:34:20.310828066 +0000 UTC, mode:-rw-r-----, size:1510] in search 's1'
admin1b.private.pek1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:21:52.076705641 +0000 UTC, mode:-rw-r-----, size:2089] in search 's1'
admin2a.private.mtv2.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:05:43.292354319 +0000 UTC, mode:-rw-r-----, size:1952] in search 's1'
ns1.corp.pek2.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:02:53.552852082 +0000 UTC, mode:-rw-r-----, size:1328] in search 's1'
admin1b.private.pdx1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:07:44.538701421 +0000 UTC, mode:-rw-r-----, size:2216] in search 's1'
admin1a.private.ber2.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:34:32.776633126 +0000 UTC, mode:-rw-r-----, size:2063] in search 's1'
admin1b.private.mtv2.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:36:25.74796109 +0000 UTC, mode:-rw-r-----, size:2201] in search 's1'
admin1a.private.tpe1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:29:17.686722355 +0000 UTC, mode:-rw-r-----, size:2036] in search 's1'
admin1a.private.akl1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:14:32.73378807 +0000 UTC, mode:-rw-r-----, size:2036] in search 's1'
admin1b.private.yvr1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:10:22.25426867 +0000 UTC, mode:-rw-r-----, size:2036] in search 's1'
ns2.bughunter.ateam.scl3.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:30:34.808857232 +0000 UTC, mode:-rw-r-----, size:1540] in search 's1'
ns1.private.euw1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:04:23.583439707 +0000 UTC, mode:-rw-r-----, size:1490] in search 's1'
ns2.private.euw1.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:33:14.757096606 +0000 UTC, mode:-rw-r-----, size:1490] in search 's1'
admin1b.private.lon2.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:36:20.762138016 +0000 UTC, mode:-rw-r-----, size:1946] in search 's1'
ns1.bughunter.ateam.scl3.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:30:35.473871531 +0000 UTC, mode:-rw-r-----, size:1540] in search 's1'
ns1.private.releng.scl3.mozilla.com /var/lib/puppet/classes.txt [lastmodified:2016-07-28 20:24:56 +0000 UTC, mode:-rw-r-----, size:1516] in search 's1'
...or in a nicer format...

admin1b.private.tor1.mozilla.com
ns1-rsync.private.scl3.mozilla.com
admin1a.private.ber1.mozilla.com
admin1b.private.par1.mozilla.com
akamai-ns1.dmz.scl3.mozilla.com
admin1b.private.ber1.mozilla.com
ns1.dev.private.scl3.mozilla.com
ns1.private.scl3.mozilla.com
admin1b.private.tpe1.mozilla.com
ns1.bughunter.ateam.phx1.mozilla.com
admin1a.private.lon2.mozilla.com
admin1a.private.tor1.mozilla.com
admin1a.private.sfo1.mozilla.com
ns2.corp.pek2.mozilla.com
admin1a.private.pdx1.mozilla.com
admin1b.private.akl1.mozilla.com
ns2.private.scl3.mozilla.com
ns2.private.releng.scl3.mozilla.com
admin1a.private.par1.mozilla.com
ns1.private.phx1.mozilla.com
admin1a.private.yvr1.mozilla.com
admin1a.private.mtv2.mozilla.com
admin1a.private.pek1.mozilla.com
admin1b.private.sfo1.mozilla.com
admin1b.private.ber2.mozilla.com
admin1a.stage.private.scl3.mozilla.com
ns2.private.phx1.mozilla.com
ns2.bughunter.ateam.phx1.mozilla.com
admin1b.private.pek1.mozilla.com
admin2a.private.mtv2.mozilla.com
ns1.corp.pek2.mozilla.com
admin1b.private.pdx1.mozilla.com
admin1a.private.ber2.mozilla.com
admin1b.private.mtv2.mozilla.com
admin1a.private.tpe1.mozilla.com
admin1a.private.akl1.mozilla.com
admin1b.private.yvr1.mozilla.com
ns2.bughunter.ateam.scl3.mozilla.com
ns1.private.euw1.mozilla.com
ns2.private.euw1.mozilla.com
admin1b.private.lon2.mozilla.com
ns1.bughunter.ateam.scl3.mozilla.com
ns1.private.releng.scl3.mozilla.com
(In reply to Jonathan Claudius [:claudijd] (use NEEDINFO) from comment #0)
> 10.240.0.1(No PTR Record) fw1.ops.pek2.mozilla.net
> 10.240.0.2(No PTR Record) fw1-0.ops.pek2.mozilla.net
> 10.240.24.1(No PTR Record) fw1.corp.pek2.mozilla.ne
> 10.240.24.118(No PTR Record) testing1.corp.pek2.mozilla.com
> 10.240.24.40(No PTR Record) ns1.corp.pek2.mozilla.com
> 10.240.24.41(No PTR Record) ns2.corp.pek2.mozilla.com
> 10.242.75.120(No PTR Record) infoblox1.private.tor1.mozilla.com
> 10.243.75.120(No PTR Record) infoblox1.private.par1.mozilla.com
> 10.244.24.6(No PTR Record) admin1a.corp.yvr1.mozilla.com
> 10.244.24.7(No PTR Record) admin1b.corp.yvr1.mozilla.com
> 10.245.24.6(No PTR Record) admin1a.corp.akl1.mozilla.com
> 10.245.24.7(No PTR Record) admin1b.corp.akl1.mozilla.com
> 10.245.75.120(No PTR Record) infoblox1.private.akl1.mozilla.com
> 10.247.75.120(No PTR Record) infoblox1.private.tpe1.mozilla.com
> 10.248.24.7(No PTR Record) admin1b.corp.pdx1.mozilla.com
> 10.249.75.120(No PTR Record) infoblox1.private.ber1.mozilla.com
> 10.249.75.5(No PTR Record) admin1.private.ber1.mozilla.com
> 10.249.75.6(No PTR Record) admin1a.private.ber1.mozilla.com
> 10.249.75.7(No PTR Record) admin1b.private.ber1.mozilla.com
> 10.253.75.120(No PTR Record) infoblox1.private.ber2.mozilla.com

Thanks for doing the legwork on this. I added the PTR entries as requested.

> 
> 2.) This set of DNS servers I was unable to find reverse or forward lookups
> on .40 and would like some help figuring out what they are so we can
> determine if they are valid DNS servers or whether they are just systems
> unnecessarily hosting DNS services.

The .6 and .7 IPs are admin hosts for offices. In these cases it's likely that the admin host is using 802.11q and has layer2 connectivity to all of the local vlans in the office. In reality, only the private vlan should be responding to DNS queries but to make configuration easier we listen on 0.0.0.0:53.

I added forward and reverse for:

Created A/PTR entries for admin1a.corp.sfo1.mozilla.com/10.251.24.6
Created A/PTR entries for admin1a.corp.tpe1.mozilla.com/10.247.24.6
Created A/PTR entries for admin1a.voip.akl1.mozilla.com/10.245.40.6
Created A/PTR entries for admin1a.voip.tpe1.mozilla.com/10.247.40.6
Created A/PTR entries for admin1a.voip.yvr1.mozilla.com/10.244.40.6
Created A/PTR entries for admin1b.corp.sfo1.mozilla.com/10.251.24.7
Created A/PTR entries for admin1b.corp.tpe1.mozilla.com/10.247.24.7
Created A/PTR entries for admin1b.voip.akl1.mozilla.com/10.245.40.7
Created A/PTR entries for admin1b.voip.tpe1.mozilla.com/10.247.40.7
Created A/PTR entries for admin1b.voip.yvr1.mozilla.com/10.244.40.7

I think .32. is the guest vlan, and while these IPs are routable I'm not able to find any other DNS entries in the subnet so I'm wondering if the admin server should even have an IP in the guest vlan. These IPs need to be reviewed:

10.242.32.6
10.242.32.7
10.244.32.6
10.244.32.7
10.245.32.6
10.245.32.7
10.247.32.6
10.247.32.7

We'll need someone with tribal knowledge on these addresses:

> 10.239.75.120(No PTR Record) no forward
> 10.240.24.2(No PTR Record) no forward
> 10.247.38.227(No PTR Record) no forward
> 10.247.38.228(No PTR Record) no forward
> 10.249.30.235(No PTR Record) no forward
> 10.252.35.131(No PTR Record) no forward
10.240.0.1(No PTR Record) fw1.ops.pek2.mozilla.net
10.240.0.2(No PTR Record) fw1-0.ops.pek2.mozilla.net
10.240.24.1(No PTR Record) fw1.corp.pek2.mozilla.ne

These three ^^ should never have DNS service on them
James? ^^

10.240.24.118(No PTR Record) testing1.corp.pek2.mozilla.com

This one must be found and killed.

10.239.75.120(No PTR Record) no forward

Infoblox in London. Needs PTR record.

10.240.24.2(No PTR Record) no forward

Corp network in PEK2 - find and kill.

10.247.38.227(No PTR Record) no forward
10.247.38.228(No PTR Record) no forward

Guest network at the TPE1 office. Ignore.

10.249.30.235(No PTR Record) no forward

BER1 corporate network. Find and kill.

10.252.35.131(No PTR Record) no forward

Guest network at the MTV2 office. Ignore.
Flags: needinfo?(jbarnell)
No longer blocks: 1283119
The DNS servers in the office there were deployed as part of the gmail deployment they should be there.  Infra was involved in this way back when

(In reply to Michal Purzynski [:michal`] (use NEEDINFO) from comment #5)
> 10.240.0.1(No PTR Record) fw1.ops.pek2.mozilla.net
> 10.240.0.2(No PTR Record) fw1-0.ops.pek2.mozilla.net
> 10.240.24.1(No PTR Record) fw1.corp.pek2.mozilla.ne
> 
> These three ^^ should never have DNS service on them
> James? ^^
> 
> 10.240.24.118(No PTR Record) testing1.corp.pek2.mozilla.com
> 
> This one must be found and killed.
> 
> 10.239.75.120(No PTR Record) no forward
> 
> Infoblox in London. Needs PTR record.
> 
> 10.240.24.2(No PTR Record) no forward
> 
> Corp network in PEK2 - find and kill.
> 
> 10.247.38.227(No PTR Record) no forward
> 10.247.38.228(No PTR Record) no forward
> 
> Guest network at the TPE1 office. Ignore.
> 
> 10.249.30.235(No PTR Record) no forward
> 
> BER1 corporate network. Find and kill.
> 
> 10.252.35.131(No PTR Record) no forward
> 
> Guest network at the MTV2 office. Ignore.
Flags: needinfo?(jbarnell)
(In reply to Michal Purzynski [:michal`] (use NEEDINFO) from comment #5)
> 10.240.0.1(No PTR Record) fw1.ops.pek2.mozilla.net
> 10.240.0.2(No PTR Record) fw1-0.ops.pek2.mozilla.net
> 10.240.24.1(No PTR Record) fw1.corp.pek2.mozilla.ne

All of DNS in 10.240.0/24 was broken due to a inventory misconfiguration, this is now fixed:

https://inventory.mozilla.org/en-US/core/search/#q=zone=:0.240.10.in-addr.arpa

> 10.239.75.120(No PTR Record) no forward

Added both.

:michal`, what can I do to help find & kill these devices and get this bug closed out?
Flags: needinfo?(mpurzynski)
So we are left with 3 machines to be hunted down.


10.240.24.118(No PTR Record) testing1.corp.pek2.mozilla.com
10.240.24.2(No PTR Record) no forward

Corp network in PEK2 - find and kill.

10.249.30.235(No PTR Record) no forward
BER1 corporate network. Find and kill.


You can use infoblox/freeradius logs/mozdef logs/observium to find the MAC address and locate a switch where this device is physically connected. If we are lucky, that is, and they are not wireless.
Flags: needinfo?(mpurzynski)
I'm going through my team's queue and looking at oldbugs. Given inventory is dead and we're now on Infoblox, servers running dns::secure will be killed in October, is there anything left here?
:digi - it's been 2 years, I think we're good with calling this done or won't fix.  I would be much more in favor of just requiring that any of our assigned addresses in the DC have an associated reverse record as policy and then reporting on the exceptions rather than onesy twosie this anyways.  #hindsight
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → FIXED
(In reply to Jonathan Claudius [:claudijd] (use NEEDINFO) from comment #10)
> I would be much more in favor of just requiring that any of our
> assigned addresses in the DC have an associated reverse record as policy and
> then reporting on the exceptions rather than onesy twosie this anyways. 
> #hindsight

Good news - this is the default behavior in MDC[12].
You need to log in before you can comment on or make changes to this bug.