Secondary domain name service at dns.he.net

[snarked]

One thing that is not stated on the web pages (even those after logging on) is which IP addresses must be granted AXFR permission.  The answer will depend on how you pull the data.

Some services (e.g. everydns.net) pulls from a single address and internally distributes the zone to its four servers.  Other services (e.g. xname.org or my colocation facility's servers) require each name server be granted permission via IPv4 - and IPv6 AXFRs aren't used.

Therefore, for HE's DNS service, which set of addresses need permission?
(Please also add this information to the service's web pages.)


Also, the primary service indicates which DNS RR-types are supported through its interface.  However, there's no indication of what the secondary service supports; i.e. are all types supported by the name servers?  Are they DNSSEC aware?

[broquea]

When you click on "Add a new slave" you get the following text which clearly states what IP to allow:

Code:

Please enter the domain name in the space below. Enter the masters that we should pull from in the spaces provided below.

Please allow zone transfers from ns1.he.net (216.218.130.2).

In order to utilize the slave service your name server MUST allow zone transfers via IPv4. We are looking for a workaround for IPv6 only hosts.

Also questions/comments/bugs/feature requests etc are supposed to be emailed, since the forums are not 100% read all the time by the dns.he.net team:

Code:

Questions or comments regarding this tool should be directed to support@he.net.
Bugs or feature requests should be directed to dnsadmin@he.net.

[snarked]

OK.  I was looking at the pages before actually attempting to set up a secondary allocation.

In my opinion, telling the user which IP address must have access when actually attempting the transfer is a bit too late, as technically, it needs to be permitted BEFORE setting up the transfer.

I'll CC this to the dnsadmin mailbox.

[gshaver]

Re: Secondary domain name service at dns.he.net

[snarked]

Thank you Gary.

With the signed root in less than a month's time and .ORG being turned on this week for domains under it, I expect that there will be alot more DNSSEC traffic, so if the name servers are at least "DNSSEC aware" (meaning that they will serve such records but not necessarily validate them), such would be helpful.  If that's what you meant by stored and served, then that's probbly good enough for now. 

[gshaver]

Re: Secondary domain name service at dns.he.net

[snarked]

In the section of displaying a zone hosted at your free (to customers) DNS service (i.e. "https://dns.he.net/" interface), I noted what appears to be an error.

I have some hosts in a forward zone that have MX records with a priority of zero.  Instead of printing a zero, the output routine is printing a dash in the priority column.  The dash should be for records which have no priority field, but apparently, you're using it for priority zero as well, which is incorrect.

Under BCP, Internet hosts which do not receive mail may (or should) have an MX record with priority zero and pointing at the DNS root.  Those sending only mail internally to the host should have an MX record with priority zero pointing at localhost (which should be rejected under SMTP by all other hosts as unroutable or as a routing loop).

CC:  dnsadmin@he.net

[snarked]

...And as noted yesterday in e-mail, I agree:  fixed.