RFC: Parsing record contents directly about dns HOT 6 CLOSED

from dns.

I know where you are coming from and feel your pain. I tried doing something similar for CoreDNS's caching back in the day.
Before I read your proposal in much more detail. Note that:

• NewRR is expensive in itself - you might also just want to create an RR without parsing some stringified rdata, i.e. without NewRR - I never found a good Go api for that - although now maybe with Generics there might be a clean way?
• Does this proposal imply that we also want to be able to write out and read in RDATA in wireformat? (as a more efficient way of doing this)?

from dns.

ok, read it.

I see. Let me be clear that the RFC 1035 zone format is a horrendous format, even if you remove most of it, like $TTL and $ORIGIN and $INCLUDE and $GENERATE, you also still have ( and ')' which could potentially show up and newlines should be ignored there - or do you also want to ban those from parsing?

If we go back to the original task, it's: if have some bytes and I want those bytes to be the rdata of this dns.RR i have, so the question then becomes:

• how do I store the bytes (and does this library need to care?)
• how do I marry an dns.RR and this parsed rdata (here you prolly do need some support in this lib)

FWIW as eluded in my first comment, I never found a elegant way of doing the later in Go, do we need a dns.RData interface thingy, this was an attempt for work directory with rdata fields: https://pkg.go.dev/github.com/miekg/dns#Field (obviously that only reading them).

So dunno - open to ideas, but I think a customized parser that works on the text representation isn't the best thing, nor the speediest

from dns.

Thank you @miekg! You raise some very good points.

Initially I would've said ( ) should be allowed, but the more I think about it, the more they seem like zone file syntax rather than content syntax, if that makes sense. Really, maybe all we need is the ability to parse quotes and backslash escapes (and skip whitespace). That still leaves us with a lot of type-specific behavior, though: net.ParseIP, toAbsoluteName, the occasional Base64 decoding, and the nightmare that is LOC parsing.

It seems the only lexer function called by each type in scan_rr.go is Next(), so I wonder if we could somehow turn that into an interface and find an elegant way to inject a different "lexer" behind the scenes (whether an actual lexer or something simpler that just produces the right data at the right time). I'll definitely need to think about that some more though.

Thanks for all the feedback so far!

from dns.

Coming back to this... still on the dunno. Had kept it in the back of my mind, and my question is. Why is this data in txt format in the first place? It makes more sense to have this in (uncompressed!) wire format, parse that back in and put the RR metadata on it, and voila -> RR

from dns.

In our case it's coming from the API or a database column that needs to be searchable text. In most other cases, I would agree that storing wire format data is better.

Maybe ideally we'd have something similar to #1507 that allows parsing to work without a hard dependency on the lexer, but that is obviously a larger change. I'm still hoping to get a PR up at some point for you to review but if you don't object, I'm going to close this issue in the meantime since it's not really a bug and more of a "request for your thoughts".

Thank you for your input, Miek!

from dns.