Read-only view of DNS entries on Support site

[gh5000]

Hi guys,

 

I've got a ticket open with Atomwide about them providing all of us with a read-only view of all DNS entries for a school. Currently, we can see DNS records only if they are associated with a firewall rule, but we can't see where other DNS records go to eg where the www. is pointing to, the MX, txt records etc.

 

To help Jamie (head of support) present a business case he has asked for some potential benefits for us.

 

The simplest one for me is when a 3PSO like myself or new nominated contacts (Network managers etc) take over a school they would be able to see existing records which aren't always documented.

 

I've got a couple of other benefits but what can you all come up with??

[howartp]

I'm with North Yorkshire Council, not LGfL, but I'm one of the few schools in NYCC who has access to modify my own DNS records on their system.

 

As we've moved suppliers for Broadband and separately for Spam (via a 3rd party), we've had a number of changes to make at critical points (ie "overnight tonight, we will switch"). I couldn't have done that without access to modify the system, but (if they won't give you that) at least with read-access I could confirm that the change they promised to make for me at 8pm (for example) had indeed been made.

 

I also had the ability to challenge whether DNS was working/replicating properly because their morning checks all worked correctly, but 50% of direct NS lookups still returned the old records - so it wasn't just propogation not working, the settings hadn't replicated from ns1 to ns2 even though all internal checks passed.

[PaddyNewman]

Hi,

 

As @ghanel has suggested, please do throw some reasoning our way!

 

By all means, we can provide you with a copy of the current zone file in a screen dump to assist, but having a read only view of your DNS records when no one is around could be helpful.

[Face-Man]

I take it you need more info than https://www.ultratools.com/tools/dnsLookupResult can provide for the school domain

[gh5000]

I take it you need more info than https://www.ultratools.com/tools/dnsLookupResult can provide for the school domain

Yeah, I do actually since those tools show me no A or CNAME records for LGfL hosted domains. Maybe @PaddyNewman could explain why

[FN-GM]

Can you not just use your domains registrar DNS settings and have full control yourself?

[gh5000]

Can you not just use your domains registrar DNS settings and have full control yourself?

You could. But I would say that this is more hassle for schools in general. The LGfL is the domain registrar for the borough addresses eg school.la.sch.uk and many more and moving them will be more of a problem when a new company or employee takes over the IT for a school. Plus when we do a firewall change request they can do the DNS records at the same time if needed.

 

Look essentially I believe that having this information readily available to key stakeholders is a good idea. As @PaddyNewman says yes we can ask for the information but that is their and the end-users time wasted waiting for the ticket response.

[PaddyNewman]

Yeah, I do actually since those tools show me no A or CNAME records for LGfL hosted domains. Maybe @PaddyNewman could explain why

@ghanel The lookup will look at the domain, it does the same for Atomwide.com for example. I know we have CNAME and A records, for www and webmail etc. This will only return the entries for that domain, treating www. differently.

 

Even with dig, CNAME records can't be reported back with a domain query. The only reliable way is zone transfer or using the AXFR option within a dig, but that's really old and probably not allowed by any DNS authority these days.

Having a read only view of all records is the fastest and easiest way to assist, no doubt. If you need something urgently however, feel free to contact me via support.

[FN-GM]

You could. But I would say that this is more hassle for schools in general. The LGfL is the domain registrar for the borough addresses eg school.la.sch.uk and many more and moving them will be more of a problem when a new company or employee takes over the IT for a school. Plus when we do a firewall change request they can do the DNS records at the same time if needed.

 

 

I would disagree but each to their own.

[gh5000]

I would disagree but each to their own.

Depends what the documentation is like on each of the places we go into. Never had a school with good documentation yet but may have just been unlucky.

 

The last school we took over had an domain hosted outside the LGfL. Took two weeks of back and forth with various third party hosting sites, website companies etc. Whois records went to a company that no longer existed. Eventually the website designer was able to find an email from 3 years ago where some other company and the old bursar had exchanged logon details for the registrar.

 

