Subject: Re: [DNSOP] DNSOP Digest, Vol 132, Issue 53

From: Tariq Saraj <[email-masked]>
Date: Tue, 19 Dec 2017 14:58:57 +0500

>The only use case you describe (firewall configuration) is
>questionable.
This is just a single use case, there can be a number of implementations
for IPv4 to IPv6 and vice versa resolution. As I have faced the problem
during development of writing automation service, thus i discuss this use
case to support the requiremnet of the proposed resource record.

>Most firewall configuration interfaces allow you to use
>domain names instead of IP addresses. So, if I want to allow port 443
>to www.example.com (which has IPv4 and IP v6 addresses), I can. Note
>that many firewall administrators don't use this because, rightly or
>wrongly, they don't trust the DNS. They'll have the same issue with
>your proposal.

using a firewall based on domain names can be simply bypassed by accessing
websites through IP address. We have experienced this scenario here in
Pakistan when the Government restrict access to youtube, but people were
still able to access it through the IP address.
Second, there are some firewalls such as Cisco and Kaspersky that handle
this situation when someone configure a firewall rule based on domain name,
it automatically resolves the IPv4 and IPv6 addresses for that domain and
update the firewall rules so that it cannot be bypassed through accessing a
server through IP based. But, these are highly expensive firewalls and
normally not affordable for every organization.

>By the way, that's why you _need_ to write something in the Security
>Considerations, probably mentioning DNSSEC.

Yes agreed, I will discuss it in that perspective.

On Mon, Nov 27, 2017 at 10:58 PM, <[email-masked]> wrote:

