limit $GENERATE range to 2^16?

[miekg]

a $GENERATE range that is too large will cause a panic, it make sense to limit this to something reasonable. I propose to limit the number of steps to 65535, i.e.

(stop - start) / step > 65535, and error out if we hit this.

[tmthrgd]

That sounds reasonable. What do other DNS servers do?

[miekg]

[ Quoting <[email protected]> in "Re: [miekg/dns] limit $GENERATE ran..." ]

That sounds reasonable. What do other DNS servers do?

i have no idea... $GENERATE is a bind-ism (originally)

[chantra]

From: https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch06.html#generate_directive

range: This can be one of two forms: start-stop or start-stop/step. If the first form is used, then step is set to 1. start, stop and step must be positive integers between 0 and (2^31)-1. start must not be larger than stop.

[miekg]

[ Quoting <[email protected]> in "Re: [miekg/dns] limit $GENERATE ran..." ]

From: https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch06.html#generate_directive > range: This can be one of two forms: start-stop or start-stop/step. If the first form is used, then step is set to 1. start, stop and step must be positive integers between 0 and (2^31)-1. start must not be larger than stop.

this ooms my test (on my machine) - and it's a very large number for something like this - not sure how to preceed. Use this number or something smaller?

[chantra]

this ooms my test (on my machine) - and it's a very large number for something
like this - not sure how to preceed. Use this number or something smaller?

it seems sensible to me to use something smaller. There is obviously no users of this feature with that many steps (or they would have reported it).
I think a sane limit is a simple fix. Supporting the bind behaviour may require a more substantial change which may not be worth it.

[miekg]

[ Quoting <[email protected]> in "Re: [miekg/dns] limit $GENERATE ran..." ]

it seems sensible to me to use something smaller. There is obviously no users of this feature with that many steps (or they would have reported it). I think a sane limit is a simple fix. Supporting the bind behaviour may require a more substantial change which may not be worth it.

thanks. I agree with that.

[chantra]

and another flavor:

"$GENERATE 6-2048 $$GENERATE 6-036160 $$$$ORIGIN \\$"

this ends up calling generate on generate :)

[chantra]

diff --git a/scan.go b/scan.go
index 0f9361af..5567653b 100644
--- a/scan.go
+++ b/scan.go
@@ -732,6 +732,8 @@ type zlexer struct {
        nextL bool

        eol bool // end-of-line
+
+       generate bool
 }

 func newZLexer(r io.Reader) *zlexer {
@@ -886,6 +888,12 @@ func (zl *zlexer) Next() (lex, bool) {
                                case "$INCLUDE":
                                        l.value = zDirInclude
                                case "$GENERATE":
+                                       if zl.generate {
+                                               l.token = "$GENERATE can be used only once"
+                                               l.err = true
+                                               return *l, true
+                                       }
+                                       zl.generate = true
                                        l.value = zDirGenerate
                                }

would seem to work when dogsciencing but will likely break if there is 2 lines with the GENERATE directive.

[tmthrgd]

@chantra To prohibit $GENERATE in $GENERATE, it would be better to set a field on the sub parser created in generate.go. That won’t conflict with multiple $GENERATE directives in one zonefile like your patch will.

[chantra]

@tmthrgd I missed that.... I had tried to set it in the lexer or something... not the sub parser. diffing a fix.

[chantra]

@tmthrgd would this work? #1033