Re: rndc - sync before reload?

[Evan Hunt]

On Fri, Jul 12, 2019 at 01:34:35AM +, John W. Blue wrote:
> I have zero experience with dynamic zones on BIND because all of ours are
> static.  That said, and since nobody else has commented, it seems like it
> would make sense to sync before reload.
> 
> The man says that sync writes out to the journal which shouldn't ever be
> a bad thing.

It doesn't write *to* the journal file; it takes the changes that are
encoded in the journal file and writes them out to the zone master file.

I guess that wasn't clear, so maybe the man page needs some clarification:

   sync [-clean] [zone [class [view]]]
   Sync changes in the journal file for a dynamic zone to the master
   file. If the "-clean" option is specified, the journal file is also
   removed. If no zone is specified, then all zones are synced.

"rndc reload" loads the zone from the master file *plus* the journal file,
if there is one. There's no need to sync the journal file to the master
file before reloading.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: rndc - sync before reload?

[Alan Clegg]

On 7/14/19 8:00 PM, John W. Blue wrote:
> Please elaborate on the technical reason why instead of being terse.

I'll give a short version:

"rndc reload" existed from the early days of BIND with the first notice
in CHANGES being [bug] 287 in 9.1.0b1.

"rndc sync" came along with [func] 3084 in BIND 9.9.0a1.

You don't need to sync before you reload.

As to the internals, I dunno.

AlanC

___
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: DMARC test

