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 Select Expand

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 Select Expand

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]

I'll include some clearer instructions for the slave service, along with a complete list of supported record types when I push the release version out to the live site.

Just to clear some of the issues in the meantime

AXFR's need to be allowed from ns1.he.net (216.218.130.2) and only ns1.   ns1 will listen to notifys and pull when it is appropriate.

DNSSEC records can be stored and served, but no additional processing is performed.

The complete list of supported records:

A
AAAA
AFSDB
CERT
CNAME
DNSKEY
DNSSEC
DS
HINFO
KEY
LOC
MX
NAPTR
NS
NSEC
PTR
RP
RRSIG
SOA
SPF
SSHFP
SRV
TXT

We are working on adding additional record types through the interface.

Gary

[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]

Correct. I see DNSKEY and DS records in the table already.  These are likely slave zones that we've pulled.

Gary

[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

[gshaver]

The visual bug has been fixed.

Gary

[snarked]

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