Automation isn’t even that hard - just outsource (e.g. 6Connect). I get why some things stagnate & collect kruft. But it is actually EASIER, and probably cheaper (including people time), to have a 3rd party “just do it” when it comes to things like DNS & IPAM.
Then again, if everyone ran everything perfectly … oh, then I could retire. :-) -- TTFN, patrick > On Apr 30, 2019, at 8:12 AM, Jared Mauch <[email protected]> wrote: > > While at NTT and at Akamai we have managed to publish sane PTR records and > make the forward work as well. You need to automate it by pulling from your > router configuration database and publish to your DNS database. If you are > still doing either by hand then it’s time to make the switch ASAP. > > Sent from my iCar > > On Apr 29, 2019, at 4:13 PM, Eric Kuhnke <[email protected] > <mailto:[email protected]>> wrote: > >> I would caution against putting much faith in the validity of geolocation or >> site ID by reverse DNS PTR records. There are a vast number of unmaintained, >> ancient, stale, erroneous or wildly wrong PTR records out there. I can name >> at least a half dozen ISPs that have absorbed other ASes, some of those >> which also acquired other ASes earlier in their history, forming a turducken >> of obsolete PTR records that has things with ISP domain names last in use in >> the year 2002. >> >> >> >> On Mon, Apr 29, 2019 at 6:15 AM Matthew Luckie <[email protected] >> <mailto:[email protected]>> wrote: >> Hi NANOG, >> >> To support Internet topology analysis efforts, I have been working on >> an algorithm to automatically detect router names inside hostnames >> (PTR records) for router interfaces, and build regular expressions >> (regexes) to extract them. By "router name" inside the hostname, I >> mean a substring, or set of non-contiguous substrings, that is common >> among interfaces on a router. For example, suppose we had the >> following three routers in the savvis.net <http://savvis.net/> domain >> suffix, each with two >> interfaces: >> >> das1-v3005.nj2.savvis.net <http://das1-v3005.nj2.savvis.net/> >> das1-v3006.nj2.savvis.net <http://das1-v3006.nj2.savvis.net/> >> >> das1-v3005.oc2.savvis.net <http://das1-v3005.oc2.savvis.net/> >> das1-v3007.oc2.savvis.net <http://das1-v3007.oc2.savvis.net/> >> >> das2-v3009.nj2.savvis.net <http://das2-v3009.nj2.savvis.net/> >> das2-v3012.nj2.savvis.net <http://das2-v3012.nj2.savvis.net/> >> >> We might infer the router names are das1|nj2, das1|oc2, and das2|nj2, >> respectively, and captured by the regex: >> ^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$ >> >> After much refinement based on smaller sets of ground truth, I'm >> asking for broader feedback from operators. I've placed a webpage at >> https://www.caida.org/~mjl/rnc/ <https://www.caida.org/~mjl/rnc/> that shows >> the inferences my algorithm >> made for 2523 domains. If you operate one of the domains in that >> list, I would appreciate it if you could comment (private is probably >> better but public is fine with me) on whether the regex my algorithm >> inferred represents your naming intent. In the first instance, I am >> most interested in feedback for the suffix / date combinations for >> suffixes that are colored green, i.e. appear to be reasonable. >> >> Each suffix / date combination links to a page that contains the >> naming convention and corresponding inferences. The colored part of >> each hostname is the inferred router name. The green hostnames appear >> to be correct, at least as far as the algorithm determined. Some >> suffixes have errors due to either stale hostnames or incorrect >> training data, and those hostnames are colored red or orange. >> >> If anyone is interested in sets of hostnames the algorithm may have >> inferred as 'stale' for their network, because for some operators it >> was an oversight and they were grateful to learn about it, I can >> provide that information. >> >> Thanks, >> >> Matthew
