[dns-operations] The last remaining DNS header flag.

[manu tman]

Hi All,

I love how https://ednscomp.isc.org make it easy to test and validate one's
server, and even more so that
https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing 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.

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.

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:

"""
dig +norec +noad +noedns +zflag soa zone @server
expect: SOA
expect: NOERROR
expect: Z bit to be clear in response
See RFC1035, 4.1.1. Header section format
<http://tools.ietf.org/html/rfc1035>
"""

Which makes it clear:
1) what the response is expected to contain
2) a reference to the relevant spec

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

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.


On this specific check, it is not obvious to me why a server should respond
with NOERROR though. RFC1035 4.1.1. says:

"""

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




On Thu, May 16, 2019 at 11:53 AM Ondřej Surý <ondrej at sury.org> wrote:

> 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.
>
> 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
>
> Ondřej
> --
> Ondřej Surý <ondrej at sury.org>
>
> > On 15 May 2019, at 16:12, Paul Wouters <paul at nohats.ca> wrote:
> >
> >> On Sat, 11 May 2019, Mark Andrews wrote:
> >>
> >> Stage 2. Declare a flag day
> >
> > Stop calling these things flag days. They are not.
> >
> > To non-DNS people, running "flag days" just signals "they made large
> > mistakes and now all have to sync up on a single day to switch to
> > keep it all running. If you don't cooperate on DNS flag day, you are
> > down for good"
> >
> > DNS will not have flag days, until we turn it off and only depend on its
> > successor.
> >
> > Paul
> > _______________________________________________
> > dns-operations mailing list
> > dns-operations at lists.dns-oarc.net
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> > dns-operations mailing list
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations
> <https://lists.dns-oarc.net/mailman/listinfo/dns-operationsdns-operations>
> mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190521/6ce7345c/attachment-0001.html>