[Jim Popovitch via bind-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2019-07-14 at 18:30 -0400, Paul Kosinski via bind-users wrote:
> Testing how lists.isc.org handles DMARC "Quarantine" (and "Reject")
> policy. The enterpr...@mozilla.org mailing list forwards such email in a
> way that some recipients choke on it (i.e., can't validate it).

This list applies the Mailman DMARC handler which, in the case of this
list's configuration, munges the From address.  In your specific case,
subscribers see the email as 

 From: Paul Kosinski via bind-users 
 Reply-to: Paul Kosinski 

You can read more about how Mailman handles DMARC here: 
   https://wiki.list.org/DEV/DMARC

hth,

- -Jim P.
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE3RmV4WutJ2KyCS2zPcxbabkKGJ8FAl0rw7cACgkQPcxbabkK
GJ9JChAAhNPPmoLbUR0UGsPjEfYSSPe1fSoO5q+larj9mXaO9rCOuVpSucf5FqOb
zex2JSqyX7Xh8PUTgUnaNLocKFOXxh2Csdx/a/vagSGBfalFk9cShX92dyn5eySj
Ah+wQjqh+1uA9esJcDpW+/HtPYUCb1+ixlzxCwneF/kNPNX8yxtenqOMBM1l2Pi+
vlt8JYM/OxSs5mOz1AWRh9OLGL+E7eUg3dljrkRhhSDqDYMlswNNT4ffgRX1EvpR
Z6BWgV8gPdmbJPzW+6ZlU53QLauhmGpL8BN6/Ur4739cKgZfxpjyV2DSSau3BGzp
cy3o8g/9Lrvvlnfiv1YZfESnQl2mfeseEj+CZespDbHu4CEVT3DqXWdQQDHAqidv
GRJ8FJtuqU2UjM+W4mNMEAwwKn5lQRbVnct4btExEYWvr7hdTGiaybNYlr9+jGDj
DlnmM9XZE8vIPvOF0mrFA8qWdLkMp5ecOlLn35++XDb2BSLDgZd+n8WqVJ3G+7Df
ZgixhaPQQADisfzk3nujKPu1JVBeIwEKyr8YW4LUvjcORLvp13UTxF00p9EVoLF6
yovKLpYvPXN0Vw6h58YAemWnEr46txzrUnHsW8/6JhT8t1AMew/9nyFu+7maOjX+
wHgFNS+YEkCbG0RbFaAkVH8fGgIwPUMUsx3SpKvkuKZpz/SqTHk=
=blPk
-END PGP SIGNATURE-

___
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: rndc - sync before reload?

[John W. Blue]

Please elaborate on the technical reason why instead of being terse.

Thanks!

John

Sent from Nine

From: Anand Buddhdev 
Sent: Saturday, July 13, 2019 4:48 PM
To: John Thurston; bind-users@lists.isc.org
Subject: Re: rndc - sync before reload?

On 10/07/2019 20:08, John Thurston wrote:

Hi John,

> On a server with both static and dynamic zones, is there any reason to
> perform an:
>   rndc sync
> prior to issuing an:
>   rndc reload

No, there is no need for a sync before reload.

Regards,
Anand
___
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

DMARC test

[Paul Kosinski via bind-users]

Testing how lists.isc.org handles DMARC "Quarantine" (and "Reject")
policy. The enterpr...@mozilla.org mailing list forwards such email in a
way that some recipients choke on it (i.e., can't validate 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

Re: static stub zone not working as expected

[Mark Andrews]

> On 14 Jul 2019, at 1:18 am, Jay Ford  wrote:
> 
> I'm still confused about why named looks further up the tree than
> c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa which it holds authoritatively via
> master/slave zone type.  That seems like incorrect behavior.

The cache doesn’t know about zones.  The lookup just make a query of
the cache for the name and also asks for potential covering NSEC records
to be returned if it is not found.  In this case it finds a covering NSEC
record.

0.c.2.ip6.arpa. 3012IN  NSECip6.arpa. NS DS RRSIG NSEC

d.f.ip6.arpa lies between 0.c.2.ip6.arpa and ip6.arpa.  Now if there was
the requested break in the chain of trust existed that was requested to be
added in RFC 6303 it would find.

d.f.ip6.arpa.   3600IN  NSECip6.arpa. NS RRSIG NSEC

Which says d.f.ip6.arpa is a delegation point so I don’t know anything about
names ending in d.f.ip6.arpa but there are no names in ip6.arpa between
d.f.ip6.arpa and ip6.arpa.  Named won’t synthesis negative responses for ULA
reverse names from that NSEC record.

> Is this something I can fix or work around?

You can turn off synthesis "synth-from-dnssec no;” 

> __
> Jay Ford , Network Engineering, University of Iowa
> 
> On Sat, 13 Jul 2019, Mark Andrews wrote:
>> I suspect this will be negative response synthesis. The cache has learnt 
>> that d.f.ip6.arpa doesn’t exist in ip6.arpa and when the name in question is 
>> looked up the covering NSEC is returned which covers all of ULA space.
>> 
>> If I’m right querying for DS d.f.ip6.arpa will load the cache appropriately 
>> to allow this to be triggered.  One then needs to trigger a lookup for a 
>> name which finds the covering NSEC in the search back through the cache.  
>> Named skips some responses in the search depending on the content but aborts 
>> it on others content.
>> -- 
>> Mark Andrews
>> 
>>> On 13 Jul 2019, at 00:42, Jay Ford  wrote:
>>> 
>>> On Fri, 12 Jul 2019, Mark Andrews wrote:
> On 12 Jul 2019, at 1:00 pm, Mark Andrews  wrote:
> 
>> On 12 Jul 2019, at 11:12 am, Jay Ford  wrote:
>> 
>> I have a similar problem with zones for IPv6 ULA space.  I'm running 
>> BIND 9.14.3.  I had hoped that validate-except would do the trick, such 
>> as:
>> 
>> validate-except { "f.ip6.arpa"; };
>> 
>> but alas, no.
>> 
>> Extra puzzling so far is that the behavior is time-variable: delegated 
>> zones will resolve most of the time, but then fail (NXDOMAIN) for a 
>> while.
>> 
>> In the ULA space it doesn't seem trivial to own the top zone (ip6.arpa) 
>> without breaking stuff.  Any suggestions for that case?
 
 ULA space it trivial to own.  D.F.IP6.ARPA is what you use if you have 
 multiple ULA prefixes.
 If you have a single ULA prefix in use then just use that.  e.g. 
 e.8.b.0.5.6.0.7.2.9.d.f.ip6.arpa
 which matches the ULA prefix used in the system tests (fd92:7065:b8e::/48).
 
 This is no different to using 10.in-addr.arpa, 168.192.in-addr.arpa or one 
 of 16.172.in-addr.arpa
 though 31.172.in-addr.arpa for RFC 1918 space.
 
 If fc00::/8 is ever used then you would also have C.F.IP6.ARPA.
 
 Named creates the D.F.IP6.ARPA zone automatically if you don’t create it 
 when the view is
 configured for recursion.  This is done to stop reverse lookups leaking 
 onto the internet
 as a whole.
 
 % dig soa d.f.ip6.arpa
 ;; BADCOOKIE, retrying.
 
 ; <<>> DiG 9.15.1 <<>> soa d.f.ip6.arpa
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23519
 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 4096
 ; COOKIE: aa8a24a1cce6c010b9d3a1b75d28009bb013cb0a2f58a961 (good)
 ;; QUESTION SECTION:
 ;d.f.ip6.arpa.INSOA
 
 ;; ANSWER SECTION:
 D.F.IP6.ARPA.86400INSOAD.F.IP6.ARPA. . 0 28800 7200 
 604800 86400
 
 ;; Query time: 0 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Fri Jul 12 13:38:03 AEST 2019
 ;; MSG SIZE  rcvd: 116
>>> 
>>> Yep, that's what I thought.  I have master/slave for the zone corresponding
>>> to my ULA /48 (c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa), which is solid including
>>> zones under it also handled as master/slave, but not for zones which are
>>> delegated via NS records to other servers (not master/slave), such as
>>> d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa which usually resolves like this:
>>> 
>>>  % dig -t ns d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-itf.uiowa.edu
>>> 
>>>  ; <<>> DiG 9.10.3-P4-Debian <<>> -t ns 
>>> d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-itf.uiowa.edu
>>>  ;; global options: +cmd
>>>  ;; Got answer:
>>>  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23886