[dns-operations] to RD or not to RD, that is the question.

Alex Nicoll anicoll at cert.org
Mon Nov 25 17:28:47 UTC 2013

Unfortunately I cannot share the domain name due to a confidentiality agreement, or I'd be happy to do it!  Using dig I can confirm that the suspect servers are returning the AA flag, regardless of whether I specify RD or not.   Thanks for the information - it's always nice to know I didn't miss something!


> -----Original Message-----
> From: ✅ Roy Arends [mailto:roy at dnss.ec]
> Sent: Monday, November 25, 2013 11:27 AM
> To: Alex Nicoll
> Cc: dns-operations at lists.dns-oarc.net
> Subject: Re: [dns-operations] to RD or not to RD, that is the question.
> * PGP Signed by an unknown key
> On 25 Nov 2013, at 16:15, Alex Nicoll <anicoll at cert.org> wrote:
> > I find myself in a bit of a quandary, and so I thought I'd turn to the gurus
> here for some help.
> >
> > I needed to do some basic DNSSEC testing on a domain, and began by
> grabbing a list of the authoritative name servers for the domain.  I then
> queried each name server for some basic records that I know exist (SOA, A
> records, etc) to get ensure the RRSIGs come back and can be validated.  On 7
> of the 10 authoritative name server, I can query WITHOUT using the RD flag in
> the message header, and get the expected results.  On the other three,
> querying without the RD flag yields no records, but also no error.  When
> querying the three WITH the RD flag, I get the expected responses.
> >
> >
> > As far as I can understand the RFCs, all authoritative name servers should
> have a local copy of the zone, which means that they should be able to
> answer the queries without recursion.  Is this a correct assumption?
> That is a correct assumption. As far as I understand, an authoritative server
> satisfies three requirements. 1) the domain in question is delegated to the
> server in question by its parent. 2) the server in question responds with the
> AA bit, or responds with a delegation to the next level 3) the server in
> question is configured to serve the zone in question.
> Can you share the domain in question with the list? It often helps to get a
> confirmation of the data that you see.
> >   If it isn't, then I need to modify my scan script, but if it is, can I assume that
> means the nameservers need to be fixed, or at least marked non-
> authoritative?
> There is quite a lot of brokeness in the world of DNS. Without data to check,
> it might be that your script needs work, the servers need work, the network
> between the two needs work, or all three :-).
> Hope this helps,
> Roy
> >
> > Thanks!
> >
> > -Alex
> >
> > Vaporware:  A much discussed piece of software that doesn’t actually exist.
> > Cloud:  Condensed Vapor.
> >
> >
> > _______________________________________________
> > dns-operations mailing list
> > dns-operations at lists.dns-oarc.net
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> > dns-jobs mailing list
> > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> * Unknown Key
> * 0x626FDEA9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 474 bytes
Desc: not available
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131125/f2b9d533/attachment.sig>

More information about the dns-operations mailing list