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

[Mark Andrews]

Formerr w/o the zflag is also acceptable.  STD13 allows for both behaviours.
That said most servers return NOERROR.

> On 22 May 2019, at 1:44 pm, manu tman <chantr4 at gmail.com> wrote:
> 
> 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
> """
> 
> 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 mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org