All I wanted to do was add a txt record for G Suite verification.

[minimoo]

@PaddyNewman @ghanel, In terms of business case - DNS system could do with an update. Whilst it's not that often, and I've not done it for a while - i've submitted 2-3 tickets over the years for a copy of our zone file for checking. If other schools do the same, that's a lot of work for support.

 

However, i'd probably argue that it's more important to allow schools the ability to change records in some way - or at least change some records.

 

I'm not sure how many schools are still doing their own hosting (either themselves or via azure et al) and using atomwide for DNS, but I'd argue now that schools should be running 100% HTTPS. That requires a certificate. Whilst you can pay for certificates, with Let's Encrypt offering free wildcard certificates with dns validation - but the certificates only last 3 months (you can renew over 1 month before expiry iirc - so that's 6 support cases a year for each wildcard certificate). In my case as we have *.domain and *.sub.domain, that's 12 support cases I will need to log each year. If for security we validate and our own records checking we ask to validate our dns zone once per year, that's 13 support tickets that would need to be raised per year.

 

Recognising that there is a security/configuration issue here and that atomwide may not want to allow full editing rights for that reason, it would be good if:

 

a) It was possible to see the existing zone

 

b) For things like g-suite verification @ghanel example above) and my let's encrypt example - that there was some ability to modify these by schools directly.

 

The let's encrypt application keeps running until the zone has been updated - whilst I assume it's sensible and generates an ID that lasts a week (or similar) - I've not tested/hit whether closing the app and restarting it would generate a new verification code; and therefore require a new support ticket...

[PaddyNewman]

However, i'd probably argue that it's more important to allow schools the ability to change records in some way - or at least change some records.

[...]Recognising that there is a security/configuration issue here and that atomwide may not want to allow full editing rights for that reason, it would be good if:

a) It was possible to see the existing zone

b) For things like g-suite verification and my let's encrypt example - that there was some ability to modify these by schools directly.

Valid points @minimoo

 

I'll be honest, being able to add TXT files for verification is a good idea from the verification side of things for Lets Encrypt and G Suite etc... but TXT also includes SPF and I've seen some REALLY dubious SPFs being passed over to us for addition, if they had added these themselves it would have had bad consequences. Such as being within LGfL StaffMail but adding a -all for the Google recommended SPF, or having multiple includes which exceeds the 10 lookup limit within a single one because they've omitted the first subdomain of the SPF lookup domain (I'm staring at one now) which cause a permanent error and fails SPF checking... sorry if I'm in the sucking eggs realm!

 

Whilst I appreciate there are a fairly big group of technically capable users within our supported schools, we also do have to cater for ones that really don't understand the concept of DNS and try to assist or at least guide down the correct path.

 

Few cases of bad requests, CNAME on the root domain, incorrect SPF etc are what we mostly see and we try to remedy these requests and advise the customers beforehand.

 

I do think visible records would be helpful for the majority. I can't think of a logical way to let users manage their own DNS though without having their domain sent elsewhere as its an internal DNS system but I'll certainly feed this one back for you.

 

Any other suggestions?

 

Thanks

Paddy

[minimoo]

@PaddyNewman - your reasons was why i'd probably do a mix (even if the techie users would hate) - e.g. promoting that https is free and easy might be good thing for some schools to be aware of (although i'd probably argue them not running a web server might also be a good idea in that case )

 

There's actually an open source system ( https://www.vinyldns.io ) used by comcast in the US - that is apparently used by 'thousands of engineers'. They have a system where you can define ACL rules to apply to a zone file i.e. screenshot in https://www.vinyldns.io/portal/manage-access . A concept like that could be used to address the issues you hit.

 

Only other suggestion I would have would be do if showing visible records, whether it's worth having some audit rules for good practice against the domain. For example, if I put our domain into https://mxtoolbox.com/domain - it tells me that:

 

a) our domain can't be resolved without http://www.* (I'll put in a ticket for that on monday I think!)

b) there's no DMARC record

