Thoughts on allowing newer DNS RR queries?
Outside of Atlas I've been doing a few tests to see how well CPE supports newer RR types. By newer I mean newer than AAAA. I'd like to do the same with the Atlas probes. Has there been discussion about being able to issue RR queries of newer types? On the query side, the Atlas device only needs to know enough to encode the type-value which could be supplied as a numeric if necessary. On the response side, a simple hex dump of the response would be good enough. I guess it's sort of a one-off test for most probes because once we know a probe and its intervening caches does or does not support a number of newer types, that situation is unlikely to require re-testing very often. So an alternative might be to make it a bootstrap sequence that the probe goes thru? Out of curiousity, how does the probe do the current DNS queries? Is it via dig or similar or is it coded into a program of some sort? Mark.
Hi Mark, what is the specific RR query you are looking for? currently we support a bunch of them UDP or TCP. Here is a list. in class IN A, AAAA, ANY, CNAME, DS, DNSKEY, MX, NS, NSEC, NSEC3, PTR, RRSIG, SOA, SRV, NAPTR. class CHAOS hostname.bind, id.server, version.bind, version.server regards, -antony On Wed, Feb 19, 2014 at 03:54:29PM +0000, Mark Delany wrote:
Outside of Atlas I've been doing a few tests to see how well CPE supports newer RR types. By newer I mean newer than AAAA. I'd like to do the same with the Atlas probes.
Has there been discussion about being able to issue RR queries of newer types?
On the query side, the Atlas device only needs to know enough to encode the type-value which could be supplied as a numeric if necessary. On the response side, a simple hex dump of the response would be good enough.
I guess it's sort of a one-off test for most probes because once we know a probe and its intervening caches does or does not support a number of newer types, that situation is unlikely to require re-testing very often. So an alternative might be to make it a bootstrap sequence that the probe goes thru?
Out of curiousity, how does the probe do the current DNS queries? Is it via dig or similar or is it coded into a program of some sort?
Mark.
On 20Feb14, Antony Antony allegedly wrote:
Hi Mark, what is the specific RR query you are looking for?
currently we support a bunch of them UDP or TCP. Here is a list.
in class IN A, AAAA, ANY, CNAME, DS, DNSKEY, MX, NS, NSEC, NSEC3, PTR, RRSIG, SOA, SRV, NAPTR.
class CHAOS hostname.bind, id.server, version.bind, version.server
Don't ask me why I made such a goof, but for some reason when I checked I thought I only saw a couple of types. Sorry. To answer your question, it wasn't a particular type I had in mind, it was more trying to ask the question of how well the infrastructure deals with new types. In the bad old days introducing a new type was deemed risky because a lot of middleware, such as caches and firewalls had type-specific code. I was wanting to test the claim that most modern middleware is type-oblivious and "just works" with new types. So ideally, it would be a type that doesn't exist or one that has just recently been published. Mark.
In the bad old days introducing a new type was deemed risky because a lot of middleware, such as caches and firewalls had type-specific code. I was wanting to test the claim that most modern middleware is type-oblivious and "just works" with new types. So ideally, it would be a type that doesn't exist or one that has just recently been published. The latest ones are according <http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4> EUI48 and EUI64 (RFC 7043) and then there are a couple (some which are still draft not even mentioned in the list above) which are still draft or just proposed: NINFO RKEY CDS UR and TA. /** draft-reid-dnsext-zs */ LDNS_RR_TYPE_NINFO = 56, /** draft-reid-dnsext-rkey */ LDNS_RR_TYPE_RKEY = 57, /** draft-ietf-dnsop-trust-history */ LDNS_RR_TYPE_TALINK = 58, /** draft-barwood-dnsop-ds-publis */ LDNS_RR_TYPE_CDS = 59, /** DNSSEC Trust Authorities */ LDNS_RR_TYPE_TA = 32768, Enjoy! jaap
antony@ripe.net:
Hi Mark, what is the specific RR query you are looking for?
currently we support a bunch of them UDP or TCP. Here is a list.
in class IN A, AAAA, ANY, CNAME, DS, DNSKEY, MX, NS, NSEC, NSEC3, PTR, RRSIG, SOA, SRV, NAPTR.
class CHAOS hostname.bind, id.server, version.bind, version.server
I suggest allowing queries, not from mnemonics, but from ID-number. Any unsigned 16-bit number should be allowed, both for CLASS and for RRTYPE. The result can be presented as an ASCII-fied blob (BASE64? uuencode? Motorla S-records? ...) for parsing by interested parties. DNS infrastructure is supposed to be blackbox store-and-forward. So should Atlas be. Yes, I understand there may be design problems with this. I'm stating the desired long-term goal. And keeping mnemonics for the most common cases is of course desireable, but if there are (e.g.) space restriction in the poor little dongles, I suggest asking by number only, and have a front-end system that does necessary translations. Maybe I'm stating the obvious ... :-/ Cheers, /Liman
Hi Mark, On 2/19/14 4:54 PM, Mark Delany wrote:
Out of curiousity, how does the probe do the current DNS queries? Is it via dig or similar or is it coded into a program of some sort?
FYI, you can see the description of the commands on the probes here: https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source-... And check out the latest sources and options for those here: https://atlas.ripe.net/get-involved/source-code/ Cheers Colin
participants (5)
-
Antony Antony -
Colin Petrie -
Jaap Akkerhuis -
Lars-Johan Liman -
Mark Delany