RE: root.hind or named.hint file update

[Michael Hare]

Agreed, using outdated built in hints and diligent logging does cause a minor 
annoyance (minor as it can be filtered after verifying the incident), so there 
is merit in updating even if automatic updates might not make sense.  For 
example, an unfiltered log from a production resolver of ours would like to say 
the following :)

21-Sep-2016 00:01:02.859 general: warning: checkhints: l.root-servers.net/ 
(2001:500:9f::42) missing from hints
21-Sep-2016 00:01:02.859 general: warning: checkhints: l.root-servers.net/ 
(2001:500:3::42) extra record in hints
21-Sep-2016 00:01:03.580 general: warning: checkhints: l.root-servers.net/ 
(2001:500:9f::42) missing from hints
21-Sep-2016 00:01:03.580 general: warning: checkhints: l.root-servers.net/ 
(2001:500:3::42) extra record in hints
21-Sep-2016 00:01:05.102 general: warning: checkhints: l.root-servers.net/ 
(2001:500:9f::42) missing from hints
21-Sep-2016 00:01:05.102 general: warning: checkhints: l.root-servers.net/ 
(2001:500:3::42) extra record in hints
21-Sep-2016 00:01:05.174 general: warning: checkhints: l.root-servers.net/ 
(2001:500:9f::42) missing from hints
21-Sep-2016 00:01:05.174 general: warning: checkhints: l.root-servers.net/ 
(2001:500:3::42) extra record in hints
21-Sep-2016 00:01:06.087 general: warning: checkhints: l.root-servers.net/ 
(2001:500:9f::42) missing from hints

-Michael

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matus 
UHLAR - fantomas
Sent: Friday, September 23, 2016 7:32 AM
To: bind-users@lists.isc.org
Subject: Re: root.hind or named.hint file update

>Pol Hallen  wrote:
>>
>> is it recommend put a cron script for auto-update root.hind and named.hint 
>> db?

On 23.09.16 12:54, Tony Finch wrote:
>No, it's best not to have a hints file and just use the one built in to BIND.

i would not say that... it's better to use builtin hints file than having
outdated hints file.

But if someone does care about hints file, it's better to have current
version, when the builtin one is older.


-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Minimal responses and speeding up queries

[Mark Andrews]

In message , Tony Finch 
writes:
> Reindl Harald  wrote:
> >
> > just because without additional responses are part of the inital question 
> > and
> > may save asking for that information - in case the additional info is not
> > needed by the client it saves traffic
> 
> There are a few situations in which additional data is useful in theory,
> but it's surprisingly poorly used in practice.
> 
> End-user clients are generally looking up address records, and the
> additional and authority records aren't of any use to them.
> 
> For MX and SRV records, additional data can reduce the need for extra A
> and  records - but only if both A and  are present in the
> response. If either RRset is missing the client still has to make another
> query to find out if it doesn't exist or wouldn't fit. Some code I am
> familiar with ignores additional sections in MX responses and always does
> separate A and  lookups, because it's simpler.
> 
> The other important case is for queries from recursive servers to
> authoritative servers, where you might hope that the recursive server
> would cache the additional data to avoid queries to the authoritative
> servers.
> 
> However, in practice BIND is not very good at this. For example,
> let's query for an MX record, then the address of one of the MX target
> hosts. We expect to get the address in the response to the first query, so
> the second query doesn't need another round trip to the authority.
> 
> Here's some log, heavily pruned for relevance.
> 
> 2016-09-23.10:55:13.316 queries: info: client @0x7f9d380311b0 ::1#55658 
> (isc.org): view rec: query: isc.org IN MX +E(0)K (::1)
> 2016-09-23.10:55:13.318 resolver: debug 11: sending packet to 
> 2001:500:60::30#53
> ;; QUESTION SECTION:
> ;isc.org.   IN  MX
> 2016-09-23.10:55:13.330 resolver: debug 10: received packet from 
> 2001:500:60::30#53
> ;; ANSWER SECTION:
> ;isc.org.   7200IN  MX  10 mx.pao1.isc.org.
> ;isc.org.   7200IN  MX  20 mx.ams1.isc.org.
> ;; ADDITIONAL SECTION:
> ;mx.pao1.isc.org.   3600IN  A   149.20.64.53
> ;mx.pao1.isc.org.   3600IN  2001:4f8:0:2::2b
> 2016-09-23.10:56:13.150 queries: info: client @0x7f9d300609e0 ::1#49485 
> (mx.pao1.isc.org): view rec: query: mx.pao1.isc.org IN A +E(0)K (::1)
> 2016-09-23.10:56:13.151 resolver: debug 11: sending packet to 
> 2001:500:60::30#53
> ;; QUESTION SECTION:
> ;mx.pao1.isc.org.   IN  A
> 
> Hmf, well that's disappointing.
> 
> Now, there's a rule in RFC 2181 about ranking the trustworthiness of data:
> 
> 5.4.1. Ranking data
> 
>[ snip ]
> 
>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.
> 
> Since my recursive server is validating, and isc.org is signed, it should
> be able to authenticate the MX target address from the MX response, and
> promote its trustworthiness, instead of making another query. But BIND
> doesn't do that.
> 
> There are other situations where BIND fails to make good use of all the
> records in a response, e.g. when you get a referral for a signed zone, the
> response includes the DS records as well as the NS records. But BIND
> doesn't cache the DS records properly, so when it comes to validate the
> answer, it re-fetches them.

Both of these are on my to do list.  There is also the no DS available
in the delegation to be validated at the transition from signed to
unsigned zones.

> Tony.
> -- 
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
> Northwest Fitzroy, West Sole: Southerly, veering westerly later, 6 to gale 8.
> Rough or very rough. Fair then rain. Good, occasionally poor.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users