c) we don't have a dmarc quarantine/reject policy

d) SOA refresh value is outside recommended range (I suspect that's deliberate by atomwide!)

e) SOA Expire value is out of recommended range

 

and then that mx.lgflmail.org reverse dns does not match the smtp banner, and a transaction warning time for smtp

 

So using your example, if a user viewing their zone did not have a SPF record set and they've got MX records configured on the domain , you could highlight that they might consider whether they want a SPF.

 

Having a school's version would mean D/E could be ignored and you could focus on what might be important for schools e.g. required g-suite/office365 dns entries that are missing - or even I saw mention of the adobe offer needing a DNS update...)

[PaddyNewman]

 

a) our domain can't be resolved without www.* (I'll put in a ticket for that on monday I think!)

b) there's no DMARC record

c) we don't have a dmarc quarantine/reject policy

d) SOA refresh value is outside recommended range (I suspect that's deliberate by atomwide!)

e) SOA Expire value is out of recommended range

@minimoo What happens when you pop your domain into - https://intodns.com

 

a) Raise a case, I'll make it so it just redirects to the www if you want?

b) Doesn't matter too much unless you know what you want?

c) as above really.

d) intodns doesn't complain about it, unless your domain differs to our lgflmail.org one.

e) same as above.

 

Feel free to raise a case for my attention and I'll use our redirector to just flip it to www if you want.

 

I'll take a look at vinyldns, the problem I would expect is that we would need to embed with USO, it would require serious work and integration to get this working but its definitely worth a look, I can pass that on anyway for consideration.

 

Thanks

Paddy

[minimoo]

@PaddyNewman - it gives a nice green tick for everything apart from:

 

TLD Parent Check - WARNING: Looks like the parent servers do not have information for your TLD when asked. This is ok but can be confusing.

SOA Refresh - WARNING: Your SOA REFRESH interval is: 900. That is not so ok

SOA Expire - Your SOA EXPIRE number is: 86400. That is NOT OK

 

The point I was more trying to make is whether there are settings that may be good practice that a custom system could encourage. I'm not fussed about these, but for example, I know we don't have DNSSEC enabled on our domain, and i'm not sure I've ever requested SPF records - the 2nd one we probably should do, the former probably less so

[DavidYoung]

@PaddyNewman - it gives a nice green tick for everything apart from:

 

TLD Parent Check - WARNING: Looks like the parent servers do not have information for your TLD when asked. This is ok but can be confusing.

SOA Refresh - WARNING: Your SOA REFRESH interval is: 900. That is not so ok

SOA Expire - Your SOA EXPIRE number is: 86400. That is NOT OK

 

The point I was more trying to make is whether there are settings that may be good practice that a custom system could encourage. I'm not fussed about these, but for example, I know we don't have DNSSEC enabled on our domain, and i'm not sure I've ever requested SPF records - the 2nd one we probably should do, the former probably less so

 

I've just run a check against our domain which is not hosted with LGfL but with Cloudflare. We get the same first message and we do get an SOA warning (serial number). The SOA records are all to do with the internal management of multiple DNS servers so that's for the provider to worry about if it works then there's no problem.

 

I do, however, agree with you on SPF/DKIM/DMARC, which LGfL should be implementing by default. We have had a couple of schools having issues getting their messages rejected by Gmail because they don't have any authentication on their domain. We've had to request SPF records for each of these. @PaddyNewman, perhaps someone should go through and check that StaffMail domains have valid SPF records, and if DKIM can be set up, even better and Atomwide should probably have a way of monitoring DMARC for issues.

 

On the general DNS front, I think if you want to do anything particularly fancy then you can easily move your domain to another provider as I say, all ours are with CloudFlare and we have a fair few custom records. The example given of Lets Encrypt would work particularly well in this scenario as it is designed to be automated and CloudFlare has an API that you can use for this.

 

Atomwide's manual system is a safety net against silly mistakes, and that's why we are happy, with, for example, the firewall situation where it does take some time but I know that it is being double-checked by someone.

 

