<div dir="ltr">Hi All,<br><br>I love how <a href="https://ednscomp.isc.org/">https://ednscomp.isc.org</a> make it easy to test and validate one's server, and even more so that <a href="https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing">https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing</a> can be ran against a local server so it is possible to validate fixes before pushing fixes out and realizing that it is not actually fixed.<br><br>I got a couple of feedback/features I would like to see that would make it even easier and more actionable for people using the tools.<br><br>For one, the web UI outputs a rather clear message about what is expected from the server. For instance, in the case of the z flag test, you would get this message:<br><br>"""<br><span style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:16px">dig +norec +noad +noedns +zflag soa zone @server</span><br style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:16px"><span style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:16px">expect: SOA</span><br style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:16px"><span style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:16px">expect: NOERROR</span><br style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:16px"><span style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:16px">expect: Z bit to be clear in response</span><br style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:16px"><a href="http://tools.ietf.org/html/rfc1035" style="font-family:Arial,sans-serif;font-size:16px">See RFC1035, 4.1.1. Header section format</a><br>"""<br><br>Which makes it clear:<br>1) what the response is expected to contain<br>2) a reference to the relevant spec<br><br>genreport on the other hand, only seems to indicate what is not right, but not really how to fix it, e.g: zflag=formerr,z <br><br>Printing the same, or similar, message than the web UI would be great. I did not find anything in DNS-Compliance-Testing repo that would help linking what I see in the UI to the CLI.<br><br><br>On this specific check, it is not obvious to me why a server should respond with NOERROR though. RFC1035 4.1.1. says:<br><br>"""<br><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)">Z Reserved for future use. Must be zero in all queries
and responses.
"""
With this only, it would seem formerr is a legitimate answer (as long as it has Z flag set to 0).
While I understand why a server should accept whatever it is set to for future use of such bits, and setting it to 0
in the reply would signal no support of "future use case", I don't find that bit in the RFC to be clear. I think it would
help if there a tiny bit more text in the ednscomp tool to clarify why a server should not FORMERR the query.
Thanks
Manu
</pre><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 16, 2019 at 11:53 AM Ondřej Surý <<a href="mailto:ondrej@sury.org">ondrej@sury.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Stop calling the CPU bugs Meltdown, because it won’t meltdown your CPU, also last time I looked there were neither zombies nor spectres in my computer... also it doesn’t have any heart that could bleed.<br>
<br>
It’s just a catchy “marketing” name and it’s exaggerated, yes, but it worked well, so we’ll have next *DNS Flag Day* even though it might not have to be *flag day* per se<br>
<br>
Ondřej <br>
--<br>
Ondřej Surý <<a href="mailto:ondrej@sury.org" target="_blank">ondrej@sury.org</a>><br>
<br>
> On 15 May 2019, at 16:12, Paul Wouters <<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>> wrote:<br>
> <br>
>> On Sat, 11 May 2019, Mark Andrews wrote:<br>
>> <br>
>> Stage 2. Declare a flag day<br>
> <br>
> Stop calling these things flag days. They are not.<br>
> <br>
> To non-DNS people, running "flag days" just signals "they made large<br>
> mistakes and now all have to sync up on a single day to switch to<br>
> keep it all running. If you don't cooperate on DNS flag day, you are<br>
> down for good"<br>
> <br>
> DNS will not have flag days, until we turn it off and only depend on its<br>
> successor.<br>
> <br>
> Paul<br>
> _______________________________________________<br>
> dns-operations mailing list<br>
> <a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
> <a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
> dns-operations mailing list<br>
> <a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
<br>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operationsdns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations<br>
dns-operations</a> mailing list<br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div>