[getdns-api] Adding an extension to highlight common DNS errors

Phillip Hallam-Baker hallam at gmail.com
Wed Jan 30 10:52:29 MST 2013

On Wed, Jan 30, 2013 at 12:08 PM, Andrew Sullivan <asullivan at dyn.com> wrote:

> On Wed, Jan 30, 2013 at 08:13:00AM -0800, Paul Hoffman wrote:
> > On Jan 29, 2013, at 12:31 PM, Andrew Sullivan <asullivan at dyn.com> wrote:
> >
> > >
> > > A CNAME response with any other RRTYPE, perhaps?
> >
> > If the API is acting as a recursive resolver, what circumstance would
> lead to this?
> People break this requirement of the protocol all the time, usually in
> an effort to do Stoopid DNS Tricks in support of CDNs.  The most
> common case observed in the wild is actual CNAME records sitting at
> the apex of a zone.  Because CNAME chains are supposed to be followed,
> what you will see is (for instance) the NS records and a CNAME all at
> that owner name.  Since this is an absurd situation, the behaviour of
> systems is unreliable.

I don't think this is an API issue except that a low level DNS API should
allow the caller to see such behavior and a high level API should try to do
the right thing despite the stupidity.

What it does raise a need for is a 'dnsstupid' tool that will tell an admin
that a DNS configuration is stupid. That would in turn require a list of
rules to check.

I can throw together a tool as part of my distribution if someone can point
me to a concise list of rules to check.

The answers I am getting back from my DNS right now make no sense at all
because the ISP seems to be redirecting all DNS traffic through its own
servers. So what I thought was a weird google.com glue record is actually a
glue record to the Verizion server.

Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vpnc.org/pipermail/getdns-api/attachments/20130130/f85a4633/attachment.html>

More information about the getdns-api mailing list