Hello- Sorry for the wide blast (and long email), but perhaps some fellow .edu's can help us through this one.
I'm one of the DNS admins for wisc.edu. An academic group on campus has noticed an issue with the atecentral.net delegation, for which two of the listed NS are on campus. []$ dig atecentral.net NS +short dns2.scout.wisc.edu. <------------- on campus dns.scout.wisc.edu. <------------- on campus dns.axisdata.com. wisc.edu is authoritative for scout.wisc.edu and return the following correct A records []$ dig scout.wisc.edu NS +short | sort adns1.doit.wisc.edu. adns2.doit.wisc.edu. adns3.doit.wisc.edu. adns1.doit.wisc.edu:dns.scout.wisc.edu. 14400 IN A 144.92.170.201 adns2.doit.wisc.edu:dns.scout.wisc.edu. 14400 IN A 144.92.170.201 adns3.doit.wisc.edu:dns.scout.wisc.edu. 14400 IN A 144.92.170.201 adns1.doit.wisc.edu:dns2.scout.wisc.edu. 14400 IN A 144.92.170.203 adns2.doit.wisc.edu:dns2.scout.wisc.edu. 14400 IN A 144.92.170.203 adns3.doit.wisc.edu:dns2.scout.wisc.edu. 14400 IN A 144.92.170.203 []$ dig @144.92.170.201 atecentral.net NS +short dns.axisdata.com. dns.scout.wisc.edu. dns2.scout.wisc.edu. It appears that there is some bad glue "somewhere" and I'm having trouble finding where it is coming from. dig +norecurse @b.gtld-servers.net atecentral.net NS ... ... ;; ADDITIONAL SECTION: dns.axisdata.com. 172800 IN A 162.255.164.103 dns.scout.wisc.edu. 172800 IN A 144.92.170.199 <---------------- WRONG dns2.scout.wisc.edu. 172800 IN A 144.92.170.200 <---------------- WRONG note: local admins have enabled DNS servers on 170.199 and 170.200 as a short term measure until this can be resolved, so if you dig against those incorrect IPs directly you will get an answer (for now). We have asked the scout.wisc.edu folks to check the atecentral.net delegation and received the following response: "... I checked with Namecheap, where atecentral.net is registered, and they say that the glue record values are supplied to the root nameservers by the registrar for the top-level domain where the names are located (wisc.edu, in this case, so Educause/VeriSign) ...." And this matches my memory as well. As recent as June 2017 when an NS inside a .edu was also the NS for another domain (for example, a .org), wearing my wisc.edu DNS admin hat I would log into the educause domain portal and add/update glue, the production example being uwhealth.org which has NS inside the wisc.edu namespace. My suspicious is that the glue stuck in gtld is supplied by educause however educause (who recently went through a major facelift of their portal, net.educause.edu) is claiming no such thing has ever existed. I'm not convinced, but there is an off chance early senility is setting in. I have a screenshot from June 2017 (without URL, unfortunately) of our list of "glue" from what I'm 99% sure is the old net.educause.edu portal however educause is claiming adamantly (yes, we have escalated a ticket) that my screenshot is not from their old portal. I see other screenshots on the web of the old net.educause.edu website that shows basically the same design theme (color) as my screenshot. You'll note my screenshot from June 2017 from "somewhere" has the wrong IPs for dns.scout.wisc.edu and dns2.scout.wisc.edu. ours: https://stats.uwsys.net/educause-maybe.jpg found on web: https://image.slidesharecdn.com/edu-dnssec-151026011336-lva1-app6891/95/edu-dnssec-testbed-27-638.jpg?cb=1445822096 For info from an old thread related to a similar thing we did at wisc.edu ~10 years ago: https://arstechnica.com/civis/viewtopic.php?f=10&t=97332, but I digress. I can't dump the .edu zonefile and educause (for now) is denying culpability. My 'dig' foo is weak enough that I can't come up with a damning output to know where to go from here. Any ideas? -Michael _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