I would say that a read-only view like we have for firewall rules would be very useful, the example of MSPs being the obvious one and we are doing this a bit ourselves, so a tab on the LGfL deployment page would be helpful to see if anything different is going on.

[PaddyNewman]

@DavidYoung afraid I'm out of the office today but a quick one with the SPF, we can't assume schools only send via MailProtect, some have their domain posting from web hosts for website mailers and other places, we would impact that mail... Essentially we can't assume.

 

I know what you are saying though.. but it's above me politically I'm afraid!

[minimoo]

On the general DNS front, I think if you want to do anything particularly fancy then you can easily move your domain to another provider as I say, all ours are with CloudFlare and we have a fair few custom records. The example given of Lets Encrypt would work particularly well in this scenario as it is designed to be automated and CloudFlare has an API that you can use for this.

 

Originally, I went the route as atomwide/lgfl were saying at one point in time that they have their load-balancing firewalls in front - and therefore in a failover scenario implying the IP's could change.

 

Atomwide's manual system is a safety net against silly mistakes, and that's why we are happy, with, for example, the firewall situation where it does take some time but I know that it is being double-checked by someone.

 

Equally, I agree with you - the only issue is that we often find that we've missed something e.g. forgetting to update the lets encrypt certificate and needing an 'immediate' dns change to fix it; or that teacher/support company that needs to remote in to fix something / view a AQA web cast that they've paid for starting in 20 minutes. Whilst most of those scenarios describe an in-house issue, the manual side of it does slow down those scenarios.

 

I would say that a read-only view like we have for firewall rules would be very useful, the example of MSPs being the obvious one and we are doing this a bit ourselves, so a tab on the LGfL deployment page would be helpful to see if anything different is going on.

 

On that note - @PaddyNewman - I don't believe the firewall rules view is a 'live' view ? I seem to remember hitting an issue once where the information on the rules page didn't match the live rules; as we'd changed information in a seperate ticket - is that still the case? If so, a read-only dump of the action rules in place instead could also be useful!

[PaddyNewman]

@minimoo again out of office so replies aren't so plush, but if there are ever issues like that, call in and ask for me, I aim (as do our service desk team) to do a first call fix, but obviously if you want something done and it doesn't break core rules, please feel free to ask for me. I'm not saying it will 100% get done there and then as we often need written confirmation but I'll aim to get it working within a very short time.

 

@DavidYoung has unfortunately spent too long on the phone with me to the point my phone timed out, so I'm always down to assist!

 

Firewalls should be replicated there, it's a manual process, I make the fw change, I update the page, sometimes this gets missed or someone doesn't 'lock' it so it's not visible but we routinely check these. But yes, there is human error on that side, I'm guilty of it also.

[JohnJackson]

Interesting thread - I'll pick this up with Atomwide.

[Xur]

Thanks John. Having a read only view would be great. I keep my domains with Atomwide/LGfL as it keeps things simple and means if anything LGfL related did need changing they can just do it for me.

 

I've had numerous issues in the past with domains, from predecessors forgetting credentials to domain management to website hosts having control of domains/not wanting to relinquish that control. Having the domains with Atomwide avoids all this.

 

On the occasions that I do need a change, it's usually done within an hour of a case being logged and the extra layer of sanity checking is useful.

 

Being able to see a definitive view of all the records at any given time would be a great addition.

[JohnJackson]

Thanks. I will pick this up with Atomwide and see what we can do for you.

[JohnJackson]

PS have you tried this tool? https://mxtoolbox.com/

[Xur]

PS have you tried this tool? https://mxtoolbox.com/

 

Thanks again for picking this up John.

 

Yep, and it's really useful for checking a particular record but it doesn't give you all the records for a domain. If you use the lookup to check an LGfL domain for example, it won't provide a definitive list of all the DNS records.

[PaddyNewman]

@ghanel This should now be in place for you, on the support site under Service Desk > View DNS records.

 

Can you take a look and let us know if that helps?