Re: Additional Section Cache Without Consulting Authoritative Data- Why? - DNS

This is a discussion on Re: Additional Section Cache Without Consulting Authoritative Data- Why? - DNS ; Sabahattin Gucukoglu wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Kevin, > > On 23 Jul 2008 at 20:26, Kevin Darcy said: > >> Sabahattin Gucukoglu wrote: >> >>> How is this proper? I observe Bind ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: Additional Section Cache Without Consulting Authoritative Data- Why?

  1. Re: Additional Section Cache Without Consulting Authoritative Data- Why?

    Sabahattin Gucukoglu wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Hi Kevin,
    >
    > On 23 Jul 2008 at 20:26, Kevin Darcy said:
    >
    >> Sabahattin Gucukoglu wrote:
    >>
    >>> How is this proper? I observe Bind 9 doing it, and a quick rifle of RFC
    >>> 1034-5 says that additional section data provided for crossing a zone cut
    >>> is, without doubt, not authoritative.
    >>>

    >> RFC 2181 is the more modern reference, as far as "ranking data" is
    >> concerned. See Section 5.4.1 of that RFC.
    >>

    >
    > Cool! Thanks. But this only seems to confirm that the problem actually
    > exists, since the additional section is the most "Mistrusted" data
    > available for use according to that list and, indeed, the spirit of
    > Additional data in 1034-5. And anyway, there's this smoking gun:
    >
    > | Unauthenticated RRs received and cached from the least trustworthy of
    > | those groupings, that is data from the additional data section, and
    > | data from the authority section of a non-authoritative answer, should
    > | not be cached in such a way that they would ever be returned as
    > | answers to a received query. They may be returned as additional
    > | information where appropriate. Ignoring this would allow the
    > | trustworthiness of relatively untrustworthy data to be increased
    > | without cause or excuse.
    >
    > In other words, don't ever trust the additional data to actually be useful
    > for any purpose other than the very one for which it can not fail to be
    > used or useful: delegation.
    >
    > If I wrote a DNS server, I wouldn't even bother to cache it. Why should
    > I? It's only a bootstrap - it loses its usefullness as soon as I've got
    > what I want out of the next hop nameserver, which may well be the address
    > of that nameserver from that nameserver. That's a result I *can* keep,
    > usefully. Stuff the next-door neighbour - he can do as I did, unless I
    > happened to need that nameserver's address while recursing myself (I.E.
    > while actually needing the authoritative address of a host listed in the
    > NS records at a delegation or in response to an actual query I get), in
    > which case I'll be so good as to pass the information along in case he's
    > in the same situation. Only then, though, as handing over stray data is
    > kind of defeating the non-caching role. And if I am on a mission to
    > recurse for others, I care about trustworthy results, so I'll keep chasing
    > till I get what I want out of an authoritative server, including every
    > single authoritative response, just as though no glue were involved.
    >
    > Last but not least, though,
    > host -v -t a bloodstone.sabahattin-gucukoglu.com
    > against a BIND 9 cache that hasn't seen a query for Bloodstone in a bit
    > returns the result from the parent (in this case, the .com) zone rather
    > than the authoritative response. That is to say, it actually violates the
    > above paragraph explicitly. It isn't alone though, so I am probably
    > missing something pretty large in all this.
    >
    > Cheers,
    > Sabahattin
    >
    > - --
    > Sabahattin Gucukoglu sabahattingucukoglucom>
    > Address harvesters, snag this: feedme@yamta.org
    > Phone: +44 20 88008915
    > Mobile: +44 7986 053399
    > http://sabahattin-gucukoglu.com/
    >
    >
    > -----BEGIN PGP SIGNATURE-----
    > Version: PGP 8
    > Comment: QDPGP - http://community.wow.net/grt/qdpgp.html
    >
    > iQA/AwUBSIgNXSNEOmEWtR2TEQIAQACfXDHaTjjGPun7LqvaYOUq2e zXqLcAoM1Z
    > dRfNsXUAyQqFR3gq2XQLzGnS
    > =rKF0
    > -----END PGP SIGNATURE-----
    >
    >
    >
    >

    I'm showing otherwise. See sequences of queries below:

    Query #1: proves that ns2.footprint.net is not in my local cache
    Query #2: shows that the authoritative nameservers for .net are
    providing ns2.footprint.net glue records (among others) for the
    footprint.net delegation. The results of this query are *not* cached,
    since I asked an authoritative nameserver directly, bypassing my local
    resolver.
    Query #3: I query ns1.footprint.net recursively. Based on #2 above, I
    know that the glue records for ns2.footprint.net must have been seen in
    the course of resolving this query
    Query #4: Immediately afterwards, I query ns2.footprint.net
    non-recursively. It's still not in my cache.

    So, BIND 9 is *seeing* the glue records, and using them for resolving
    the current query, but it's not providing them as answers to subsequent
    queries. They're not "cached" in any meaningful sense of the term. This
    appears to conform to the standards.

    % dig ns2.footprint.net +norec

    ; <<>> DiG 9.3.0 <<>> ns2.footprint.net +norec
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1956
    ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;ns2.footprint.net. IN A

    ;; AUTHORITY SECTION:
    .. 3600000 IN NS L.ROOT-SERVERS.net.
    .. 3600000 IN NS M.ROOT-SERVERS.net.
    .. 3600000 IN NS A.ROOT-SERVERS.net.
    .. 3600000 IN NS B.ROOT-SERVERS.net.
    .. 3600000 IN NS C.ROOT-SERVERS.net.
    .. 3600000 IN NS D.ROOT-SERVERS.net.
    .. 3600000 IN NS E.ROOT-SERVERS.net.
    .. 3600000 IN NS F.ROOT-SERVERS.net.
    .. 3600000 IN NS G.ROOT-SERVERS.net.
    .. 3600000 IN NS H.ROOT-SERVERS.net.
    .. 3600000 IN NS I.ROOT-SERVERS.net.
    .. 3600000 IN NS J.ROOT-SERVERS.net.
    .. 3600000 IN NS K.ROOT-SERVERS.net.

    ;; Query time: 3 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Thu Jul 24 01:33:33 2008
    ;; MSG SIZE rcvd: 243

    % dig footprint.net ns +norec @h.gtld-servers.net

    ; <<>> DiG 9.3.0 <<>> footprint.net ns +norec @h.gtld-servers.net
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1504
    ;; flags: qr; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 8

    ;; QUESTION SECTION:
    ;footprint.net. IN NS

    ;; ANSWER SECTION:
    footprint.net. 172800 IN NS ns1.footprint.net.
    footprint.net. 172800 IN NS ns2.footprint.net.
    footprint.net. 172800 IN NS ns3.footprint.net.
    footprint.net. 172800 IN NS ns4.footprint.net.
    footprint.net. 172800 IN NS ns6.footprint.net.
    footprint.net. 172800 IN NS ns7.footprint.net.
    footprint.net. 172800 IN NS ns8.footprint.net.
    footprint.net. 172800 IN NS ns9.footprint.net.

    ;; ADDITIONAL SECTION:
    ns1.footprint.net. 172800 IN A 63.208.138.37
    ns2.footprint.net. 172800 IN A 64.152.81.68
    ns3.footprint.net. 172800 IN A 63.208.138.37
    ns4.footprint.net. 172800 IN A 67.72.120.47
    ns6.footprint.net. 172800 IN A 210.8.213.38
    ns7.footprint.net. 172800 IN A 63.209.70.231
    ns8.footprint.net. 172800 IN A 212.187.253.68
    ns9.footprint.net. 172800 IN A 212.162.1.100

    ;; Query time: 122 msec
    ;; SERVER: 192.54.112.30#53(h.gtld-servers.net)
    ;; WHEN: Thu Jul 24 01:33:47 2008
    ;; MSG SIZE rcvd: 303

    % dig ns1.footprint.net

    ; <<>> DiG 9.3.0 <<>> ns1.footprint.net
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1990
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 7

    ;; QUESTION SECTION:
    ;ns1.footprint.net. IN A

    ;; ANSWER SECTION:
    ns1.footprint.net. 171867 IN A 63.208.138.37

    ;; AUTHORITY SECTION:
    footprint.net. 171867 IN NS ns9.footprint.net.
    footprint.net. 171867 IN NS ns1.footprint.net.
    footprint.net. 171867 IN NS ns2.footprint.net.
    footprint.net. 171867 IN NS ns3.footprint.net.
    footprint.net. 171867 IN NS ns4.footprint.net.
    footprint.net. 171867 IN NS ns6.footprint.net.
    footprint.net. 171867 IN NS ns7.footprint.net.
    footprint.net. 171867 IN NS ns8.footprint.net.

    ;; ADDITIONAL SECTION:
    ns2.footprint.net. 171867 IN A 64.152.81.68
    ns3.footprint.net. 171867 IN A 63.208.138.37
    ns4.footprint.net. 171867 IN A 67.72.120.47
    ns6.footprint.net. 171867 IN A 210.8.213.38
    ns7.footprint.net. 171867 IN A 63.209.70.231
    ns8.footprint.net. 171867 IN A 212.187.253.68
    ns9.footprint.net. 171867 IN A 212.162.1.100

    ;; Query time: 3 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Thu Jul 24 01:33:54 2008
    ;; MSG SIZE rcvd: 303

    % dig ns2.footprint.net +norec

    ; <<>> DiG 9.3.0 <<>> ns2.footprint.net +norec
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 315
    ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;ns2.footprint.net. IN A

    ;; AUTHORITY SECTION:
    .. 3600000 IN NS H.ROOT-SERVERS.net.
    .. 3600000 IN NS I.ROOT-SERVERS.net.
    .. 3600000 IN NS J.ROOT-SERVERS.net.
    .. 3600000 IN NS K.ROOT-SERVERS.net.
    .. 3600000 IN NS L.ROOT-SERVERS.net.
    .. 3600000 IN NS M.ROOT-SERVERS.net.
    .. 3600000 IN NS A.ROOT-SERVERS.net.
    .. 3600000 IN NS B.ROOT-SERVERS.net.
    .. 3600000 IN NS C.ROOT-SERVERS.net.
    .. 3600000 IN NS D.ROOT-SERVERS.net.
    .. 3600000 IN NS E.ROOT-SERVERS.net.
    .. 3600000 IN NS F.ROOT-SERVERS.net.
    .. 3600000 IN NS G.ROOT-SERVERS.net.

    ;; Query time: 4 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Thu Jul 24 01:33:59 2008
    ;; MSG SIZE rcvd: 243

    %

    - Kevin




  2. Re: Additional Section Cache Without Consulting Authoritative Data -Why?

    On Jul 24, 6:40*am, Kevin Darcy wrote:

    > I'm showing otherwise. See sequences of queries below:
    >
    > Query #1: proves that ns2.footprint.net is not in my local cache


    Agreed.

    > Query #2: shows that the authoritative nameservers for .net are
    > providing ns2.footprint.net glue records (among others) for the
    > footprint.net delegation. The results of this query are *not* cached,
    > since I asked an authoritative nameserver directly, bypassing my local
    > resolver.


    Yep.

    > Query #3: I query ns1.footprint.net recursively. Based on #2 above, I
    > know that the glue records for ns2.footprint.net must have been seen in
    > the course of resolving this query


    You meant, I think, that you queried your local nameserver recursively
    for ns1.footprint.net, and yes ns2.footprint.net's address comes back
    at you. But there's something wrong - the TTLs on the records in the
    answer, authority and additional sections indicate that you *have*
    already cached them. It isn't 172800; it's slightly less. So at some
    point you must have got the delegations and additional sections from
    the .net nameservers cached. Did you specify a footprint.net
    nameserver explicitly to dig as destination for your query? That
    would have done that because you'd've implicitly needed a recursive
    query done on that server's address. If not, there's a time gap.

    > Query #4: Immediately afterwards, I query ns2.footprint.net
    > non-recursively. It's still not in my cache.


    Whatever it is, I'm not agreeing. And once again, the simple process
    of:
    # rndc flush
    # host -t a -v ns2.footprint.net
    gives a record whose TTL is 172800; as it is from the c.gtld-
    servers.net nameserver and not any of the footprint.net nameservers
    where it is 86400. And no configuration directive exists in
    named.conf for doing what I want (additional-from-auth and additional-
    from-cache only apply if you're authoritative only and responding to
    authoritative queries).

    Any further ideas? I'm about ready to bug-report this one.

    Cheers,
    Sabahattin

    > % dig ns2.footprint.net +norec
    >
    > ; <<>> DiG 9.3.0 <<>> ns2.footprint.net +norec
    > ;; global options: printcmd
    > ;; Got answer:
    > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1956
    > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
    >
    > ;; QUESTION SECTION:
    > ;ns2.footprint.net. IN A
    >
    > ;; AUTHORITY SECTION:
    > . 3600000 IN NS L.ROOT-SERVERS.net.
    > . 3600000 IN NS M.ROOT-SERVERS.net.
    > . 3600000 IN NS A.ROOT-SERVERS.net.
    > . 3600000 IN NS B.ROOT-SERVERS.net.
    > . 3600000 IN NS C.ROOT-SERVERS.net.
    > . 3600000 IN NS D.ROOT-SERVERS.net.
    > . 3600000 IN NS E.ROOT-SERVERS.net.
    > . 3600000 IN NS F.ROOT-SERVERS.net.
    > . 3600000 IN NS G.ROOT-SERVERS.net.
    > . 3600000 IN NS H.ROOT-SERVERS.net.
    > . 3600000 IN NS I.ROOT-SERVERS.net.
    > . 3600000 IN NS J.ROOT-SERVERS.net.
    > . 3600000 IN NS K.ROOT-SERVERS.net.
    >
    > ;; Query time: 3 msec
    > ;; SERVER: 127.0.0.1#53(127.0.0.1)
    > ;; WHEN: Thu Jul 24 01:33:33 2008
    > ;; MSG SIZE rcvd: 243
    >
    > % dig footprint.net ns +norec @h.gtld-servers.net
    >
    > ; <<>> DiG 9.3.0 <<>> footprint.net ns +norec @h.gtld-servers.net
    > ;; global options: printcmd
    > ;; Got answer:
    > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1504
    > ;; flags: qr; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 8
    >
    > ;; QUESTION SECTION:
    > ;footprint.net. IN NS
    >
    > ;; ANSWER SECTION:
    > footprint.net. 172800 IN NS ns1.footprint.net.
    > footprint.net. 172800 IN NS ns2.footprint.net.
    > footprint.net. 172800 IN NS ns3.footprint.net.
    > footprint.net. 172800 IN NS ns4.footprint.net.
    > footprint.net. 172800 IN NS ns6.footprint.net.
    > footprint.net. 172800 IN NS ns7.footprint.net.
    > footprint.net. 172800 IN NS ns8.footprint.net.
    > footprint.net. 172800 IN NS ns9.footprint.net.
    >
    > ;; ADDITIONAL SECTION:
    > ns1.footprint.net. 172800 IN A 63.208.138.37
    > ns2.footprint.net. 172800 IN A 64.152.81.68
    > ns3.footprint.net. 172800 IN A 63.208.138.37
    > ns4.footprint.net. 172800 IN A 67.72.120.47
    > ns6.footprint.net. 172800 IN A 210.8.213.38
    > ns7.footprint.net. 172800 IN A 63.209.70.231
    > ns8.footprint.net. 172800 IN A 212.187.253.68
    > ns9.footprint.net. 172800 IN A 212.162.1.100
    >
    > ;; Query time: 122 msec
    > ;; SERVER: 192.54.112.30#53(h.gtld-servers.net)
    > ;; WHEN: Thu Jul 24 01:33:47 2008
    > ;; MSG SIZE rcvd: 303
    >
    > % dig ns1.footprint.net
    >
    > ; <<>> DiG 9.3.0 <<>> ns1.footprint.net
    > ;; global options: printcmd
    > ;; Got answer:
    > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1990
    > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 7
    >
    > ;; QUESTION SECTION:
    > ;ns1.footprint.net. IN A
    >
    > ;; ANSWER SECTION:
    > ns1.footprint.net. 171867 IN A 63.208.138.37
    >
    > ;; AUTHORITY SECTION:
    > footprint.net. 171867 IN NS ns9.footprint.net.
    > footprint.net. 171867 IN NS ns1.footprint.net.
    > footprint.net. 171867 IN NS ns2.footprint.net.
    > footprint.net. 171867 IN NS ns3.footprint.net.
    > footprint.net. 171867 IN NS ns4.footprint.net.
    > footprint.net. 171867 IN NS ns6.footprint.net.
    > footprint.net. 171867 IN NS ns7.footprint.net.
    > footprint.net. 171867 IN NS ns8.footprint.net.
    >
    > ;; ADDITIONAL SECTION:
    > ns2.footprint.net. 171867 IN A 64.152.81.68
    > ns3.footprint.net. 171867 IN A 63.208.138.37
    > ns4.footprint.net. 171867 IN A 67.72.120.47
    > ns6.footprint.net. 171867 IN A 210.8.213.38
    > ns7.footprint.net. 171867 IN A 63.209.70.231
    > ns8.footprint.net. 171867 IN A 212.187.253.68
    > ns9.footprint.net. 171867 IN A 212.162.1.100
    >
    > ;; Query time: 3 msec
    > ;; SERVER: 127.0.0.1#53(127.0.0.1)
    > ;; WHEN: Thu Jul 24 01:33:54 2008
    > ;; MSG SIZE rcvd: 303
    >
    > % dig ns2.footprint.net +norec
    >
    > ; <<>> DiG 9.3.0 <<>> ns2.footprint.net +norec
    > ;; global options: printcmd
    > ;; Got answer:
    > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 315
    > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
    >
    > ;; QUESTION SECTION:
    > ;ns2.footprint.net. IN A
    >
    > ;; AUTHORITY SECTION:
    > . 3600000 IN NS H.ROOT-SERVERS.net.
    > . 3600000 IN NS I.ROOT-SERVERS.net.
    > . 3600000 IN NS J.ROOT-SERVERS.net.
    > . 3600000 IN NS K.ROOT-SERVERS.net.
    > . 3600000 IN NS L.ROOT-SERVERS.net.
    > . 3600000 IN NS M.ROOT-SERVERS.net.
    > . 3600000 IN NS A.ROOT-SERVERS.net.
    > . 3600000 IN NS B.ROOT-SERVERS.net.
    > . 3600000 IN NS C.ROOT-SERVERS.net.
    > . 3600000 IN NS D.ROOT-SERVERS.net.
    > . 3600000 IN NS E.ROOT-SERVERS.net.
    > . 3600000 IN NS F.ROOT-SERVERS.net.
    > . 3600000 IN NS G.ROOT-SERVERS.net.
    >
    > ;; Query time: 4 msec
    > ;; SERVER: 127.0.0.1#53(127.0.0.1)
    > ;; WHEN: Thu Jul 24 01:33:59 2008
    > ;; MSG SIZE rcvd: 243
    >
    > %



+ Reply to Thread