[knot-dns-users] Knot DNS 1.3.0-rc5

Marek Vavruša marek.vavrusa at nic.cz
Mon Aug 5 08:01:40 CEST 2013

Hi Johan,

On 3 August 2013 17:24, Johan Ihrén <johani at johani.org> wrote:
>>> Besides, I think it conforms to the standard listed in the thread as
>>> we "identify and handle occluded names"
>>> and also include occluded names in the AXFR response. Except, we don't
>>> but since we don't accept
>>> such names into a zonefile in the first place, it is irrelevant to
>>> consider whether we would include them
>>> or not in the AXFR response. And I believe discarding them falls into
>>> the "identify and handle" category.
>> I'm happy with this response. As I said, out-of-zone names shouldn't be
>> there in the first place, and I can't think of any negative side effects
>> of discarding them.
> What about NSEC/NSEC3 chains?

Yes, it was said that it could disconnect an NSEC3 chain. That being
said, no sane signer
would allow this and there could even be a question of ordering.
There are about a zero reasons to have something like 'something.' in
a 'something.else.' zone.

>>> I see the point, but I also see a few good cases where it's a good idea to fake
>>> the server version/id. Nevertheless, we could accept two (3 for NSID)
>>> different types:
>>> * boolean on|off - on would fill a default string, off would turn it
>>> off (just a convenience)
>>> * text "something" - arbitrary string, just like now, even empty text
>>> * hexstring - just for the NSID
>>> This would make it convenient to serve both automatic or arbitrary data.
>>> Does this sound okay?
>> If you can make Knot parse the options as either boolean or strings,
>> that would be great. Then we can have on|off for sane defaults, or
>> string values for wacky people who want to misreport versions and
>> identities for any reason :)
> There are cases where having your own version is more than reasonable. Apart from the minimum disclosure case (that would be covered by an "off" switch) it may be that we have our own modifications to the stock releases. Sure, if we're hacking the source we can of course hack the part that specifies the version string...but we all forget about such maintenance while we're chasing the real problem, so being able to just tweak the config to indicate that this is not stock knot-1.3.0 but rather my own derivative version would be helpful.
> Johan

Yup, we kept the whole hexstring/string configuration, so you can
still set it to any arbitrary string
as before. But as an addition, you are also able to set it to boolean
on and it will fill the value automagically.

Here's some extra information https://gitlab.labs.nic.cz/knot/issues/113


> _______________________________________________
> knot-dns-users mailing list
> knot-dns-users at lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

More information about the knot-dns-users mailing list