[dns-operations] COM referral responses from root without glue and TC bit

Viktor Dukhovni ietf-dane at dukhovni.org
Fri Jan 12 23:00:56 UTC 2024


On Fri, Jan 12, 2024 at 02:40:22PM -0800, Wes Hardaker wrote:
> Viktor Dukhovni <ietf-dane at dukhovni.org> writes:
> 
> > > Relevant text from RFC 9471 abstract: If message size constraints
> > > prevent the inclusion of all glue records for in-domain name servers,
> > > the server must set the TC (Truncated) flag to inform the client that
> > > the response is incomplete.
> > 
> > Indeed, and so 6 out of 13 roots need to be updated to set TC=1 as
> > required.
> 
> Definitely true.  Having said that, different software behaves
> differently (as we run multiple different software packages, I see
> differences across our deployment even).
> 
> Note that although this should be done, the specification mandating this
> is from September of last year so the software hasn't likely caught up
> yet.  Though there is some argument that RFC1034 said this too, but less
> well stated.
> 
> I'll further note that this is not a root specific problem.  This is
> likely true across the deployed DNS ecosystem, but the root does serve
> as a good test case.

However, in partial defense of the root servers, it should be noted that
while "gtld-servers.net" is in-bailiwick for the root servers, it is not
in- bailiwick for the "com." delegation, and so a glueless response
should be handled gracefully.  The "missing" glue is *sibling* glue.

The more severe form of the problem is for essentially the same query at
the ".net" TLD, with the same results:

    ; <<>> DiG 9.16.40-RH <<>> +norecur +ignore +noedns @m.root-servers.net -t a kcmbrvwjafupdyztdq2ifvi6ye7fcacaaben6jaavmoaaaeqnqaaa2qaaaanh7j.a5erjsqwn7zic34e7psoufcfue6rsznpw34cx57gjhhqqj6edwr6o57wikagcdv.ard6pjajyuo6kmpbm6ohbbjppyhmkivhxxmgqgb5xjpl2cvvlzo34erwypot4fw.lh4aa5rzkni7yihszvyxxw43w4aa3cysaws7jtjg.dns.uas-1.optnl.net
    ; (2 servers found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3211
    ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;kcmbrvwjafupdyztdq2ifvi6ye7fcacaaben6jaavmoaaaeqnqaaa2qaaaanh7j.a5erjsqwn7zic34e7psoufcfue6rsznpw34cx57gjhhqqj6edwr6o57wikagcdv.ard6pjajyuo6kmpbm6ohbbjppyhmkivhxxmgqgb5xjpl2cvvlzo34erwypot4fw.lh4aa5rzkni7yihszvyxxw43w4aa3cysaws7jtjg.dns.uas-1.optnl.net. IN A

    ;; AUTHORITY SECTION:
    net.                    172800  IN      NS      k.gtld-servers.net.
    net.                    172800  IN      NS      g.gtld-servers.net.
    net.                    172800  IN      NS      m.gtld-servers.net.
    net.                    172800  IN      NS      c.gtld-servers.net.
    net.                    172800  IN      NS      d.gtld-servers.net.
    net.                    172800  IN      NS      b.gtld-servers.net.
    net.                    172800  IN      NS      e.gtld-servers.net.
    net.                    172800  IN      NS      f.gtld-servers.net.
    net.                    172800  IN      NS      h.gtld-servers.net.
    net.                    172800  IN      NS      a.gtld-servers.net.
    net.                    172800  IN      NS      i.gtld-servers.net.
    net.                    172800  IN      NS      j.gtld-servers.net.
    net.                    172800  IN      NS      l.gtld-servers.net.

This time, the response is a dead-end glueless in-bailiwick delegation
for ".net".

-- 
    Viktor.


More information about the dns-operations mailing list