> Send DNSOP mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/dnsop
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of DNSOP digest..."
>
>
> Today's Topics:
>
>    1. Re:  IVIPTR: New RR for DNS (Stephane Bortzmeyer)
>    2. Re:  IVIPTR: New RR for DNS (Stephane Bortzmeyer)
>    3. Re:  Terminology: "primary master" (Joe Abley)
>    4. Re:  Terminology: "primary master" (Tony Finch)
>    5.  I-D Action: draft-ietf-dnsop-terminology-bis-08.txt
>       ([email-masked])
>    6. Re:  I-D Action: draft-ietf-dnsop-terminology-bis-08.txt
>       (Paul Hoffman)
>    7. Re:  [v6ops] New Version Notification for
>       draft-palet-sunset4-ipv6-ready-dns-00.txt (Gert Doering)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 27 Nov 2017 15:27:39 +0100
> From: Stephane Bortzmeyer <[email-masked]>
> To: Tony Finch <[email-masked]>
> Cc: bert hubert <[email-masked]>, Tariq Saraj
>         <[email-masked]>, [email-masked]
> Subject: Re: [DNSOP] IVIPTR: New RR for DNS
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Nov 27, 2017 at 01:38:08PM +0000,
>  Tony Finch <[email-masked]> wrote
>  a message of 24 lines which said:
>
> > Why not
>
> Section 1 of the draft explains "why not" but I disagree with their
> assessment. I think the PTR way is indeed the right one.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 27 Nov 2017 15:45:15 +0100
> From: Stephane Bortzmeyer <[email-masked]>
> To: Tariq Saraj <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [DNSOP] IVIPTR: New RR for DNS
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
> On Sat, Nov 25, 2017 at 10:41:13PM +0500,
>  Tariq Saraj <[email-masked]> wrote
>  a message of 60 lines which said:
>
> > Please provide your valuable feedback on the newly uploaded draft.
> > draft-tariq-dnsop-iviptr-00
> > <https://datatracker.ietf.org/doc/draft-tariq-dnsop-iviptr/>
> > *IVIPTR: Resource Record for DNS*
>
> The only use case you describe (firewall configuration) is
> questionable. Most firewall configuration interfaces allow you to use
> domain names instead of IP addresses. So, if I want to allow port 443
> to www.example.com (which has IPv4 and IP v6 addresses), I can. Note
> that many firewall administrators don't use this because, rightly or
> wrongly, they don't trust the DNS. They'll have the same issue with
> your proposal.
>
> By the way, that's why you _need_ to write something in the Security
> Considerations, probably mentioning DNSSEC.
>
> Otherwise, I'm not convinced by your argument against using PTR. If
> people don't configure PTRs to get the effect you want, it may be because:
>
> * they don't want to (so they don't need your proposal)
> * they're lazy or incompetent (so they'll ignore your proposal)
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 27 Nov 2017 11:34:11 -0500
> From: Joe Abley <[email-masked]>
> To: Tony Finch <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Havard Eidnes <[email-masked]>
> Subject: Re: [DNSOP] Terminology: "primary master"
> Message-ID: <[email-masked]>
> Content-Type: text/plain;       charset=us-ascii
>
> Hi Tony,
>
> On Nov 27, 2017, at 08:22, Tony Finch <[email-masked]> wrote:
>
> > Joe Abley <[email-masked]> wrote:
> >>> On Nov 23, 2017, at 12:44, Tony Finch <[email-masked]> wrote:
> >>>
> >>> It's quite difficult to have multiple masters and DNSSEC and coherent
> >>> copies of the zone from all masters - i.e. more effort than just
> spinning
> >>> up parallel instances of BIND or Knot in automatic signing mode.
> >>
> >> Note that I wasn't talking about multiple signers; I was talking about
> >> (from the perspective of one particular slave) having multiple masters
> >> available to serve precisely the same zone.
> >
> > A primary master is wrt a zone not a server - a zone's primary master is
> > a server that's authoritative for a zone and which does not get the zone
> > contents via axfr/ixfr, but instead from a master file and/or UPDATE (or
> > a non-standard mechanism such as directly from a database).
>
> That's an alluringly clear definition, but I'm not sure it matches common
> understanding of the term, which I think has more to do with "single source
> of truth" than with the specifics of what transport is used to provision
> zone data in a server.
>
> For example,
>
>     W <------- A -------> X
>
> Suppose A is a source of truth for a particular zone, and that W and X
> obtain zone data from A. Are you saying that if the mechanism represented
> by the arrows is [AI]XFR then A is a primary master and W and X are not,
> whereas if that mechanism is something else (perhaps it's rsync, with W, A
> and X all configured to be masters from local zone files) then W, A and X
> are all primary masters?
>
> If A is not a nameserver but instead is a database, and the arrows
> represent database replication, then W and X are primary masters but A is
> not?
>
>
> Joe
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 27 Nov 2017 17:15:17 +0000
> From: Tony Finch <[email-masked]>
> To: Joe Abley <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Havard Eidnes <[email-masked]>
> Subject: Re: [DNSOP] Terminology: "primary master"
> Message-ID: <[email-masked]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Joe Abley <[email-masked]> wrote:
>
> > > A primary master is wrt a zone not a server - a zone's primary master
> is
> > > a server that's authoritative for a zone and which does not get the
> zone
> > > contents via axfr/ixfr, but instead from a master file and/or UPDATE
> (or
> > > a non-standard mechanism such as directly from a database).
> >
> > That's an alluringly clear definition, but I'm not sure it matches
> > common understanding of the term, which I think has more to do with
> > "single source of truth" than with the specifics of what transport is
> > used to provision zone data in a server.
>
> Hmm, I think I sort-of agree, but with caveats...
>
> I prefer to make a clear distinction between the standard DNS as specified
> in the RFCs versus any funky non-standard stuff that people might do with
> the DNS.
>
> The standard DNS protocols are closely fitted to a particular distributed
> architecture, in which a zone has a single source of truth that we call
> the primary master. You can, of course, implement a similar architecture
> using non-standard protocols, but if you do you should take care to make
> it clear how you are diverging from the standard - and be careful about
> how you use standard DNS terminology when talking about your non-standard
> system.
>
> > For example,
> >
> >     W <------- A -------> X
> >
> > Suppose A is a source of truth for a particular zone, and that W and X
> > obtain zone data from A. Are you saying that if the mechanism
> > represented by the arrows is [AI]XFR then A is a primary master and W
> > and X are not, whereas if that mechanism is something else (perhaps it's
> > rsync, with W, A and X all configured to be masters from local zone
> > files) then W, A and X are all primary masters?
>
> In this case I would say A is a primary master and W and X are secondaries
> that use rsync instead of standard zone transfers.
>
> The part of the standard architecture that you have replaced is the zone
> transfer mechanism, so the primary master is architecturally unaffected,
> so it's OK to use the same name.
>
> (But you can't call rsync "ixfr" even though it is incrementally
> transferring zones, because that would be unreasonably confusing.)
>
> > If A is not a nameserver but instead is a database, and the arrows
> > represent database replication, then W and X are primary masters but A
> > is not?
>
> In this case I would be very proud of my high-availability multi-master
> system.
>
> Tony.
> --
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h
> punycode
> Shannon, Rockall, Malin, Hebrides, Bailey: North or northwest 5 to 7,
> occasionally gale 8 except in Shannon. Rough or very rough, occasionally
> moderate. Squally showers. Good.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 27 Nov 2017 09:49:17 -0800
> From: [email-masked]
> To: <[email-masked]>
> Cc: [email-masked]
> Subject: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-08.txt
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations WG of the
> IETF.
>
>         Title           : DNS Terminology
>         Authors         : Paul Hoffman
>                           Andrew Sullivan
>                           Kazunori Fujiwara
>         Filename        : draft-ietf-dnsop-terminology-bis-08.txt
>         Pages           : 44
>         Date            : 2017-11-27
>
> Abstract:
>    The DNS is defined in literally dozens of different RFCs.  The
>    terminology used by implementers and developers of DNS protocols, and
>    by operators of DNS systems, has sometimes changed in the decades
>    since the DNS was first defined.  This document gives current
>    definitions for many of the terms used in the DNS in a single
>    document.
>
>    This document will be the successor to RFC 7719, and thus will
>    obsolete RFC 7719.  It will also update RFC 2308.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-08
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-terminology-bis-08
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-08
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 27 Nov 2017 09:53:32 -0800
> From: "Paul Hoffman" <[email-masked]>
> To: [email-masked]
> Subject: Re: [DNSOP] I-D Action:
>         draft-ietf-dnsop-terminology-bis-08.txt
> Message-ID: <[email-masked]>
> Content-Type: text/plain; format=flowed
>
> This draft closes out a bunch of issues. (As a reminder, we're tracking
> issues both here on the list and on the GitHub repo:
> https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis).
>
> We will be opening new issues in the coming weeks with the intention to
> be ready for WG Last Call by mid-January.
>
> --Paul Hoffman
>
> On 27 Nov 2017, at 9:49, [email-masked] wrote:
>
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Domain Name System Operations WG of
> > the IETF.
> >
> >         Title           : DNS Terminology
> >         Authors         : Paul Hoffman
> >                           Andrew Sullivan
> >                           Kazunori Fujiwara
> >       Filename        : draft-ietf-dnsop-terminology-bis-08.txt
> >       Pages           : 44
> >       Date            : 2017-11-27
> >
> > Abstract:
> >    The DNS is defined in literally dozens of different RFCs.  The
> >    terminology used by implementers and developers of DNS protocols,
> > and
> >    by operators of DNS systems, has sometimes changed in the decades
> >    since the DNS was first defined.  This document gives current
> >    definitions for many of the terms used in the DNS in a single
> >    document.
> >
> >    This document will be the successor to RFC 7719, and thus will
> >    obsolete RFC 7719.  It will also update RFC 2308.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-08
> > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
> terminology-bis-08
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-08
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 27 Nov 2017 18:58:46 +0100
> From: Gert Doering <[email-masked]>
> To: Tony Finch <[email-masked]>
> Cc: Joe Abley <[email-masked]>, "[email-masked] WG"
>         <[email-masked]>, [email-masked], Daniel Karrenberg
>         <[email-masked]>, [email-masked], [email-masked]
> Subject: Re: [DNSOP] [v6ops] New Version Notification for
>         draft-palet-sunset4-ipv6-ready-dns-00.txt
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
> On Mon, Nov 27, 2017 at 12:28:16PM +0000, Tony Finch wrote:
> > The 31 TLDs with no v6 nameservers:
> [..]
>
> > mil.
>
> Yay.  Like, IPv6 mandate, and all that.
>
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> ------------------------------
>
> End of DNSOP Digest, Vol 132, Issue 53
> **************************************
>

