dns: ZoneParser error with "TSIG" records

[ Quoting notifications@github.com in “Re: [miekg/dns] ZoneParser error wi…” ]

Bind is looking for a qstring but will accept a plain string. It emits a qstring. The is actually consistent with Postel’s be liberal with what you accept and conservative with what you generate principal.

Sure, and now its offloadig the (liberal) decision to infect this library.

TSIG also needs to have a presentation format defined. Humans have to read it and sometime tools have to post process it.

Also sure: but it hasn’t today, so it’s illegal, please use RFC 3597 syntax.

This issue is very good at highlighting which registries have absolutely no clue what they are doing.

👍 for this library parsing zone files, and not zone files and also text files that resemble zone files.

[ Quoting notifications@github.com in “Re: [miekg/dns] ZoneParser error wi…” ]

Would it be possible to get an option to allow your parser to skip over these entries or allow it to recover from the error? I don’t see stripping records as a pre-processing step practical in my scenario. Wouldn’t this pre-processing step would need its own parser, defeating the point?

I’m currently using my own very hacky parser for the root zones files from https://czds.icann.org/ however I’d like to move to your more complete parser, but it throws errors like this on many of the zones files provided by ICANN’s CZDS service.

To help provide another example of a record that errors and should be skipped from a root zone file:

dns: bad NAPTR Flags: "u" at line: 168993:61

blackberry-plugin.software.nic.tel.     86400   in      naptr   100 100 u E2U+web:http !^.*\$!http://dev.telnic.org/downloads/blackberry.html! .

this is plain wrong:

The Flags and Services and Regexp fields are all quoted <character-string>s.

https://tools.ietf.org/html/rfc2915#section-9. Those fields are not quoted so that is an error.

Ignoring unknown RRs may be an option, but sounds dangerous so I’m not a fan it doing that.

I don’t know what ICANN is serving you, but it’s certainly not well formed zones.

/Miek

– Miek Gieben

[ Quoting notifications@github.com in “Re: [miekg/dns] ZoneParser error wi…” ]

Unfortunately I’m not in control of the input zone file. It’s being generated by Neustar with what looks like an AXFR from dig.

you’re not getting a zonefile, your getting an axfr with a transaction signature attached. Those are 2 different things. TSIG has no meaning in a zone and doesn’t have a text representation, so it errors.

If they are not conforming to the spec is there another way to make this work? Or alternatively, would it be possible to allow the parser to continue after throwing a noncritical error, allowing the user to decide what errors are worth stopping on?

you need to strip the TSIG, just as you (probably) need to drop the second SOA, although the parser happily returns that second one.

/Miek

– Miek Gieben

Without a TSIG presentation format this is WAI; we discarding invalid zone.

TSIG needs an RFC which will be trivial; so this is your change to engage in the IETF process 😃

Meanwhile closing this as Works As Intended

I’m not willing to implement the same.

You need to read it with bind and then write it out again to clean. Then you can read it again using this library and process

On Wed, 21 Nov 2018, 18:38 Miek Gieben <miek@miek.nl wrote:

Twitter thread with ICANN going on. Seems bind does ignore this crap

On Wed, 21 Nov 2018, 18:27 Miek Gieben <miek@miek.nl wrote:

How many zone files are actually garbage here?

On Wed, 21 Nov 2018, 18:26 Miek Gieben <miek@miek.nl wrote:

Yeah. Best approach would be to clean them with some shell. I don’t know of any library that handles malformed zones files.

On Wed, 21 Nov 2018, 17:02 Ian Foster <notifications@github.com wrote:

I don’t know what ICANN is serving you, but it’s certainly not well formed zones.

100% agree, I’m just trying to figure out the best way to deal with them.

If adapting this library to accept non-compliant zones is not an option I can continue to use my own parser.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/miekg/dns/issues/810#issuecomment-440739796, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVkW6WP_kDKKyZEkfMXIQNE78FVRhKgks5uxYcogaJpZM4YadA2 .