Understanding cause of DNS format error (FORMERR)
Sam.Wilson at ed.ac.uk
Tue Jun 26 13:47:52 UTC 2012
In article <mailman.1143.1340715359.63724.bind-users at lists.isc.org>,
Gabriele Paggi <gabriele.pgi at gmail.com> wrote:
> Hello Sam,
> > There's some kind of delegation bug as well. If I query
> > dns1[0-3].one.microsoft.com for SOA and NS for
> > partners.extranet.microsoft.com you get sensible answers though the
> > origin host is different for each server queried and those origins are
> > privately addressed.
> Which kind of misconfiguration could lead to SOA records for hosts on
> the internet to be privately addressed?
> Misconfigured split horizon server?
It's not difficult for private addresses to escape. It need not actually
be a problem. It's not necessarily a problem here but it does make it
difficult to work out what's going on.
> > The authority for zero-answer responses such as
> > vlasext.partners.extranet.microsoft.com/IN/AAAA is the SOA for
> > partners.extranet.microsoft.com
> What do you mean with "authority for zero-answer responses"?
> What is the normal authority response I should get when querying for
> non-existent records?
For a NXDOMAIN response, or NOERROR with an empty answer section, the
server should provide the SOA record in the authority section. That SOA
is the apex of the zone which doesn't contain the answer record you
asked for, if you see what I mean. The server is proving that it has
authority to tell you that the information doesn't exist.
The fact that looking for nonexistent data for
vlasext.partners.extranet.microsoft.com returns the
partners.extranet.microsoft.com SOA record shows that the vlasext
subdomain has not been delegated. The servers should therefore be able
to offer an authoritative answer for data that does exist for
vlasext.etc... but they don't.
> I'm trying a few third level domains (e.g. fabric.readthedocs.org) and
> I most of the time get as authority section the SOA for the second
> level domain (readthedocs.org).
dig <domain> +trace will also (normally) show you how the tree is
delegated, though it doesn't print out the SOA records. Try
> > It's all rather horrible.
> I concur!
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
More information about the bind-users