This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] Thoughts on allowing newer DNS RR queries?
- Previous message (by thread): [atlas] Thoughts on allowing newer DNS RR queries?
- Next message (by thread): [atlas] Thoughts on allowing newer DNS RR queries?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Lars-Johan Liman
atlas at liman.net
Fri Feb 21 10:47:26 CET 2014
antony at 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
- Previous message (by thread): [atlas] Thoughts on allowing newer DNS RR queries?
- Next message (by thread): [atlas] Thoughts on allowing newer DNS RR queries?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]