-- 
Regards
Tariq Saraj
Riphah Institute of Systems Engineering, Islamabad

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Dec 2017 17:29:55 +0100

On Tue, Dec 19, 2017 at 02:58:57PM +0500,
 Tariq Saraj <[email-masked]> wrote 
 a message of 1158 lines which said:

> using a firewall based on domain names can be simply bypassed by
> accessing websites through IP address.

No, no, this is absolutely not what I was talking about. Instead, I
referred to:

> server through IP based.

Exactly.

> But, these are highly expensive firewalls and normally not
> affordable for every organization.

Any 50 US $ OpenWRT router can do it (iptables accepts domain names).

% sudo iptables -A OUTPUT -d www.example.com -j DROP

% sudo iptables -n -v -L OUTPUT
Chain OUTPUT (policy ACCEPT 184 packets, 22306 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       0.0.0.0/0            93.184.216.34

---

From: Tariq Saraj <[email-masked]>
Date: Fri, 22 Dec 2017 00:44:09 +0500

hi Bortzmeyer,
there are still some issues with

 >   0     0 DROP       all  --  *      *       0.0.0.0/0
93.184.216.34

First these rules are still bypassed by the client. Below I have two
commands ping and the dig. with the ping command the IP address is
different, while when the dig command is passed for the domain facebook.com
the answer is a different IP address.
.
****@ubuntu:~$ ping facebook.com
PING facebook.com (157.240.1.35) 56(84) bytes of data.
64 bytes from edge-star-mini-shv-01-lht6.facebook.com (157.240.1.35):
icmp_seq=1 ttl=50 time=148 ms
64 bytes from edge-star-mini-shv-01-lht6.facebook.com (157.240.1.35):
icmp_seq=2 ttl=50 time=149 ms
64 bytes from edge-star-mini-shv-01-lht6.facebook.com (157.240.1.35):
icmp_seq=3 ttl=50 time=148 ms
^C
--- facebook.com ping statistics ---
11 packets transmitted, 11 received, 0% packet loss, time 10010ms
rtt min/avg/max/mdev = 148.903/148.997/149.096/0.372 ms

[The dig command]
****@ubuntu:~$ dig facebook.com A
; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> facebook.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62852
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;facebook.com.            IN    A
;; ANSWER SECTION:
facebook.com.        212    IN    A    185.60.216.35
;; Query time: 41 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Dec 21 11:28:46 PST 2017
;; MSG SIZE  rcvd: 57

Also, even if all this is keep aside for the time being, what about all
those IP addresses or IPv6 addresses that are configured on any of the
network security component such as firewall in my usecase? One still need
to resolve the corresponding IP address if rules are based on IPv6 address
or IPv6 address if rules are based on IP address.